Skip to main content

Checkpoint Verification

Checkpoints contain:

  • The cryptographic hash of the previous checkpoint
  • A list of all transaction digests and their corresponding transaction effects digests included in the checkpoint
  • A set of signatures from a quorum (more than two-thirds) of the validators that formed the committee when the checkpoint was created

Validators and full nodes consume checkpoints to remain synchronized with the network.

Verifying checkpoints​

Full nodes and validators verify a checkpoint to trust it. This verification confirms that the Sui validator committee created it and that it is authentic.

Checkpoint verification requires two interdependent steps:

  1. A client that has the public keys of the validator committee can check the signatures on the checkpoint. Checkpoints are signed by the aggregated BLS signatures of a quorum of the committee. If the signatures are valid, the client knows the checkpoint was created by the validator committee and not another party.
  2. By validating checkpoints, the client can learn the composition of the committee. The final checkpoint of each epoch contains the validator committee, including the public keys, of the next epoch.

This process creates an apparent circular dependency. The client needs to know the committee to verify checkpoints, but also learns the committee through checkpoint validation. The process is bootstrapped from the genesis checkpoint, the earliest checkpoint in a Sui network. The genesis checkpoint contains the initial validator committee, which allows the client to verify all checkpoints in history by following this process:

  1. Obtain the genesis checkpoint from a trusted source.
  2. Load the initial committee from the genesis checkpoint.
  3. Use the state sync network or Sui archive to obtain the next checkpoint.
  4. Verify the checkpoint signatures using the current committee's public keys, and confirm that the checkpoint’s previous hash matches the last validated checkpoint hash.
  5. If the checkpoint is invalid, raise an error.
  6. If valid, check whether the checkpoint is the last in the current epoch:
    • If so, load the next committee and use it as the current committee.
    • If not, return to step 3 and continue.

This process allows the client to verify all checkpoints up to the present time.

Checkpoint commitments​

After a client verifies a checkpoint, it can use the information to execute transactions and confirm results.

A checkpoint contains a list of transactions, so a full node can fetch and execute them. Because transactions are identified by their digest (a cryptographic hash), the client can be sure they have not been altered.

The checkpoint also includes the effects digests of each transaction. An effects digest is the cryptographic hash of the TransactionEffects structure, which lists all transaction inputs and outputs, including the digests of all objects written by the transaction. This allows a full node to confirm it has the same execution results as the validators who signed the checkpoint.

By executing checkpoints and verifying transaction outputs, a full node can build the entire state of the Sui network—the collection of objects in the network—and trust that every byte of every object is correct.