Authors: Hong-Sheng Zhou [email protected]; Thomas Lavaur <[email protected]>

• Status tracker

Reviewers

• Draft
• Verified

Change log

Motivation

Full bootstrapping from genesis is correct, but it can be slow. A new node must download, validate, and execute the complete historical chain. As the chain grows, this means processing many blocks and verifying many consensus and execution rules before the node can participate normally.

The trusted bootstrap source already helps a node start from genesis. This RFC extends that role: the trusted bootstrap source can provide a recent checkpoint package, so a new node can start closer to the current chain tip.

After starting from the checkpoint, the node still validates and executes the remaining suffix locally.

Vocabulary

checkpoint_block: the first block of the selected checkpoint epoch used as the checkpoint anchor.

checkpoint_state: the state after the epoch-transition logic for checkpoint_block's epoch and before executing checkpoint_block.

checkpoint package: a package containing checkpoint_block, checkpoint_state, and checkpoint_metadata.

checkpoint_metadata: metadata included in the checkpoint package.

epoch_state_root: a block-header field representing the state root for the start of the block's epoch. Every block in the same epoch carries the same epoch_state_root value.

state-root computation: the computation that derives epoch_state_root from checkpoint_state.

Proposal

This RFC introduces checkpoint-based fast bootstrapping as the recommended fast initialization path for new nodes when a valid checkpoint package is available from the trusted bootstrap source. Genesis bootstrapping remains possible as an explicit operator choice, but it requires downloading, validating, and executing the complete historical chain and can be impractically slow.