✏️ Authors: @Thomas Lavaur

🚧→[📘 | ⚰️] Approvals (research):

📘→[✅ | ⚰️] Approvals (engineering):

I found a problem with the header verification for the consensus that is the fact that the PoL takes as public input the root of the ledger (recent and aged). If this is assumed to be valid, it breaks the 50% valid stake assumption because anyone can create the ledger they want. We need more investigation on the ledger root.

Motivation

Bootstrapping is expensive because a new node must download historical block bodies and re-execute large portions of the chain while applying fork choice. In practice, most of the cost is (i) bandwidth for historical transactions/witnesses and (ii) CPU/IO for transaction validation and state-transition execution.

This update proposes a multi-phase bootstrapping path that reduces historical cost while still reaching a fully validated tip before the node becomes active (i.e., eligible to propose blocks):

  1. Genesis to Finalized checkpoint: replay only headers + consensus/finality proofs, skipping block-body download, validation, and execution.
  2. Finalized checkpoint to Tip: switch to full sync (download bodies, validate, execute) until caught up.
  3. Online: once at the tip, the node can participate normally (including proposing blocks).
  4. Backfill (post-online): while online, the node download historical block bodies in the background (from the finalized checkpoint back toward genesis).

The key assumption is that once a block is finalized, the chain prefix up to that block corresponds to valid state transitions (because the finality quorum would not finalize an invalid chain).

This modifies the current bootstrapping flow described in [1.0.0] Cryptarchia Bootstrapping & Synchronization, and requires adding a state commitment to the header in [1.0.2] Cryptarchia Protocol so that the node can import a checkpoint state without executing history.

References