多数 Rollup 把执行数据和状态承诺都交给同一个以太坊：blob 上 L1、证明也在 L1 验。Eclipse 把这条链拆成三段：执行交给自己的排序器，交易数据交给 Celestia，可验证性靠锚定到以太坊的批头承诺。它的数据通路因此变成执行归执行、数据归数据、锚定归锚定。本文按 Eclipse 官方文档拆这条路径，并说明三层各自回答什么问题。
数据通路长什么样
文档把 Celestia Publisher 描述为执行层与数据可用性层之间的第一座桥：它从 Eclipse 排序器持续取块，先写进本地数据库建索引，用 zstd 压缩（文档标注压缩等级 3）并成批，再把逐块 blob 提交给 Celestia，换回 span sequence 数据；随后为一个批次范围提交一份索引 blob，最后创建 BatchHeader，把 span sequence 的承诺锚定到以太坊。这条流水线的目标被文档写成让执行与数据可用性解耦：数据搬到带宽更合适的层，可验证性靠锚在以太坊上的批头兜底，文档称之为强可重建性保证。
三层各答一个问题
数据可用性回答的问题是这份数据发布了吗。Eclipse 文档引用通行定义：节点收到新区块时尝试下载全部交易数据，下得动就算验证了可用性——数据至少被发布出来，任何人都能拿它重建链。这里的验证对象是数据可得性本身，不是每笔交易的业务对错，两者不要混谈。执行层负责排序与执行，排序器把交易持续装进 Eclipse 块；压缩、成批与提交 blob 是发布通路的活，不改变执行语义。结算层负责回答哪条是规范链：Eclipse 把验证桥内建进基础设施，并运行以太坊全节点，把以太坊上的记录作为规范链依据，让所有 Eclipse 节点认同一份历史。三层分别回答：交易怎么排、数据在哪查、正统以谁为准。
这跟托委员会的路线有什么不同
把数据挪出以太坊并不自动等于安全，差别在锚定了什么、谁负责让数据可取。数据可用性委员会路线里，链下委员会给数据背书，若委员会合谋不发布数据，用户可能取不到重建链所需的输入，提款通道也可能因此延迟。Eclipse 的做法是把数据放在一条独立出块的 DA 链上，同时把每批数据的承诺用 BatchHeader 写进以太坊——批头在以太坊上留了底，数据承诺就有了一份不依赖 DA 链自身意愿的公开记录；即便排序器更替或停摆，历史数据仍可凭链上锚点与 DA 链上的 blob 重建，新运营方接手时也有明确的账本起点。要分清两件事：批头证明的是某段数据被承诺过，某一批数据此刻能不能取到，仍取决于 DA 链自身的可用性状态——这是三层模型必须分开核对的地方，不能因为锚定在以太坊上就默认数据永远随手可查。
核对一笔状态要看三个地方
这种架构的代价是链路变长。想确认一笔交易真实有效，对应三条查询：在 Eclipse 侧看块与执行结果，确认排序器给出的顺序与回执；在 Celestia 侧按批头里的 span sequence 信息定位 blob，确认原始交易数据确实发布过；在以太坊侧看 BatchHeader 与桥的合约记录，确认这条记录属于规范链。任何一段滞后或故障，都会在交易状态这类单一问题上表现出不同形态的卡住：桥确认了但 blob 暂时拉不动、数据可查但批头还没锚定，处理顺序完全不同。排查时先定位断点在哪一层，比笼统地问交易有没有成功更有效。
另外，Eclipse 文档对以太坊带宽与 EIP-4844 的动机表述写于当时的技术背景，不能拿来推断现在的参数或费用水平；可以确认的是官方文档对架构分工本身的描述。本文只陈述机制与分工，不构成对任何链性能或安全性的判断，也不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。