检查点验证
在 Sui 网络上，检查点定义了区块链的历史。它们与传统区块链（如比特币或以太坊）使用的区块概念非常相似。然而，Sui 区块链在事务执行后形成检查点，以提供链的已认证历史，而不是在执行之前形成。
检查点包含：
- 上一个检查点的密码哈希。
- 包含在检查点中的所有事务摘要（以及相应的事务效果摘要）的列表。
- 在创建检查点时形成委员会的验证者中超过 2/3 的验证者的签名集。
验证者和全节点都使用检查点来保持与网络同步。
检查点验证
为了使全节点和验证者信任检查点，它们必须首先验证它。验证确保检查点是由 Sui 验证者委员会创建的真实检查点。
检查点验证需要两个相互依赖的部分：
假设全节点（或其他客户端）具有创建检查点的验证者委员会的公钥，它可以检查检查点上的签名的有效性。
检查点由委员会的聚合 BLS 签名签名。 如果签名有效，则客户端现在知道检查点是由验证者委员会创建的，而不是由其他某方创建的。
通过验证检查点，客户端可以确定委员会的组成，因为每个时期的最终检查点包含下个时期的验证者委员会（包括公钥）。
这些部分似乎会创建循环依赖问题。客户端需要知道委员会以验证检查点，反过来，它可以了解每个时期的委员会是什么。为了解决这个问题，该过程是通过从创世检查点开始引导的，创世检查点是 Sui 网络中最早的检查点。创世检查点包含初始验证者委员会，这允许客户端通过以下过程验证历史上的所有检查点：
- 客户端从某个可信的源获得创世检查点。
- 客户端加载创世检查点中的初始委员会。
- 客户端使用状态同步网络或 Sui 存档获取下一个检查点。
- 客户端使用当前委员会的公钥验证检查点上的签名，并验证检查点的上一个检查点哈希等于客户端验证的上一个检查点的哈希。
- 如果检查点无效，则引发错误。
- 否则，客户端检查检查点是否是当前时期的最后一个。
- 如果是，从中加载下一个委员会，并将该委员会用作当前委员会。
- 如果不是，返回到步骤 3 并继续。
这允许客户端最终验证直到当前时间的所有检查点。
检查点承诺了什么？
在客户端验证了检查点后，它可以对该信息执行什么操作？
如前所述，检查点包含了事务列表，因此全节点可以开始获取和执行这些事务。由于事务由其摘要（密码哈希）标识，因此客户端可以确保它执行的事务未被更改。
此外，检查点还包含每个事务的效果摘要。效果摘要是 TransactionEffects 的密码哈希，它本身是一个列出事务的所有输入和输出的结构。它包括由事务编写的所有对象的摘要。
这使得全节点可以验证它已经获得了与验证者在签署检查点时所证明的执行结果相同的结果。
通过执行检查点并验证事务输出，全节点可以构建起 Sui 网络的整个状态（即网络中的所有对象），并相信每个对象的每个字节都是正确的。