先软确认再等数据层盖章:主权 Rollup 节点的两级终局 图 1
先软确认再等数据层盖章:主权 Rollup 节点的两级终局 · 图 1

一条用模块化框架搭起来的链,往往没有以太坊这样的一层给自己做裁判,它的终局要靠外部的数据可用性层背书。Rollkit 官方文档把这类主权 Rollup 的终局描述成两个阶段:先是排序器把区块通过点对点网络广播出去,所有看到的人得到软确认;随后区块内容被提交到数据可用性层,确认包含之后才算终局。理解这两级各自担保什么,是在这类链上判断一笔交易何时算数的基础。

第一级:广播即软确认

软确认发生在区块被生产并通过 P2P 网络 gossip 的时刻,延迟就是区块时间本身,量级在毫秒到秒级。官方文档对这一级的担保描述很克制:排序器已经承诺了这个顺序,风险是排序器可能出尔反尔,生产两个互相冲突的区块。也就是说软确认给的是一个可撤回的排序承诺——只要排序器不再抵赖,它会变成第二级;如果它试图抵赖,节点还能从数据层拿到的权威序列里发现并纠正。对展示余额、提示已提交这类场景,这一级通常够用;但它是信任排序器行为的信任态,不是密码学意义上的不可逆。

第二级:数据层盖章之后

示意

第二级是 DA finalized:数据可用性层确认区块被包含进来。Rollkit 文档给出的担保措辞是数据永久可用且排序确定,并配有一条前提——假设数据层本身安全。此时区块的归属和顺序已经被外部链锚定,排序器单方面改写顺序不再可能。文档对延迟的说明分两个口径:终局概念页以 Celestia 为例写约六秒,数据可用性概念页写约十二秒到终局,两处数值不一致,说明这类秒级参数会随版本与配置变化,读者应以自己部署所用版本文档和实时数据层状态为准,不要把任何固定秒数当作合同。

头与数据分家:两个命名空间

Rollkit 把区块头与交易数据放进数据层的两个不同命名空间分别提交,官方文档里的清单是 Header 与 Data 两类。分家的意义在轻量的验证路径:只关心链在哪、长度多少的观察者可以只跟头部流,需要重放执行的人再去拉数据流。这带来一个独特的失败面——数据可能暂时缺席而头部仍在增长。文档在数据可用性一节明确写了提交器(Submitter)的角色:区块生产后排队进入 DA 提交流程,数据层负责存储与排序,全节点再据此取回并验证。

节点怎么凭这些重建链

把这几点合起来,一个主权 Rollup 全节点的同步逻辑就是:沿数据层读回按序提交的区块头,验证头与头之间的连续性与签名,再取对应命名空间里的事件与交易数据喂给自己的执行引擎逐块重放,重建出与生产者一致的状态。软确认和终局在这里汇合:重放时以数据层序列为准,凡与已确认序列冲突的软确认分支被丢弃。数据缺席时节点可以追到最近一段确认可用的头为止,等数据补齐再继续。想判断节点追到哪一级,看它的头是从 gossip 来的还是从数据层确认来的即可。

按场景选终局档位

Rollkit 文档给运维者的建议可以直接翻译成用户习惯:展示余额、接收小额付款用软确认即可;处理提现与跨桥转移要等数据层终局。两者的信任假设不同,前者信排序器不作恶,后者信数据层安全加提交器诚实。还要区分一类容易混淆的部署:框架也提供仅供本地开发测试的本地数据可用性模式,官方文档写明这种模式担保为零,操作方可以扣留数据,它出现的意义是让你在一台机器上模拟整条链,绝不能与生产部署混为一谈。最后提醒:本文解释机制与信任边界,不构成投资建议;涉及秒级延迟与参数差异时,请以你所用链的实时文档与数据层状态为准。