For those familiar with the Cryptarchia v2/v2-prime protocol, feel free to skip directly to the 'An Attack' section.

An earlier version can be found at On the Closest Common Ancestor (CCA) Rule in v2/v2-prime (first draft). I have revised several paragraphs based on my discussions with Álvaro.

The Closest Common Ancestor (CCA) rule functions as a fundamental component of the conflict resolution mechanism in Cryptarchia v2 consensus protocol. This protocol enhances resilience, adaptability to network delays, and supports multiple concurrent proposers in a blockchain system using a Directed Acyclic Graph (DAG) structure. The CCA rule specifically resolves conflicts arising from blocks containing incompatible transactions.

This document examines the CCA rule in Cryptarchia v2, analyzes the rule with unbounded window size in v2-prime, and illustrates a potential attack. This attack in the unbounded window size setting serves as a starting point for carefully analyzing the CCA rule in the full v2 protocol, which requires a suitably sized window.

The CCA Rule in v2

Context: Conflict Resolution in a DAG-Based Protocol

In Cryptarchia v2, blocks form a DAG where each block references previous blocks, encoding both history and agreement relationships. Conflicts occur when DAG branches contain mutually incompatible transactions (such as double-spends). Since the DAG allows concurrent block production, a robust canonical branch selection method is essential.

Defining the Closest Common Ancestor (CCA)

When two conflicting blocks $i$ (honest) and $j$ (adversarial) are identified, the protocol locates their closest common ancestor (CCA)—the most recent block that is an ancestor of both in the DAG. Formally, for blocks $i$ and $j$:

Weight Calculation from the CCA

After identifying CCA $c$, the protocol calculates the "weight" of each branch (the honest branch from $i$ and the adversarial branch from $j$), starting from $c$. Weight is defined as the sum of window-filtered references in all descendant blocks from the CCA. The reference window parameter (typically 30 slots) ensures only recent activity counts, preventing exploitation of long-range references.

For each branch: