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).
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.
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.