Prysm 中的 Blob Sidecar 处理

本文档探讨了EIP4844中BlobsSidecarBeaconBlockBody之间的规范依赖关系,以及由于它们之间的松散耦合而导致的实现复杂性。着重分析了信标链处理、P2P网络处理和分叉选择处理中遇到的问题,特别是当sidecarblock之前接收到时的情况,并提出了进一步的考虑。

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

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

信标链处理

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

P2P 网络处理

我们将分别查看 beacon_blockblobs_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 网络处理中看到的那样,可以独立处理每个对象。它们之间没有严格的依赖关系。这在分叉选择方面发生了变化。今天,客户端实现使用分叉选择存储来缓存有用的状态,例如 VALIDOPTIMISTICINVALID... 等。有了 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。总完成时间取决于两个对象之间的时间间隔,为了获得更好的性能,应尽量减小该时间间隔。

  1. 在区块之前收到 Sidecar

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

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

进一步考虑

  • 通过检查点同步,节点可能必须请求 BeaconBlocksByRange 以进行回溯。在紧密耦合的世界中,我们不需要单独调用 BlobsSidecarsByRange
  • 还有其他吗?
  • 原文链接: hackmd.io/_3lpo0FzRNa1l7...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
_3lpo0FzRNa1l7XB0ELH7Q
_3lpo0FzRNa1l7XB0ELH7Q
江湖只有他的大名,没有他的介绍。