本文将介绍一种相当简单且集成良好的以太坊历史记录分布式存储方法，以及对状态存储的扩展。
步骤 1：将块内容放入 blob 中
我们将以太坊的历史记录放入 blob 中。实现这一目标的自然方法是使用一个函数get_blobs(block_body) -> List[Blob] ，该函数序列化The Block主体并将其拆分为 blob。然后，我们要求区块头 blob 版本化哈希列表中的第一个 blob 版本化哈希等于[get_versioned_hash(blob) for blob in get_blobs(block.body)] 。
为了方便起见，我们可以将精简共识（CL）主体的二进制数据块（blob）与执行有效负载（EL）主体的二进制数据块（即ExecutionPayload ）分开，这样，零知识证明执行验证（ZK-EVM）证明就可以只包含这些版本化的哈希值作为公共见证。这使得区块的验证可以完全通过以下步骤完成：（i）下载区块头；（ii）对二进制数据块进行分布式哈希验证（DAS）；（iii）仅下载并直接验证精简共识部分；（iv）验证零知识证明执行验证。当精简共识的完整功能引入后，精简共识部分也将获得零知识证明，届时我们将拥有一个完整的“区块头、分布式哈希验证和证明”链。
我们可以通过有效载荷分块和调整一些常量来简化上述代码。具体来说，如果我们 (i) 执行EIP-7976并对零字节和非零字节使用相同的 gas 价格，以及 (ii) 在将 blob 升级为抗量子传输时（甚至更早）增加 blob 的大小，那么我们就可以保证每个有效载荷块都能装入一个 blob 中（！！）。例如，如果我们把 calldata 的成本设置为每字节 64 gas，那么根据EIP-7825 ，序列化交易的大小上限为 256 kB，因此如果我们把 blob 的大小设置为 256 kB，就能得到这个保证。
我们还需要对块级访问列表执行相同的操作，包括确保每个组件和组合都体现出“每字节 64 gas”的硬性不变性。
步骤 2：随机 blob 历史记录存储
我们添加一条规则，要求每个客户端必须存储其看到的每个数据块中随机选择的一个样本。如果我们：
- 将样本大小设置为 512 字节（较当前的 2048 字节有所减少），以最大化 PeerDAS 带宽。
- 假设每个插槽平均有 64 个 256 kB 大小的 blob（16 MB），这足以使 L2 blob 空间比现状增加约 20 倍，或使当前 gas 限制增加约 128 倍，或者两者兼而有之。
然后我们得到：
- 每个客户端存储每个 blob 的 1/512，因此需要约 710 个诚实节点（由于重叠，需要超过 512 个）来存储 >= 50% 的 blob，才能恢复所有 blob。
- 每个客户端的负载（假设每个槽位处理 128 个数据块）将为
512 * 62 * 31556926 / 12字节 = 80 GB/年，这与对共识节点施加的合理额外负载大致相当。
可以通过重新利用现有的 DAS 机制来查询 blob，也可以通过创建更适合同步过程的专用协议来查询。
步骤 3：添加存储空间
实际上，这不需要任何额外工作。如果数据块中包含块级访问列表，那么就可以从已知的最新状态（如果需要，可以使用合并时的快照）同步数据块，并重放更新以计算当前状态。如果需要，我们还可以添加一个“从左到右重复遍历树”的机制，但目前尚不清楚这样做是否值得增加复杂性。
