Checkpoint

A checkpoint creates a cryptographically signed, finalized record of the blockchain's state at a specific block. This provides a canonical reference point that is considered irreversible, preventing long-range attacks. Validators or a trusted committee typically sign checkpoints, making them a source of weak subjectivity for new nodes joining the network.

In interoperability protocols, a checkpoint is the act of submitting a Merkle root or block header from a source chain to a destination chain. This proves the state of the source chain, allowing assets or messages to be verified and unlocked. For example, a light client on Chain B can verify a transaction from Chain A using only its checkpoint header.

Nodes can sync to the network's current state much faster by downloading the most recent checkpoint instead of processing every historical block. They download the world state (account balances, contract storage) at that checkpoint and then only validate new blocks. This reduces sync time from days to hours.

In Proof-of-Stake networks like Ethereum, an epoch (32 slots/blocks) ends with a finalized checkpoint. A block must be justified and then finalized in a subsequent epoch to become irreversible. This Casper FFG mechanism provides economic finality, distinct from the probabilistic finality of Nakamoto consensus.

Not all checkpoints imply absolute finality. Objective checkpointing (e.g., in Tendermint) is instantly final. Subjective checkpointing (e.g., in early Ethereum PoW) relied on social consensus. The key distinction is whether reversal requires a software fork (objective) or can be ignored by new nodes (subjective).

Checkpoints create a finality guarantee, making reverted transactions after a checkpoint economically infeasible. This enhances security but introduces a liveness trade-off: the network must wait for the checkpoint interval to achieve this finality, potentially delaying transaction confirmation compared to probabilistic finality models.

The security of a checkpoint often depends on a trusted entity or a federated committee (e.g., a multi-signature wallet) to sign the checkpoint hash. This creates a centralization risk and a weak subjectivity requirement, as new nodes must trust an external source for the latest valid checkpoint to sync correctly.

Checkpoints are a primary defense against long-range attacks, where an attacker creates an alternative chain from far back in history. By anchoring the chain at regular intervals, checkpoints make rewriting history before the last checkpoint computationally impossible, protecting against stake grinding and nothing-at-stake problems in Proof-of-Stake systems.

For light clients and new nodes, a checkpoint provides a trusted root (e.g., a block header hash) for Merkle proof verification. This enables efficient synchronization but requires the weak subjectivity assumption: the client must obtain a recent, honest checkpoint from a trusted source, introducing a bootstrap trust dependency.

If the entity responsible for publishing checkpoints (e.g., a foundation's multi-sig) is compromised, an attacker could publish a malicious checkpoint for a fraudulent chain. This is a catastrophic failure mode, as it could cause the network to accept invalid state. Defenses include using decentralized oracles or a large, diverse validator set for checkpoint signing.

Ethereum's consensus layer uses finalized checkpoints every 32 slots (approx. 6.4 minutes) via the Casper FFG protocol. A block becomes a checkpoint when it is the first block in an epoch. Finality requires a two-thirds supermajority of validators to attest across two consecutive epochs, balancing finality latency with robust security.

A cryptographic hash (typically a Merkle root) that commits to the entire state of the blockchain—including account balances and smart contract storage—at a specific block. Checkpoints use state roots to provide a verifiable anchor point for light clients and cross-chain bridges, enabling them to trustlessly verify proofs without downloading the full chain.

A security model in proof-of-stake systems where new or offline nodes must rely on a recent, cryptographically signed checkpoint (a weakly subjective checkpoint) to bootstrap securely. This prevents long-range attacks by establishing a trusted recent state from which the canonical chain can be objectively determined based on accumulated proof-of-stake.

A consensus mechanism component that provides finality guarantees, often by producing checkpoints. Examples include:

• Casper FFG: Overlays finality on a blockchain by periodically finalizing checkpoints (epoch blocks).
• GRANDPA: Used in Polkadot, it finalizes chains of blocks rather than individual blocks, creating finalized checkpoints. These gadgets ensure that a checkpoint, once finalized, cannot be reverted without slashing a large portion of staked assets.

A specific block that marks the end of an epoch—a fixed number of blocks in protocols like Ethereum 2.0. This block serves as a natural checkpoint where the validator set can be rotated, rewards are calculated, and the state root is finalized. It is the primary unit for the Casper FFG finality gadget to justify and finalize the chain's state.

The process where a resource-constrained client downloads only block headers and uses checkpoints to synchronize with the network. By trusting a recent, signed checkpoint header from a trusted source, the light client can efficiently verify subsequent block headers and request Merkle proofs for specific transactions or state data, without needing the full chain history.

A critical security mechanism for cross-chain bridges where a trusted set of relayers or a multi-sig submits checkpointed block headers from the source chain to the destination chain. These checkpoints allow the destination chain to verify the inclusion and validity of transactions or events that occurred on the source chain, forming the basis for atomic swaps and asset transfers.