Checkpoint Sync

What Is Checkpoint Sync?

Checkpoint sync (also called weak subjectivity sync or trusted checkpoint sync) is a synchronization method for Beacon Chain nodes that skips replaying years of historical block processing. Instead of validating every slot from genesis, a new node downloads a recent finalized state and its corresponding block from a trusted source, then starts validating forward from that point.

The technique exists because proof-of-stake chains face a challenge that proof-of-work chains do not: long-range attacks. Validators who participated early in the chain and later exited could maintain a secret fork and present it to a new node syncing from genesis. That node would have no way to distinguish the real chain from the forged one because the attacking validators' stakes have already been withdrawn. Checkpoint sync solves this by anchoring trust to a recent finalized state where the current validator set is known.

On Ethereum, all major consensus clients now support checkpoint sync, and Lighthouse has made it the default since v4.6.0. Genesis sync requires an explicit opt-in flag.

How It Works

Checkpoint sync operates in two phases: a fast forward sync to reach the chain head, followed by a background backfill of historical data.

Phase 1: Forward Sync

The node operator provides a checkpoint sync URL pointing to a trusted, fully synced beacon node. The syncing node then:

1. Downloads a finalized BeaconState (SSZ-encoded) and its corresponding SignedBeaconBlock from the remote node via the Beacon API
2. Verifies the checkpoint is within the weak subjectivity period (not too old)
3. Treats this checkpoint as a trusted anchor (a pseudo-genesis block)
4. Syncs forward from that slot to the current chain head, performing full state transition verification for each subsequent block

This forward sync completes in roughly two to five minutes, compared to several hours or days for a genesis sync.

Phase 2: Backfill Sync

Once the node is at the chain head and participating in attestation duties, it begins downloading historical blocks backward in the background. This backfill performs only lightweight verification: checking the hash chain integrity and proposer signatures rather than re-executing full state transitions.

Backfill behavior varies by client. Lighthouse defaults to stopping at the weak subjectivity point (roughly five months back) rather than downloading all the way to genesis. Nimbus supports a --backfill=false flag to skip historical downloads entirely.

Beacon API Endpoints

The checkpoint data comes from standardized Beacon API endpoints shared across all consensus clients:

# Fetch the finalized state
GET /eth/v2/debug/beacon/states/finalized

# Fetch the corresponding block
GET /eth/v2/beacon/blocks/{slot}

# Example: start Lighthouse with checkpoint sync
lighthouse bn \
  --network mainnet \
  --checkpoint-sync-url https://beaconstate.ethstaker.cc

# Example: start Prysm with checkpoint sync
prysm.sh beacon-chain \
  --checkpoint-sync-url https://beaconstate.ethstaker.cc \
  --genesis-beacon-api-url https://beaconstate.ethstaker.cc

The Weak Subjectivity Window

The weak subjectivity period defines how old a checkpoint can be while still being considered safe. It depends on the active validator count, average validator balance, and a safety decay parameter. With Ethereum mainnet's current validator set of over 900,000 validators, the weak subjectivity period is approximately 3,500 epochs (roughly 15 to 16 days).

Using a checkpoint older than this window is unsafe because the validator set may have rotated enough that a one-third attack becomes feasible. Consensus clients check the checkpoint age and reject stale ones by default.

Comparison to Bitcoin's Initial Block Download

Bitcoin's initial block download (IBD) is fundamentally different in its trust model. A new full node downloads and fully validates every block and transaction from the genesis block in 2009 forward. No trusted third party is required: the node independently verifies the entire chain using proof of work as the objective measure of chain validity.

Bitcoin Core does offer AssumeUTXO, which shares a conceptual similarity: a node downloads a UTXO set snapshot and starts validating immediately while performing full background verification of all history. The key difference is that AssumeUTXO eventually achieves complete independent verification, while Ethereum's checkpoint sync never re-executes full state transitions for pre-checkpoint history.

Client Support

All major Ethereum consensus clients support checkpoint sync, each with slightly different flags and behaviors:

• Lighthouse: --checkpoint-sync-url. Default since v4.6.0; genesis sync requires --allow-insecure-genesis-sync
• Prysm: --checkpoint-sync-url plus --genesis-beacon-api-url. Also supports file-based sync via --checkpoint-block and --checkpoint-state
• Teku: --checkpoint-sync-url or --initial-state for file-based sync
• Lodestar: --checkpointSyncUrl
• Nimbus: uses a separate trustedNodeSync command before starting the node normally
• Grandine: --checkpoint-sync-url with back-syncing disabled by default

Use Cases

Rapid Validator Deployment

Staking operators running dozens or hundreds of validator nodes need to bring new instances online quickly. Checkpoint sync reduces provisioning time from days to minutes, making it practical to scale validator infrastructure on demand without missing attestation duties.

Disaster Recovery

When a node's database becomes corrupted or hardware fails, the operator can restore service in minutes by checkpoint syncing to a fresh machine. Without checkpoint sync, recovering a consensus client would require hours of re-syncing during which the validator misses attestations and accrues inactivity penalties.

Development and Testing

Developers building on Ethereum need local nodes for testing. Checkpoint sync lets a developer spin up a fully synced mainnet node in minutes rather than waiting days, lowering the barrier to running personal infrastructure.

Decentralization Support

Long sync times discourage solo stakers from running their own nodes. By reducing the initial setup to minutes, checkpoint sync makes it more practical for individuals to operate full nodes and contribute to network decentralization.

Risks and Considerations

Trust in the Checkpoint Provider

The most significant tradeoff is the trust assumption. If the checkpoint provider serves a state from a forged chain, the syncing node would follow the wrong fork with no way to independently detect the deception. This is a fundamental departure from proof-of-work chains where cumulative work provides an objective, trustless measure of chain validity.

The primary mitigation is to verify the checkpoint's block root and slot number against multiple independent sources: block explorers, community-maintained endpoint lists, and other trusted node operators. Using a single checkpoint provider is risky; cross-referencing several sources significantly reduces the attack surface.

Stale Checkpoint Risk

A checkpoint older than the weak subjectivity period is unsafe. The validator set may have changed enough that an attacker controlling one-third of the historical stake could present a convincing alternative chain. Consensus clients reject stale checkpoints by default, though some offer override flags for special cases (such as Teku's --ignore-weak-subjectivity-period-enabled).

Reduced Historical Verification

A checkpoint-synced node never performs full state transition verification for blocks before the checkpoint. The backfill phase only checks hash chain continuity and proposer signatures. This means the node trusts that pre-checkpoint state transitions were valid based on the finalization guarantee, rather than verifying them independently. For most use cases this is acceptable, since finalized checkpoints represent a two-thirds supermajority attestation from active validators.

Eclipse Attacks on Checkpoint Sources

If an attacker controls all the checkpoint sources a node operator consults, they can serve a consistent but false checkpoint. Diversity of sources is essential: use endpoints maintained by different organizations, check community resources, and when possible verify against a locally synced node operated by a trusted party.

Why It Matters

Checkpoint sync is a practical necessity for proof-of-stake networks at scale. Without it, syncing a new Beacon Chain node from genesis would take days, discouraging participation and centralizing node operation among those with the patience and resources for long sync times. The speed advantage comes at the cost of a trust assumption, but the Ethereum community has accepted this tradeoff, making checkpoint sync the recommended default across all major clients. For a deeper look at how different blockchains approach syncing and node bootstrapping, see the research article on full node cost and requirements.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.