面向所有人 / 它如何运作
结算与记录
每个区块的内容都按顺序发布，包括第 0 个区块，而以太坊始终持有数据本身，或对存放在别处、可获取的数据的一份提交。这正是让这条链可核对而非仅仅被断言的东西。
两层发布
| 层级 | 它持有什么 |
|---|---|
| 数据可用性层 | 完整载荷，每个区块一份内容寻址，以其哈希为键；排序器在依赖确认摘要之前先核验它 |
| 以太坊收件箱合约 | 一个点名该载荷的紧凑信封以每 60 秒一次的调度目标提交一次，blob 或 calldata 依据实测价格选择 |
| 后备 | 以 calldata 形式放在以太坊上的完整载荷每当数据可用性路径失败时采用，所以链在中断期间仍可推导 |
想象一家商店把每张收据都存在档案室里，并且每分钟给银行寄一份封好的摘要，说「这是我刚 归档的收据的指纹」。银行无法从指纹读出收据的内容，但任何进入档案室的人都能核对没有东西 被改动过。而如果档案室一时无法进入，商店就改为把收据本身寄给银行。Pickle 的排序器是这家 商店，数据可用性层是档案室，以太坊是银行。
每个封存的区块生成一份派生载荷，携带其完整交易列表。载荷存入一个内容 寻址的数据可用性层，以其哈希为键，排序器在依赖它之前先核验确认。随后，一个点名该载荷的 紧凑信封被提交到以太坊上的收件箱合约。如果数据可用性路径因任何原因 失败，就改为把完整载荷以 calldata 形式发布到以太坊。
每个区块都按顺序发布，包括第 0 个区块。收件箱合约只接受来自指定批处理密钥的追加，并为 每一批发出一个带索引的事件；这个索引就是每个验证者所遵循的全序。
载荷携带区块的完整交易列表，连同区块范围、父哈希、区块哈希和已承诺的时间戳；之所以包含 时间戳，是因为它不仅是区块头的一部分，也是执行环境的一部分，副本节点必须依据同一时钟执行 才能封存出同一哈希。发布分两层：载荷以其哈希存入内容寻址存储，确认时核验摘要；信封则按 每个聚合窗口提交到 L1 收件箱合约。收件箱合约由批处理器把关，每次追加发出一个带索引的 事件。提交工具是 blob 还是 calldata，每次提交时依据实测价格选择，因为在这样的载荷大小下， blob 费用低时执行 gas 占主导，费用高时纯 calldata 更划算。
载荷携带什么
- 区块的完整交易列表，所以关于这个区块没有任何东西需要被信任。
- 区块范围、父哈希和区块哈希，所以副本节点知道它处于何处，以及必须复现什么。
- 已承诺的时间戳，因为读取时钟的交易看到的是那个值，而依据另一个时钟执行的副本节点会封存出 另一个哈希。
为什么每个窗口只提交一次
以太坊并不会为每个封存的区块收到一笔交易。完整数据按每个区块进入数据可用性层；而以太坊则按 每个聚合窗口收到一份提交，以 60 秒为调度目标。正是聚合让模型化的结算成本 保持在每年数百万美元的低位，而不是逐区块发布的设计会招致的数千万乃至数亿美元。限制页面给出了模型化的区间及其所依赖的假设。
独立验证
任何运营者都可以把同一个二进制程序作为副本节点运行。它不产出任何东西。它从 上次应用的索引开始读取以太坊收件箱合约，按内容地址获取每份载荷或解码内联的 calldata 后备， 依据已承诺的时间戳按顺序重新执行每一笔交易，在本地封存区块，并把哈希与排序器提交的哈希比对。
遇到任何不匹配，副本节点永久停机
分歧在设计上是终止性的：重试会封存更多区块并偏离规范链，把原因埋掉。一个停机的副本节点 就是已发布数据与已提交哈希不一致的信号。链上没有任何东西仲裁这一不一致；信任模型页面说明了由此推出什么。
已同步的副本节点从自己独立推导出的状态提供标准的读取 RPC。它的余额、回执和区块头都是本地 重新推导的，而不是排序器答案的可信副本。交易提交会转发给排序器；副本节点不接受任何东西进入 本地内存池。
历史从哪里读取
排序器针对回答当前状态做了优化，只保留最近区块的一小段窗口。完整历史被索引进浏览器的数据库， 由排序器持续供给，任何历史性的问题都在那里回答。两者都处在同一批已发布载荷的下游，副本节点仅凭以太坊和数据可用性层就能重建 其中任一个。