本文介绍了一种利用 Blob 实现以太坊历史数据分布式存储的简化方案。通过将区块内容存入 Blob，结合数据可用性抽样（DAS）与 ZK-EVM 证明，旨在实现仅凭轻量级节点即可验证全网。此外，文章还探讨了随机采样存储历史数据的可行性及负载计算，以及如何通过 Blob 记录访问列表来优化状态存储。
这篇文章将描述一种相当简单且集成良好的方法，用于实现以太坊历史的分布式存储，以及对存储状态的扩展。
第 1 步：将区块内容放入 Blob
我们将以太坊的历史放入 Blob 中。实现这一点自然的方法是使用一个函数 get_blobs(block_body) -> List[Blob]，它将区块主体序列化并将其拆分为 Blob。然后，我们要求区块头中 Blob 版本化哈希列表中的前几个 Blob 版本化哈希等于 [get_versioned_hash(blob) for blob in get_blobs(block.body)]。
为了方便起见，我们可以将 CL 主体的 Blob 与 EL 主体（即 ExecutionPayload）的 Blob 分开，这样我们就可以让 ZK-EVM 证明仅将这些版本化哈希作为公开见证者。这使得区块可以纯粹通过以下方式进行验证：
- 下载区块头
- 对 Blob 进行 DAS 检查
- 仅下载并直接验证 CL 部分
- 验证 ZK-EVM 证明
当完整的精简共识 (Lean Consensus) 功能引入时，CL 部分也将获得 ZK 证明，我们将实现通过仅检查区块头、DAS 和证明即可验证链的理想目标——完全的“智能手表上的可验证性”。
我们可以通过执行有效载荷分块并调整一些常量来使上述过程更简洁。特别是，如果我们 (i) 执行 EIP-7976 且对零和非零字节采用相同的 Gas 价格，以及 (ii) 在我们将 Blob 升级为抗量子（或甚至更早）时增加 Blob 大小，那么我们可以实现每个有效载荷分块都能装进一个 Blob (!!) 的保证。例如，如果我们通过 EIP-7825 将 Calldata 开销设置为每字节 64 Gas，我们就有一个硬性上限，即序列化交易在 256 kB 以下，因此如果我们设置 Blob 大小为 256 kB，我们就得到了这个保证。
我们还需要对区块级访问列表（access lists）执行相同的操作，包括确保硬性的“每字节 64 Gas”不变性反映在每个组件和组合中。
第 2 步：随机 Blob 历史存储
我们增加一条规则，即每个客户端必须存储其看到的每个 Blob 的一个随机选择的样本。如果我们：
- 将样本大小设置为 512 字节（从目前的 2048 字节缩小），以最大化 PeerDAS 带宽
- 假设每个 Slot 平均有激进的 64 个 256 kB 大小的 Blob (16 MB)，这足以让 L2 Blob 空间比现状增加约 20 倍，或者比当前 Gas 限制增加约 128 倍，或者是两者的混合
那么我们得到：
- 每个客户端存储每个 Blob 的 1/512，因此你需要约 710 个诚实节点（由于重叠而高于 512 个）存储 >= 50% 的 Blob，以便能够恢复所有 Blob。
- 每个客户端的负载（在激进的每个 Slot 128 个 Blob 下）将是
512 * 62 * 31556926 / 12 字节 = 每年 80 GB，这与强加给共识节点的合理额外负载大致相符
查询 Blob 可以通过重新利用现有的 DAS 机制，或者通过创建一个更针对同步过程进行优化的专用协议来完成。
第 3 步：增加存储
这实际上不需要任何工作。如果区块级访问列表包含在 Blob 中，那么你已经可以从你所知道的最新的状态（如果需要，可以是合并时的快照）同步 Blob，并重放更新以计算当前状态。如果需要，我们还可以添加一种“重复地从左到右遍历树”的机制，尽管目前尚不清楚其复杂性是否值得。
