Prysm 中的 Blob Sidecar 处理

Prysm 中的 Blob Sidecar 处理

背景

在 EIP4844 中，引入了 BlobsSidecar，用于接受需要在信标节点中持久化一段时间的 "blobs" 数据。这些 blobs 大幅度降低了 rollup 费用，并使以太坊能够在不牺牲去中心化的情况下保持竞争力。Blobs 在大约 1 个月后会被修剪掉，时间足够 L2 的所有参与者检索它们。Blobs 持久化在信标节点中，而不是在执行引擎中。与这些 blobs 一起，BeaconBlockBody 包含了一个新的字段 blob_kzg_commitments。重要的是，这些 kzg 承诺与 blob 内容相匹配。

请注意，在 CL 上，blobs 仅在 BeaconBlockBody 中被引用，而没有编码在 BeaconBlockBody 中。内容不是嵌入完整的内容，而是通过上面的 BlobsSidecar 单独传播。CL 必须正确地完成以下三件事：

• 信标链：处理更新的信标区块并确保 blobs 可用
• P2P 网络：传递和同步更新的信标区块类型和新的 blobs sidecars
• 诚实验证者：生成带有 blobs 的信标区块，发布 blobs sidecars

在本文档中，我们将探讨 BlobsSidecar 和 BeaconBlockBody 之间松散耦合的规范依赖性，以及由于它们松散耦合而导致的实现复杂性。

信标链处理

作为区块处理的一部分，添加了一个新的函数 process_blob_kzg_commitments。它确保 BeaconBlockBody 中的 kzg 承诺与区块交易中定义的 SignedBlobTransaction 中的哈希值匹配。给定原始交易，节点应该能够根据字段偏移量查找 blob 版本化的哈希值。在这个验证中，BlobsSidecar 不是必需的。信标节点可以 "乐观地" 处理区块。

P2P 网络处理

我们将分别查看 beacon_block 和 blobs_sidecar gossip 主题。

在 blobs_sidecar 中，如果 blobs 格式不正确（例如，BLSFieldElement 在无效范围内），并且 kzg 证明被错误地编码为压缩的 BLS G1 点，则节点将拒绝。最后，如果 sidecar 签名无效，它将拒绝。在接受 blobs 之前，最后一步是运行 validate_blobs_sidecar，它验证 sidecar 对象中的聚合证明。在此之前，还要进行一次快速验证，以确保 KZG 证明是正确编码的压缩 BLS G1 点。

在 beacon_block 中，节点将查看 BeaconBlockBody 中的 blob_kzg_commitments，如果 kzg 承诺被错误地编码为压缩的 BLS G1 点，并且这些承诺与交易列表中的版本化哈希不对应，则节点将拒绝该区块。

分叉选择处理

正如我们从信标链和 P2P 网络处理中看到的那样，可以独立处理每个对象。它们之间没有严格的依赖关系。这在分叉选择方面发生了变化。今天，客户端实现使用分叉选择存储来缓存有用的状态，例如 VALID，OPTIMISTIC，INVALID... 等。有了 EIP4844，分叉选择存储标记区块（即 protoarray 术语中的节点）数据是否可用（即具有有效的 sidecar）也将很有用。is_data_available 是一条重要的信息，旨在随着后续的分片升级而改变。is_data_available 检索给定 blob_kzg_commitments 的匹配 BlobsSidecar，并验证 sidecar 是否可靠。重要的是要注意，在 is_data_available 返回 true 之前，区块不能是 VALID。在此之前，该区块应仅被视为 OPTIMISTIC。鉴于这些约束，我们分析两种情况

1. 在 sidecar 之前收到区块

这是一个理想的情况。block（蓝色）在 sidecar（红色）之前收到。block 到达 p2p 服务，节点在传递给它的对等方之前验证该区块是否通过 p2p 条件，并将其发送到区块链服务，节点根据共识规则验证该区块，然后将其发送到分叉选择存储和 DB 以进行持久存储。

一旦区块缓存在分叉选择存储中，节点就可以验证 sidecar，然后将其发送到分叉选择存储，以使该区块具有有效的 sidecar 并在将其存储到 DB 中进行持久存储之前变为 VALID。总完成时间取决于两个对象之间的时间间隔，为了获得更好的性能，应尽量减小该时间间隔。

2. 在区块之前收到 Sidecar

这是一个棘手的情况。sidecar（灰色）在 block（蓝色）之前收到。在这种情况下，我们将 sidecar 存储在一个挂起的队列中，直到收到，处理该区块并存储在分叉选择存储中。总完成时间取决于区块何时到达

松散耦合的 sidecar 和 block 增加了上述场景的复杂性。

进一步考虑

• 通过检查点同步，节点可能必须请求 BeaconBlocksByRange 以进行回溯。在紧密耦合的世界中，我们不需要单独调用 BlobsSidecarsByRange
• 还有其他吗？

• 原文链接： hackmd.io/_3lpo0FzRNa1l7...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～