Sui 为什么没有区块：检查点在执行之后创建，纪元把四件事钉死

在 Sui 的网络里，严格来说不存在与以太坊或比特币同构的块。共识定序、交易执行与历史记录是三道分开的工序，串起它们的单位叫检查点（checkpoint）：官方定义里，检查点在执行之后创建，为链历史提供一份认证记录，内含已定局的交易，用于节点同步与全局交易排序。理解这个先后顺序——先有执行，后有记录——是理解 Sui 与多数链结构差异的钥匙。

检查点的字段账

Sui 的 GraphQL 参考文档列出检查点的核心字段。每个检查点有顺序号，也有一个由摘要哈希得来的标识符，并用前一个检查点的摘要把彼此串成链——这条摘要接力让任何一段历史一旦写定就难以被局部篡改。它记录到这个检查点为止全网累计交易数，让新节点一眼判断自己追到哪。它带时间戳，携带一份滚动的燃气摘要，聚合了委员会对该检查点产物的签名，并标明自己属于哪个纪元。执行产生的对象状态变化在检查点之前就已由交易证书定局，检查点只是把这些已成定局的事实装订成册，而不是像传统链那样先装订再执行。

纪元内钉死的四件事

Sui 的活动按时间切成纪元。官方文档明确，检查点之间的纪元边界是网络自我重组的机会：执行协议或系统包升级、更换验证者委员会、分发质押奖励。在一个纪元内部，四项数据被钉死：协议版本、参考燃气价、系统包版本与委员会成员。这条规则带来一个很实用的推论——同一纪元内，交易执行费的计价基准与谁在担保历史是一致的；跨越纪元边界时，这些基准可能整体切换。系统的网络配置也会大致保持各纪元时长接近，让边界成为一个可预期的事件而不是随机噪声。

全节点如何靠检查点建状态

官方的检查点验证文档描述了信任路径：全节点执行每个检查点里的交易并核对输出，由此构建整个网络的对象集合，并且相信每个对象每个字节都正确——因为每笔交易进入检查点时已经带着委员会签发的证书。这与比特币轻客户端验证工作量、以太坊信标链验证检查点签名是三种不同的信任锚：Sui 把锚放在每笔交易的证书与每册检查点的委员会聚合签名上。对同步而言，检查点同样是抓取单元：落后的节点按顺序号拉检查点、重放执行，追平后转入实时流水线。

对开发者的三个观察面

第一，把检查点当块用要小心语义：检查点的顺序号统计的是装订批次，不是共识轮次，依赖类逻辑（比如按批次计息）应当用时间戳或交易自带的事件来对齐。第二，跨纪元的假设要重置：参考燃气价在纪元边界可能跳变，用旧纪元价格做长期预估会失准。第三，历史校验走证书路径：需要向第三方证明某笔交易发生过，给检查点摘要、顺序号与该交易证书，验证者就能在委员会公钥集合下复算，而不需要对方自己同步全链。检查点被裁剪的历史无法这样复核，长期留证要提前归档。另一个细节是拒绝清单这类系统对象：官方文档注明对受监管代币的写入只在下一个纪元边界生效，因此某笔交易受不受清单约束，取决于它所在纪元起点处的清单状态——这同样是纪元作为配置单元的体现。

风险提示：本文为机制解释，不构成投资建议；协议处于持续演进中，具体字段与规则以官方文档为准。