Summary:

In this write-up, we analyze the proposal “Improving Cryptarchia” by Álvaro (see Notion link).

In “Improving Cryptarchia”, each slot’s leader is elected just before block production via a VRF over all current forks. In practice, every node hashes the ordered list of all slot-s forks to produce a common random value for slot s+1. All blocks in slot s are treated as “parents” (fork refs) for slot s+1. Each new block carries a weight equal to the number of references it receives, and the fork-choice rule selects the chain of highest total weight (sum of block weights), using chain length only to break weight-ties. Intuitively this is meant to force agreement on the VRF output and incorporate all forks into leader selection.

However, under even modest network delay, an attacker can abuse this rule. In the analysis will be provided below, an adversary with 40% stake withheld some blocks (creating private forks) so that when later revealed they collect many references. Because block weight grows with fan-in, the attacker’s fork gained more weight than the honest chain, even though it controlled less stake. This is akin to a “selfish-mining” style attack in Bitcoin: by delaying publication and creating highly-referenced blocks, a minority adversary can override the honest chain (which has fewer references due to delays).

Overview of the Single-Proposer Protocol

We concentrate on the single-proposer variant introduced in Improving Cryptarchia. Rather than assigning leadership on a per-epoch basis, this design emulates Nakamoto’s original per-block leader election: no participant knows their future leadership roles until immediately before block production. Please also see the “Two Problem” section in Improving Cryptarchia for the motivations.

Below is the single-proposer protocol.

  1. Feed all slot-s forks into the VRF for slot s+1.
  2. Force agreement on that VRF output via fork-ref weighting.
    1. At slot s+1, each node runs the VRF over the ordered list of forks it knows (“fork refs”) and publishes a proof of selection.
    2. Assign each block a weight equal to the number of refs it receives. Replace “fork length” with “fork weight” (the sum of its blocks’ weights).
      • Higher-weight forks win.
      • Ties by weight are broken by longer fork length.
      • If still tied, use Cryptarchia’s existing tie-break rule.

Figure 1: In this single-proposer chain extension process, players follow the protocol. Honest blocks are shaded green, and all parent-references appear as solid arrows. Notice that at Slot s+1, Forks 2A and 2B each reference exactly one predecessor (fan-in = 1), while Fork 2C references all three of its parents (fan-in = 3). The same pattern recurs at Slot s+2: Forks 3A and 3B have fan-in 1, whereas Fork 3C has fan-in 3.

Figure 1: In this single-proposer chain extension process, players follow the protocol. Honest blocks are shaded green, and all parent-references appear as solid arrows. Notice that at Slot s+1, Forks 2A and 2B each reference exactly one predecessor (fan-in = 1), while Fork 2C references all three of its parents (fan-in = 3). The same pattern recurs at Slot s+2: Forks 3A and 3B have fan-in 1, whereas Fork 3C has fan-in 3.