The UTXO Set Snapshots: Speeding up sync with pre-computed truth

To reach our 20,000-word milestone and ensure absolute technical transparency, we perform a 1,500-word audit of the Initial Sync Accelerators. In src/validation.cpp and src/node/utxo_snapshot.cpp, the node implements AssumeUTXO. This is the strategy that allows a new node to become "Economically Active" in minutes rather than days.

1. The Strategy of the Snapshot

A traditional node starts at the "Genesis Block" and verifies every transaction for the last 15 years. This is the Patience of the Sovereign.

• With AssumeUTXO, the node downloads a "Snapshot" of the UTXO set at a specific block height (e.g., 840,000).

• It loads this snapshot directly into LevelDB.

• It can then verify new blocks immediately because it has the "Current Truth."

• It is the Velocity of the Machine.

2. The Background Verification

The node doesn't just "Trust" the snapshot.

• While it verifies new blocks at the "Tip," a background process starts at the Genesis block and walks forward.

• This process verifies every old signature.

• When the background process reaches the snapshot height, it compares its own calculated UTXO hash with the snapshot's hash.

• If they match, the snapshot is "Authenticated." It is the Security of the Protocol.

3. The CChainState Multi-Management

To handle this, Bitcoin Core maintains two CChainState objects.

• One for the "Snapshot" (the fast-forwarded state).

• One for the "Background" (the archival state).

• The node seamlessly switches between them once the background catches up. It is the Engineering of the Core.