尧图网站建设 
EIP-8094 eth/vhash面向 Blob 感知的以太坊 Mempool 协议设计全解读【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-8094eth/vhash - Blob-Aware Mempool 是一份处于 Draft 状态的以太坊网络层Networking 类别标准提案目标是让 devp2peth协议的 mempool 消息具备vhash 感知能力——即通过 blob 内容哈希versioned hash来寻址交易侧边车sidecar中的 blob 数据。读完本文你将理解当前 blob 交易在 RBFreplace-by-fee费用替换场景下带宽浪费的根源、该提案引入的GetPooledBlobs/PooledBlobs消息设计、三种实现路径的取舍以及它与 EIP-7642、EIP-8077、EIP-8070 等协议的协同关系。背景为什么 blob 交易的 RBF 在网络上是昂贵的以太坊 blob 交易的 sidecar 传播模型要理解 EIP-8094 的动机需要先回顾 blob 交易的传播机制。在 EIP-4844 的设计中blob 数据并不嵌入交易主体而是作为sidecar单独传播Instead of embedding the full contents in the body, the blobs are propagated separately, as sidecars.交易的网络层包装格式为rlp([tx_payload_body, blobs, commitments, proofs])见 EIP-4844 规范其中blobs是 blob 数据列表commitments是对应的 KZG 承诺proofs是对应的 KZG 证明节点必须验证kzg_to_versioned_hash(commitments[i]) tx_payload_body.blob_versioned_hashes[i]才能确认包装数据与交易主体一致见 EIP-4844 验证规则。关键在传播规则。EIP-4844 明确规定Nodes MUST NOT automatically broadcast blob transactions to their peers. Instead, those transactions are only announced usingNewPooledTransactionHashesmessages, and can then be manually requested viaGetPooledTransactions.见 EIP-4844 网络层规则也就是说blob 交易默认不走急切推送路径而是先公告、再按需拉取完整内容。问题费用波动期的重复带宽消耗EIP-8094 的 Motivation 指出在当前 devp2peth/69协议下eth/69由 EIP-7642 定义该 EIP 的requires字段即指向它当一笔交易被替换RBF时它必须像任何新交易一样在 mempool 中重新分发。即使替换前后的实际内容blob 数据几乎完全一样协议参与者也没有任何手段在拿到完整内容之前判断这个新公告对应的 blob 内容我是否已经有了于是每一次替换都消耗与全新交易等量的网络资源。而最麻烦的地方在于RBF 恰恰在费率剧烈波动的时期使用最频繁而网络过载正是这种波动期的典型形态。也就是说在本来就高负载的时候协议反而会因为重复分发已经分发过的 blob 内容而雪上加霜。这正是该提案的核心切入点如果替换只改了费用元数据而 blob 内容未变就应该让网络无需重新传输 blob 内容。核心思路用 vhash内容哈希寻址 blob提案的名字eth/vhash点明了核心设计修改 devp2peth协议使类型 3blob-carrying交易 sidecar 中的 blob 能够通过内容哈希来寻址。这里的 vhash 即 EIP-4844 中定义的 versioned hashkzg_to_versioned_hash(commitment)取 KZG 承诺的 SHA256 哈希并覆写版本字节见 EIP-4844 定义。由于 vhash 是 blob 内容的确定性指纹它天然具备两个特性内容不变则 vhash 不变RBF 只改费用时sidecar 的 vhash 集合保持不变接收方可以据此判断这些 blob 我已有缓存无需再拉已经标准化vhash 在共识层和 CL 侧早已是成熟标识符只是尚未进入 devp2p 消息层。规范详解SpecificationEIP-8094 的规范由四部分组成两条既有消息的修改、两条新消息的引入以及一条对 EIP-4844 传播规则的修订。注意新消息的消息码msg code在提案中仍标注为-- TODO --等待后续分配。1.Transactions (0x02)消息变更类型 3 交易在通过Transactions消息传输时应should不带 sidecar 发送Transactions (0x02) changes: Type 3 transaction should be sent without sidecar2.PooledTransactions (0x0a)消息变更同理PooledTransactions消息中的类型 3 交易也应不带 sidecar 发送PooledTransactions (0x0a) changes: Type 3 transaction should be sent without sidecar这两条修改的目的是一致的让交易主体含费用字段与blob 内容在消息层解耦为后续按 vhash 单独拉取 blob 铺路。值得注意的是这与 EIP-8070Sparse Blobpool 的方向相呼应——后者在GetPooledTransactions/PooledTransactions中要求将 blob 字段编码为 RLP 空列表0xc0只保留 commitments 与 proofs而 EIP-8094 走得更远直接让 blob 内容通过专门的新消息按 vhash 请求。3. 新消息GetPooledBlobs消息码待分配[request-id: P, [vhash₁: B_32, vhash₂: B_32, ...]]该消息从接收方的交易池中按 vhash 请求 blob格式包含一个请求 ID 和 vhash 列表每个 vhash 为 32 字节即B_32。request-id用于关联请求与响应这也是 devp2p 支持并发请求与乱序响应的常规机制EIP-8070 的 Rationale 中同样提到了基于request_id关联的并发请求设计。4. 新消息PooledBlobs消息码待分配[request-id: P, [blob₁, blob₂...]]这是GetPooledBlobs的响应消息返回请求的 blob 列表格式沿用主以太坊规范即 EIP-4844中的 blob 定义。规范还明确了三条关键约束顺序一致、允许跳过返回的 blob 必须与请求中的 vhash 顺序一致但可以跳过本地不可用的 blob。由于接收方无论如何都必须校验传输的 blob 哈希与请求的 vhash 对应响应消息中不需要再附带 vhash 列表可选优化一前缀版本号可以在 blob 格式前加上 blob 版本号可选优化二重建友好的 blob 格式允许节点用更少的带宽重建 RSReed-Solomon擦除编码而不是传输完整编码。每个 blob 可发送以下字段blob 版本blob versionblob 内容version 1 时排除擦除编码扩展部分blob 承诺blob commitmentblob 证明blob proof(s)version 1 时包含擦除编码片的 cell proofs提案特别强调必须包含所有 cell proofs以保证重建过程 CPU 高效。从实现背景可以推断这里提到的擦除编码扩展 / cell proofs对应的是 PeerDAS 方向的列采样体系EIP-8070 即依赖该体系其参数表中包含CELLS_PER_EXT_BLOB与 64 cells 的 RS 解码阈值。该可选项的目的是把网络带宽换 CPU变成CPU 换带宽让有能力的节点自行重建。可选优化三发送位图可以在响应中附带已发送/未发送 blob 的位图bitmap或附上已发送的 vhash 列表。提案明确指出这是冗余信息但可以简化接收端的处理逻辑。5. 对 EIP-4844 传播规则的修订提案要求修订 EIP-4844 中不得自动广播 blob 交易的规则。原规则为Nodes MUST NOT automatically broadcast blob transactions to their peers. Instead, those transactions are only announced usingNewPooledTransactionHashesmessages, and can then be manually requested viaGetPooledTransactions.修订后的规则为Nodes MUST send (broadcast or send inNewPooledTransactionHashes) blob transactionwithoutsidecars to their peers. Peers can then request blob content usingGetPooledBlobsmessages. Nodes MUST NOT forward blob transactions before receiving and validating all blobs.对比可见三处关键变化从禁止广播变为允许不带 sidecar 广播交易主体含费用、nonce、vhash 列表等元数据可以通过Transactions消息急切推送也可以走NewPooledTransactionHashes公告blob 内容改为通过GetPooledBlobs显式请求接收方按 vhash 决定要拉哪些 blob这是实现跳过已有内容的机制基础新增转发前置条件节点在接收并验证所有 blob 之前不得转发 blob 交易这保证了内容可验证性不被破坏。设计取舍Rationale为什么用 blob 级 vhash 而不是 sidecar 级哈希提案明确讨论过两种标识符方案使用单个 sidecar 级哈希优点是单一元素、消息格式简单或者使用 blob 级 vhash。最终选择 vhash理由有二sidecar 级哈希是全新标识符而 blob 级 vhash 已经非常成熟只是尚未进入 devp2pblob 级寻址允许重组消息例如在费率飙升时可以只发送部分 blob粒度更细、更灵活。因此使用 vhashes。三种实现选项的比较提案系统性地比较了把 vhash 引入 devp2p 消息的三条路径选项思路评价Option 1在公告中扩展 vhash允许节点请求带/不带 sidecar 的交易甚至通过 bitmap 或 vhash 列表选择需要哪些部分粒度最细但公告与请求消息的复杂度最高Option 2公告扩展 nonce见 EIP-8077若交易哈希与自己已有不同则根据是否已拥有同一 nonce 的 sidecar决定是否带 sidecar 请求假设是简单替换若 vhash 确实不同再重新带 sidecar 请求依赖同 nonce 即替换的假设存在二次请求的额外 RTTOption 3选定推送或公告后拉取不带 sidecar的类型 3 交易允许单独请求 sidecar新增消息类型设计最简单、最直接从表面看Option 3 似乎会在每一跳增加一个 RTT 延迟。但提案给出了关键反驳大多数类型 3 交易在没有 sidecar 时非常小因此可以改变协议行为允许直接推送不带 sidecar 的交易由推送的接收方在需要时主动请求 blob。而在 sidecar 被拉取并验证内容之前禁止转发类型 3 交易这条规则保证了内容验证链不被破坏。综合权衡后提案选择 Option 3引入新的消息类型即GetPooledBlobs/PooledBlobs。与其他 Draft 状态 EIP 的关系EIP-8077eth/XX公告携带 source 与 nonce该提案扩展NewPooledTransactionHashes (0x08)消息在原有[txtypes, txsize, txhash]基础上追加txsourceB_20与txnonceP字段。它与 EIP-8094 的变更互不冲突可以简单组合EIP-8070Sparse Blobpool两个提案都改变 blob 交易在网络的传播方式但目标不同——EIP-8070 致力于在正常情况下按比例削减带宽通过 p0.15 的整包拉取概率与其余情况的列采样并不处理 RBF 的细节EIP-8094 则专注于让RBF 不消耗额外带宽。两者可以组合但组合方式取决于引入顺序因此提案将其留待后续决定标注-- TODO --。此外从仓库中的 EIP-8081Hegotá 网络升级 Meta EIP 可以看到EIP-8094 与 EIP-8077 同被列为 Hegotá 升级的Proposed for Inclusion候选说明两个提案正被一同推进评估。向后兼容性EIP-8094 明确了两点兼容性结论该提案修改eth协议需要推出新版本参照 EIP-7642 引入eth/69的先例。支持多个 wire protocol 版本是客户端常规做法推出新版本不会破坏旧客户端——它们可以继续使用旧协议版本该提案不改变 EVM 的共识规则不需要硬分叉。它纯粹是网络层devp2p的协议演进这与同属 Networking 类别的 EIP-7642、EIP-8077、EIP-8070 保持一致。安全考量与当前状态值得如实指出的是该提案的Security Considerations 部分目前为空尚未填写具体的安全分析。作为 Draft 状态提案其待办项还包括GetPooledBlobs与PooledBlobs的消息码尚未分配标注-- TODO --与 EIP-8070 的组合方式待定标注-- TODO --从设计本身可以推断PooledBlobs响应允许跳过不可用的 blob意味着接收方必须容忍部分响应而请求方最终仍需验证 blob 哈希与 vhash 对应这类校验逻辑的具体安全边界有待后续版本补充。读者在评估或实现时应将本提案视为尚未定稿的设计草案并同时关注其依赖链EIP-4844blob 交易与 vhash 定义、EIP-7642eth/69 基线协议以及并行演进的 EIP-8077 与 EIP-8070。延伸阅读提案原文EIPS/eip-8094.md依赖的协议版本基线EIPS/eip-7642.mdeth/69 - 历史过期与简化收据blob 交易与 vhash 的源头定义EIPS/eip-4844.md可组合的公告扩展EIPS/eip-8077.mdeth/XX - 公告携带 nonce并行推进的带宽优化EIPS/eip-8070.mdSparse Blobpool网络升级候选列表EIPS/eip-8081.mdHegotá Meta EIP【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-8094 eth/vhash：面向 Blob 感知的以太坊 Mempool 协议设计全解读
EIP-8094 eth/vhash面向 Blob 感知的以太坊 Mempool 协议设计全解读【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-8094eth/vhash - Blob-Aware Mempool 是一份处于 Draft 状态的以太坊网络层Networking 类别标准提案目标是让 devp2peth协议的 mempool 消息具备vhash 感知能力——即通过 blob 内容哈希versioned hash来寻址交易侧边车sidecar中的 blob 数据。读完本文你将理解当前 blob 交易在 RBFreplace-by-fee费用替换场景下带宽浪费的根源、该提案引入的GetPooledBlobs/PooledBlobs消息设计、三种实现路径的取舍以及它与 EIP-7642、EIP-8077、EIP-8070 等协议的协同关系。背景为什么 blob 交易的 RBF 在网络上是昂贵的以太坊 blob 交易的 sidecar 传播模型要理解 EIP-8094 的动机需要先回顾 blob 交易的传播机制。在 EIP-4844 的设计中blob 数据并不嵌入交易主体而是作为sidecar单独传播Instead of embedding the full contents in the body, the blobs are propagated separately, as sidecars.交易的网络层包装格式为rlp([tx_payload_body, blobs, commitments, proofs])见 EIP-4844 规范其中blobs是 blob 数据列表commitments是对应的 KZG 承诺proofs是对应的 KZG 证明节点必须验证kzg_to_versioned_hash(commitments[i]) tx_payload_body.blob_versioned_hashes[i]才能确认包装数据与交易主体一致见 EIP-4844 验证规则。关键在传播规则。EIP-4844 明确规定Nodes MUST NOT automatically broadcast blob transactions to their peers. Instead, those transactions are only announced usingNewPooledTransactionHashesmessages, and can then be manually requested viaGetPooledTransactions.见 EIP-4844 网络层规则也就是说blob 交易默认不走急切推送路径而是先公告、再按需拉取完整内容。问题费用波动期的重复带宽消耗EIP-8094 的 Motivation 指出在当前 devp2peth/69协议下eth/69由 EIP-7642 定义该 EIP 的requires字段即指向它当一笔交易被替换RBF时它必须像任何新交易一样在 mempool 中重新分发。即使替换前后的实际内容blob 数据几乎完全一样协议参与者也没有任何手段在拿到完整内容之前判断这个新公告对应的 blob 内容我是否已经有了于是每一次替换都消耗与全新交易等量的网络资源。而最麻烦的地方在于RBF 恰恰在费率剧烈波动的时期使用最频繁而网络过载正是这种波动期的典型形态。也就是说在本来就高负载的时候协议反而会因为重复分发已经分发过的 blob 内容而雪上加霜。这正是该提案的核心切入点如果替换只改了费用元数据而 blob 内容未变就应该让网络无需重新传输 blob 内容。核心思路用 vhash内容哈希寻址 blob提案的名字eth/vhash点明了核心设计修改 devp2peth协议使类型 3blob-carrying交易 sidecar 中的 blob 能够通过内容哈希来寻址。这里的 vhash 即 EIP-4844 中定义的 versioned hashkzg_to_versioned_hash(commitment)取 KZG 承诺的 SHA256 哈希并覆写版本字节见 EIP-4844 定义。由于 vhash 是 blob 内容的确定性指纹它天然具备两个特性内容不变则 vhash 不变RBF 只改费用时sidecar 的 vhash 集合保持不变接收方可以据此判断这些 blob 我已有缓存无需再拉已经标准化vhash 在共识层和 CL 侧早已是成熟标识符只是尚未进入 devp2p 消息层。规范详解SpecificationEIP-8094 的规范由四部分组成两条既有消息的修改、两条新消息的引入以及一条对 EIP-4844 传播规则的修订。注意新消息的消息码msg code在提案中仍标注为-- TODO --等待后续分配。1.Transactions (0x02)消息变更类型 3 交易在通过Transactions消息传输时应should不带 sidecar 发送Transactions (0x02) changes: Type 3 transaction should be sent without sidecar2.PooledTransactions (0x0a)消息变更同理PooledTransactions消息中的类型 3 交易也应不带 sidecar 发送PooledTransactions (0x0a) changes: Type 3 transaction should be sent without sidecar这两条修改的目的是一致的让交易主体含费用字段与blob 内容在消息层解耦为后续按 vhash 单独拉取 blob 铺路。值得注意的是这与 EIP-8070Sparse Blobpool 的方向相呼应——后者在GetPooledTransactions/PooledTransactions中要求将 blob 字段编码为 RLP 空列表0xc0只保留 commitments 与 proofs而 EIP-8094 走得更远直接让 blob 内容通过专门的新消息按 vhash 请求。3. 新消息GetPooledBlobs消息码待分配[request-id: P, [vhash₁: B_32, vhash₂: B_32, ...]]该消息从接收方的交易池中按 vhash 请求 blob格式包含一个请求 ID 和 vhash 列表每个 vhash 为 32 字节即B_32。request-id用于关联请求与响应这也是 devp2p 支持并发请求与乱序响应的常规机制EIP-8070 的 Rationale 中同样提到了基于request_id关联的并发请求设计。4. 新消息PooledBlobs消息码待分配[request-id: P, [blob₁, blob₂...]]这是GetPooledBlobs的响应消息返回请求的 blob 列表格式沿用主以太坊规范即 EIP-4844中的 blob 定义。规范还明确了三条关键约束顺序一致、允许跳过返回的 blob 必须与请求中的 vhash 顺序一致但可以跳过本地不可用的 blob。由于接收方无论如何都必须校验传输的 blob 哈希与请求的 vhash 对应响应消息中不需要再附带 vhash 列表可选优化一前缀版本号可以在 blob 格式前加上 blob 版本号可选优化二重建友好的 blob 格式允许节点用更少的带宽重建 RSReed-Solomon擦除编码而不是传输完整编码。每个 blob 可发送以下字段blob 版本blob versionblob 内容version 1 时排除擦除编码扩展部分blob 承诺blob commitmentblob 证明blob proof(s)version 1 时包含擦除编码片的 cell proofs提案特别强调必须包含所有 cell proofs以保证重建过程 CPU 高效。从实现背景可以推断这里提到的擦除编码扩展 / cell proofs对应的是 PeerDAS 方向的列采样体系EIP-8070 即依赖该体系其参数表中包含CELLS_PER_EXT_BLOB与 64 cells 的 RS 解码阈值。该可选项的目的是把网络带宽换 CPU变成CPU 换带宽让有能力的节点自行重建。可选优化三发送位图可以在响应中附带已发送/未发送 blob 的位图bitmap或附上已发送的 vhash 列表。提案明确指出这是冗余信息但可以简化接收端的处理逻辑。5. 对 EIP-4844 传播规则的修订提案要求修订 EIP-4844 中不得自动广播 blob 交易的规则。原规则为Nodes MUST NOT automatically broadcast blob transactions to their peers. Instead, those transactions are only announced usingNewPooledTransactionHashesmessages, and can then be manually requested viaGetPooledTransactions.修订后的规则为Nodes MUST send (broadcast or send inNewPooledTransactionHashes) blob transactionwithoutsidecars to their peers. Peers can then request blob content usingGetPooledBlobsmessages. Nodes MUST NOT forward blob transactions before receiving and validating all blobs.对比可见三处关键变化从禁止广播变为允许不带 sidecar 广播交易主体含费用、nonce、vhash 列表等元数据可以通过Transactions消息急切推送也可以走NewPooledTransactionHashes公告blob 内容改为通过GetPooledBlobs显式请求接收方按 vhash 决定要拉哪些 blob这是实现跳过已有内容的机制基础新增转发前置条件节点在接收并验证所有 blob 之前不得转发 blob 交易这保证了内容可验证性不被破坏。设计取舍Rationale为什么用 blob 级 vhash 而不是 sidecar 级哈希提案明确讨论过两种标识符方案使用单个 sidecar 级哈希优点是单一元素、消息格式简单或者使用 blob 级 vhash。最终选择 vhash理由有二sidecar 级哈希是全新标识符而 blob 级 vhash 已经非常成熟只是尚未进入 devp2pblob 级寻址允许重组消息例如在费率飙升时可以只发送部分 blob粒度更细、更灵活。因此使用 vhashes。三种实现选项的比较提案系统性地比较了把 vhash 引入 devp2p 消息的三条路径选项思路评价Option 1在公告中扩展 vhash允许节点请求带/不带 sidecar 的交易甚至通过 bitmap 或 vhash 列表选择需要哪些部分粒度最细但公告与请求消息的复杂度最高Option 2公告扩展 nonce见 EIP-8077若交易哈希与自己已有不同则根据是否已拥有同一 nonce 的 sidecar决定是否带 sidecar 请求假设是简单替换若 vhash 确实不同再重新带 sidecar 请求依赖同 nonce 即替换的假设存在二次请求的额外 RTTOption 3选定推送或公告后拉取不带 sidecar的类型 3 交易允许单独请求 sidecar新增消息类型设计最简单、最直接从表面看Option 3 似乎会在每一跳增加一个 RTT 延迟。但提案给出了关键反驳大多数类型 3 交易在没有 sidecar 时非常小因此可以改变协议行为允许直接推送不带 sidecar 的交易由推送的接收方在需要时主动请求 blob。而在 sidecar 被拉取并验证内容之前禁止转发类型 3 交易这条规则保证了内容验证链不被破坏。综合权衡后提案选择 Option 3引入新的消息类型即GetPooledBlobs/PooledBlobs。与其他 Draft 状态 EIP 的关系EIP-8077eth/XX公告携带 source 与 nonce该提案扩展NewPooledTransactionHashes (0x08)消息在原有[txtypes, txsize, txhash]基础上追加txsourceB_20与txnonceP字段。它与 EIP-8094 的变更互不冲突可以简单组合EIP-8070Sparse Blobpool两个提案都改变 blob 交易在网络的传播方式但目标不同——EIP-8070 致力于在正常情况下按比例削减带宽通过 p0.15 的整包拉取概率与其余情况的列采样并不处理 RBF 的细节EIP-8094 则专注于让RBF 不消耗额外带宽。两者可以组合但组合方式取决于引入顺序因此提案将其留待后续决定标注-- TODO --。此外从仓库中的 EIP-8081Hegotá 网络升级 Meta EIP 可以看到EIP-8094 与 EIP-8077 同被列为 Hegotá 升级的Proposed for Inclusion候选说明两个提案正被一同推进评估。向后兼容性EIP-8094 明确了两点兼容性结论该提案修改eth协议需要推出新版本参照 EIP-7642 引入eth/69的先例。支持多个 wire protocol 版本是客户端常规做法推出新版本不会破坏旧客户端——它们可以继续使用旧协议版本该提案不改变 EVM 的共识规则不需要硬分叉。它纯粹是网络层devp2p的协议演进这与同属 Networking 类别的 EIP-7642、EIP-8077、EIP-8070 保持一致。安全考量与当前状态值得如实指出的是该提案的Security Considerations 部分目前为空尚未填写具体的安全分析。作为 Draft 状态提案其待办项还包括GetPooledBlobs与PooledBlobs的消息码尚未分配标注-- TODO --与 EIP-8070 的组合方式待定标注-- TODO --从设计本身可以推断PooledBlobs响应允许跳过不可用的 blob意味着接收方必须容忍部分响应而请求方最终仍需验证 blob 哈希与 vhash 对应这类校验逻辑的具体安全边界有待后续版本补充。读者在评估或实现时应将本提案视为尚未定稿的设计草案并同时关注其依赖链EIP-4844blob 交易与 vhash 定义、EIP-7642eth/69 基线协议以及并行演进的 EIP-8077 与 EIP-8070。延伸阅读提案原文EIPS/eip-8094.md依赖的协议版本基线EIPS/eip-7642.mdeth/69 - 历史过期与简化收据blob 交易与 vhash 的源头定义EIPS/eip-4844.md可组合的公告扩展EIPS/eip-8077.mdeth/XX - 公告携带 nonce并行推进的带宽优化EIPS/eip-8070.mdSparse Blobpool网络升级候选列表EIPS/eip-8081.mdHegotá Meta EIP【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考