Checkpoints on Sui

Checkpoints are equivalent to blocks on Sui. However, this analogy is very relative since Sui has no blocks. Checkpoints are formed AFTER, not before, transactions run, which makes them milestones by which the history of the Sui Network can be tracked rather than actual blocks as structural units of the blockchain (perhaps this is the reason why Sui founders prefer the term "network" to "blockchain"). Thanks to checkpoints, validators, and full nodes get synchronized with the Network.

A checkpoint should contain the following:

• the cryptographic hash of the previous checkpoint;
• a list of all the digests of the transactions included therein;
• a set of signatures from a quorum (more than 2/3rds) of the validators that formed the committee at the moment the checkpoint was created.

Checkpoint Verification Process

How can a validator or a full node be sure that a checkpoint is valid and contains correct data? That's when checkpoint verification comes into play. Validating checkpoints allows the client to determine the committee’s composition, as each epoch’s final checkpoint contains the next epoch’s validator committee. This process appears to create a circular dependency: the client needs the committee to verify checkpoints, which in turn reveals the committee for each epoch. This issue is resolved by bootstrapping from the Genesis checkpoint containing the initial validator committee, which allows a client to verify all checkpoints up to the present.

Checkpoint verification involves two interdependent components:

1. If the Full node (or other client) possesses the public keys of the checkpoint’s validator committee, it can validate the checkpoint’s signatures.
2. Checkpoints are signed by the aggregated BLS signatures of a committee quorum. Valid signatures confirm the checkpoint’s creation by the validator committee.

Checkpoint verification runs as follows:

1. A client (a validator or a full node) obtains the Genesis checkpoint from a trusted source.
2. The client loads the initial committee from the Genesis checkpoint.
3. The client uses the state sync network or Sui archive to obtain the next checkpoint.
4. The client verifies the checkpoint’s signatures using the current committee’s public keys and checks that the checkpoint’s previous checkpoint hash matches the hash of the previously validated checkpoint.

4.1. If the checkpoint is invalid, an error comes up.

4.2. If the checkpoint is the last one of the current epoch, the client loads the next committee from it.

4.3. If not, the process returns to step 3.

Checkpoint verification is critical to maintain the Sui Network's consistency and integrity.