EIP-8136 Cell-Level Deltas 详解为 PeerDAS 数据列广播引入的 Gossipsub 增量优化【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-8136Cell-Level Deltas for Data Column Broadcast是对 PeerDASEIP-7594数据可用性采样网络的关键带宽优化节点不再被迫交换整条数据列column而是只交换对方缺失的单元cell。本文基于本仓库 EIPS/eip-8136.md 的完整规范结合其依赖的 PeerDAS 基础、以及后续引用该方案的 EIP-8371RowDAS与 EIP-7773Glamsterdam 升级元提案系统讲解其动机、协议设计、备选方案对比、向后兼容性与安全考量帮助以太坊客户端与 Gossipsub 实现者理解并落地这一无需硬分叉即可渐进部署的网络优化。背景PeerDAS 中数据列如何被广播在深入 EIP-8136 之前需要先理解它所优化的对象。根据 EIP-7594PeerDAS状态 Finalrequires EIP-4844节点以「列」为单位参与数据可用性每一行row由 blob 数据及其纠删码扩展构成每行被细分为多个 cell——cell 是可用对应 blob 的 KZG 承诺进行认证的最小单元每一列column与一个特定的 gossip 子网关联由所有行的同一索引处的 cell 组成每个节点根据其节点 ID 确定性负责一组列子网并保管custody其数据。节点在每个 slot 从对等节点处采样列以完成本地 DAS 检查当节点获取至少 50% 的列时即可重构整个数据矩阵不足 50% 时可向对等节点请求缺失的列。EIP-7594 还引入了 cell KZG 证明cell_proofs使节点可以只下载一个 blob 中的特定 cell同时仍能相对 KZG 承诺验证数据完整性——这正是 cell 级数据交换得以成立的前提。动机mempool 已有数据不应被重复传输EIP-8136 的出发点非常朴素且直接在绝大多数情况下区块中引用的全部或几乎所有 blob 都已在节点的本地 mempool 中。既然节点本地已经持有这些 blob 数据再通过网络把包含这些 cell 的完整数据列推送给它就是纯粹的带宽浪费。当前EIP-8136 之前的设计存在一个明显的低效场景即使只有一个 blob 不在本地 mempool 中共识层Consensus Layer也必须等待从网络接收完整的对应数据列才能通过其数据可用性检查。而启用本优化后客户端只需等待接收缺失的那部分 cell即可其余 cell 直接使用本地 mempool 中已有的 blob 数据补齐。由此EIP-8136 将列内大部分 cell 已在本地的情况下的网络开销从「整列传输」降为「增量传输」。规范基于 Gossipsub Partial Messages Extension 的 cell 增量交换核心技术手段EIP-8136 的规范本身非常精简其核心只有一句话式的定义Cell-Level Deltas 使用Gossipsub 的 Partial Messages Extension来交换 cell 位图cell bitmaps并据此请求/提供 cell。即消息的传播单元从「完整数据列」细化为「cell 位图 缺失 cell」。节点通过位图向对等节点宣告自己持有哪些 cell、缺失哪些 cell随后只针对缺失部分发起请求与响应。规范的详细 wire format 定义在ethereum/consensus-specs仓库spec 以该仓库为单一事实来源EIP 文档中不重复罗列协议字节级细节。关键词语义与所有 EIP 一致本规范中的 MUST / MUST NOT / REQUIRED / SHALL / SHALL NOT / SHOULD / SHOULD NOT / RECOMMENDED / NOT RECOMMENDED / MAY / OPTIONAL 均按 RFC 2119 与 RFC 8174 解释。实现者需据此区分强制性与建议性要求。关键设计决策默认 pull-based 取代 push-based扩展带来的最大行为变化是 cell 的传播策略默认从 push推送转为 pull拉取节点不再默认把整列数据急切地推送给每个对等节点取而代之的是先通过位图「宣告」再由对端按需拉取缺失 cell急切推送eager push仍然被允许但不再是默认行为。这一转变是带宽效率的核心来源既然大部分 cell 对端本地已有主动推送必然造成冗余流量而按需拉取则让每个字节都恰好是对方缺失的。备选设计对比为什么最终选择 Gossipsub 扩展EIP-8136 的 Rationale 明确列出了三个被否决的备选方案理解这些对比有助于把握设计边界备选一更小的 Gossipsub 消息单 cell 即一消息将 Gossipsub 消息单元从整列缩小为单个 cell。此方案虽然天然做到 cell 级传输但存在多个结构性缺陷由于没有把位图作为一等公民概念每个 cell 一条消息会引入每条消息的固定开销用IDONTWANT通知对端「这些 cell 我已有」时总是会与对端同时推送同一 cell 产生竞态——在几乎所有 blob 都是公开数据mempool 可见的场景下默认 push 策略过于激进消息 ID 是基于内容如哈希的缺少「该 cell 属于哪个区块」的上下文节点无法据此请求自己缺失的 cell也无法优先处理正在处理的区块的 cell。文档进一步指出修改消息 ID 语义也许能规避部分问题但这仍需要一个独立的新 Gossipsub topic无法作为现有 topic 的向后兼容替代品而且修改消息 ID 语义可能破坏「消息 ID 与消息一一对应」这一 Gossipsub 实现假设。备选二新增 RPC 方法表面上看最简单但忽略了 Gossipsub 内部已在进行的工作。若仅在现有 Gossipsub 之上叠加一个新 RPC 方法由于是在原有 gossip 流量之外额外增加一次 RPC 往返只会增加网络与计算负载而非降低。要让两者协同最终仍会走向本方案——带有应用自定义语义的 partial messages Gossipsub 扩展。备选三完全独立于 Gossipsub 的新协议文档承认这可能是值得探索的长期方向但对于「在无需硬分叉的前提下利用本地 blob 数据」这一目标而言改动量过大。向后兼容性无需硬分叉可渐进部署EIP-8136 明确声明不存在向后兼容性问题其兼容机制建立在「双边协商」之上节点仍按原有规则组建 Gossipsub mesh 并按原规则 gossip只有当一条 gossip 连接的两端都支持该扩展时优化才生效只要任一方不支持双方都退回到原有行为——互传完整 Gossipsub 消息完整数据列。不实现该优化的节点依然能正常接收和传输完整数据列。正因为这一特性EIP-8136 不需要硬分叉可以随客户端版本逐步上线、随时回滚。此外文档特别指出该扩展不改变 Gossipsub 的 peer 评分语义对能及时提供消息的 peer 给予好评、对提供无效消息的 peer 给予惩罚的机制保持不变评分行为在有/无该扩展时应当一致。安全考量延迟权衡与实现陷阱延迟 vs 带宽的默认权衡默认情况下相比标准 Gossipsub 的默认 push 行为本优化为 cell 传播引入了少量延迟换来的是更高效的带宽使用。文档同时给出缓解路径随着时间推移节点的 eager cell push 策略可以被逐步调优以匹配甚至改善传播延迟。延迟是 rollout 期间及之后需要重点监控的关键指标。实现者必须注意的陷阱文档为客户端与 Gossipsub 实现者列出了一组具体的实现注意点不要歧视不支持该扩展的 peer虽然与支持本 EIP 的 peer 组 mesh 更高效但若偏好这类 peer可能割裂网络。实现 SHOULD NOT 对不支持的 peer 进行歧视。peer 评分应大体等价无论 peer 是否支持 partial messages其评分应当大致相同一次提供一个 cell 的 peer 不应比一次提供全部 cell 的 peer 获得更高评分。对 Group ID 垃圾消息保持韧性实现应能抵御 peer 用不同 Group ID 刷消息的行为实现 SHOULD 为 mesh peer 的消息预留空间以防范恶意非 mesh peer 的消息淹没。渐进式部署该优化预期渐进铺开并保留按需回滚的能力——这与其「无需硬分叉」的设计目标一致。生态落点Glamsterdam 与 RowDAS 中的引用EIP-8136 并非孤立提案在本仓库中可找到它的两个直接落点可作为理解其生态定位的参考EIP-7773Hardfork Meta - Glamsterdam将 EIP-8136 列入 Networking EIPs 清单与eth/70部分区块回执列表EIP-7975、eth/72稀疏 BlobpoolEIP-8070等并列说明它是 PeerDAS 网络栈升级的重要组成部分。EIP-8371RowDAS - Distributed Blob ReconstructionDraftrequires 7594 与 8136直接以 Cell-Level Deltas 为地基其新增的行子网data_row_{subnet_id}必须使用 EIP-8136 的 Cell-Level Deltas 且关闭 eager pushGroupID 由区块根block root派生位图覆盖范围与 GroupID 派生的 wire format 遵循 EIP-8136 的路线定义于 consensus-specs 仓库。EIP-8371 还重申了 EIP-8136 的非歧视性指导仅适用于存在完整消息回退路径的列 topic并继承了其对位图更新去抖debounce、限速以及限制每 peer 跟踪 GroupID 数量的建议。从实现层面看EIP-8136 的核心概念cell 位图、GroupID、按需拉取、mesh 与非 mesh 消息空间预留都在这些后续提案中得到了复用与扩展这也印证了其「最小语义变更、向后兼容」设计原则的有效性。总结EIP-8136 以极小的协议改动换取显著的网络带宽收益在 PeerDAS 框架下将「整列广播」细化为「基于 Gossipsub Partial Messages Extension 的 cell 位图交换 缺失 cell 按需拉取」充分利用节点本地 mempool 已持有的 blob 数据。它不改变 mesh 结构与 gossip 语义不需要硬分叉双边协商机制保证了对不支持节点的完全向后兼容。对于以太坊客户端与 Gossipsub 实现者而言落地要点集中在正确实现 partial messages 扩展与位图交互、默认 pull 策略与可选的 eager push 调优、以及文档强调的 peer 评分中立性与对恶意 Group ID 消息的韧性。该 EIP 已在 Glamsterdam 网络升级中被列为 Networking EIP并作为 RowDAS 的底层基础设施持续影响以太坊数据可用性层的演进。版权说明本文所述 EIP-8136 内容版权依 CC0 放弃可自由使用。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
EIP-8136 Cell-Level Deltas 详解：为 PeerDAS 数据列广播引入的 Gossipsub 增量优化
EIP-8136 Cell-Level Deltas 详解为 PeerDAS 数据列广播引入的 Gossipsub 增量优化【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-8136Cell-Level Deltas for Data Column Broadcast是对 PeerDASEIP-7594数据可用性采样网络的关键带宽优化节点不再被迫交换整条数据列column而是只交换对方缺失的单元cell。本文基于本仓库 EIPS/eip-8136.md 的完整规范结合其依赖的 PeerDAS 基础、以及后续引用该方案的 EIP-8371RowDAS与 EIP-7773Glamsterdam 升级元提案系统讲解其动机、协议设计、备选方案对比、向后兼容性与安全考量帮助以太坊客户端与 Gossipsub 实现者理解并落地这一无需硬分叉即可渐进部署的网络优化。背景PeerDAS 中数据列如何被广播在深入 EIP-8136 之前需要先理解它所优化的对象。根据 EIP-7594PeerDAS状态 Finalrequires EIP-4844节点以「列」为单位参与数据可用性每一行row由 blob 数据及其纠删码扩展构成每行被细分为多个 cell——cell 是可用对应 blob 的 KZG 承诺进行认证的最小单元每一列column与一个特定的 gossip 子网关联由所有行的同一索引处的 cell 组成每个节点根据其节点 ID 确定性负责一组列子网并保管custody其数据。节点在每个 slot 从对等节点处采样列以完成本地 DAS 检查当节点获取至少 50% 的列时即可重构整个数据矩阵不足 50% 时可向对等节点请求缺失的列。EIP-7594 还引入了 cell KZG 证明cell_proofs使节点可以只下载一个 blob 中的特定 cell同时仍能相对 KZG 承诺验证数据完整性——这正是 cell 级数据交换得以成立的前提。动机mempool 已有数据不应被重复传输EIP-8136 的出发点非常朴素且直接在绝大多数情况下区块中引用的全部或几乎所有 blob 都已在节点的本地 mempool 中。既然节点本地已经持有这些 blob 数据再通过网络把包含这些 cell 的完整数据列推送给它就是纯粹的带宽浪费。当前EIP-8136 之前的设计存在一个明显的低效场景即使只有一个 blob 不在本地 mempool 中共识层Consensus Layer也必须等待从网络接收完整的对应数据列才能通过其数据可用性检查。而启用本优化后客户端只需等待接收缺失的那部分 cell即可其余 cell 直接使用本地 mempool 中已有的 blob 数据补齐。由此EIP-8136 将列内大部分 cell 已在本地的情况下的网络开销从「整列传输」降为「增量传输」。规范基于 Gossipsub Partial Messages Extension 的 cell 增量交换核心技术手段EIP-8136 的规范本身非常精简其核心只有一句话式的定义Cell-Level Deltas 使用Gossipsub 的 Partial Messages Extension来交换 cell 位图cell bitmaps并据此请求/提供 cell。即消息的传播单元从「完整数据列」细化为「cell 位图 缺失 cell」。节点通过位图向对等节点宣告自己持有哪些 cell、缺失哪些 cell随后只针对缺失部分发起请求与响应。规范的详细 wire format 定义在ethereum/consensus-specs仓库spec 以该仓库为单一事实来源EIP 文档中不重复罗列协议字节级细节。关键词语义与所有 EIP 一致本规范中的 MUST / MUST NOT / REQUIRED / SHALL / SHALL NOT / SHOULD / SHOULD NOT / RECOMMENDED / NOT RECOMMENDED / MAY / OPTIONAL 均按 RFC 2119 与 RFC 8174 解释。实现者需据此区分强制性与建议性要求。关键设计决策默认 pull-based 取代 push-based扩展带来的最大行为变化是 cell 的传播策略默认从 push推送转为 pull拉取节点不再默认把整列数据急切地推送给每个对等节点取而代之的是先通过位图「宣告」再由对端按需拉取缺失 cell急切推送eager push仍然被允许但不再是默认行为。这一转变是带宽效率的核心来源既然大部分 cell 对端本地已有主动推送必然造成冗余流量而按需拉取则让每个字节都恰好是对方缺失的。备选设计对比为什么最终选择 Gossipsub 扩展EIP-8136 的 Rationale 明确列出了三个被否决的备选方案理解这些对比有助于把握设计边界备选一更小的 Gossipsub 消息单 cell 即一消息将 Gossipsub 消息单元从整列缩小为单个 cell。此方案虽然天然做到 cell 级传输但存在多个结构性缺陷由于没有把位图作为一等公民概念每个 cell 一条消息会引入每条消息的固定开销用IDONTWANT通知对端「这些 cell 我已有」时总是会与对端同时推送同一 cell 产生竞态——在几乎所有 blob 都是公开数据mempool 可见的场景下默认 push 策略过于激进消息 ID 是基于内容如哈希的缺少「该 cell 属于哪个区块」的上下文节点无法据此请求自己缺失的 cell也无法优先处理正在处理的区块的 cell。文档进一步指出修改消息 ID 语义也许能规避部分问题但这仍需要一个独立的新 Gossipsub topic无法作为现有 topic 的向后兼容替代品而且修改消息 ID 语义可能破坏「消息 ID 与消息一一对应」这一 Gossipsub 实现假设。备选二新增 RPC 方法表面上看最简单但忽略了 Gossipsub 内部已在进行的工作。若仅在现有 Gossipsub 之上叠加一个新 RPC 方法由于是在原有 gossip 流量之外额外增加一次 RPC 往返只会增加网络与计算负载而非降低。要让两者协同最终仍会走向本方案——带有应用自定义语义的 partial messages Gossipsub 扩展。备选三完全独立于 Gossipsub 的新协议文档承认这可能是值得探索的长期方向但对于「在无需硬分叉的前提下利用本地 blob 数据」这一目标而言改动量过大。向后兼容性无需硬分叉可渐进部署EIP-8136 明确声明不存在向后兼容性问题其兼容机制建立在「双边协商」之上节点仍按原有规则组建 Gossipsub mesh 并按原规则 gossip只有当一条 gossip 连接的两端都支持该扩展时优化才生效只要任一方不支持双方都退回到原有行为——互传完整 Gossipsub 消息完整数据列。不实现该优化的节点依然能正常接收和传输完整数据列。正因为这一特性EIP-8136 不需要硬分叉可以随客户端版本逐步上线、随时回滚。此外文档特别指出该扩展不改变 Gossipsub 的 peer 评分语义对能及时提供消息的 peer 给予好评、对提供无效消息的 peer 给予惩罚的机制保持不变评分行为在有/无该扩展时应当一致。安全考量延迟权衡与实现陷阱延迟 vs 带宽的默认权衡默认情况下相比标准 Gossipsub 的默认 push 行为本优化为 cell 传播引入了少量延迟换来的是更高效的带宽使用。文档同时给出缓解路径随着时间推移节点的 eager cell push 策略可以被逐步调优以匹配甚至改善传播延迟。延迟是 rollout 期间及之后需要重点监控的关键指标。实现者必须注意的陷阱文档为客户端与 Gossipsub 实现者列出了一组具体的实现注意点不要歧视不支持该扩展的 peer虽然与支持本 EIP 的 peer 组 mesh 更高效但若偏好这类 peer可能割裂网络。实现 SHOULD NOT 对不支持的 peer 进行歧视。peer 评分应大体等价无论 peer 是否支持 partial messages其评分应当大致相同一次提供一个 cell 的 peer 不应比一次提供全部 cell 的 peer 获得更高评分。对 Group ID 垃圾消息保持韧性实现应能抵御 peer 用不同 Group ID 刷消息的行为实现 SHOULD 为 mesh peer 的消息预留空间以防范恶意非 mesh peer 的消息淹没。渐进式部署该优化预期渐进铺开并保留按需回滚的能力——这与其「无需硬分叉」的设计目标一致。生态落点Glamsterdam 与 RowDAS 中的引用EIP-8136 并非孤立提案在本仓库中可找到它的两个直接落点可作为理解其生态定位的参考EIP-7773Hardfork Meta - Glamsterdam将 EIP-8136 列入 Networking EIPs 清单与eth/70部分区块回执列表EIP-7975、eth/72稀疏 BlobpoolEIP-8070等并列说明它是 PeerDAS 网络栈升级的重要组成部分。EIP-8371RowDAS - Distributed Blob ReconstructionDraftrequires 7594 与 8136直接以 Cell-Level Deltas 为地基其新增的行子网data_row_{subnet_id}必须使用 EIP-8136 的 Cell-Level Deltas 且关闭 eager pushGroupID 由区块根block root派生位图覆盖范围与 GroupID 派生的 wire format 遵循 EIP-8136 的路线定义于 consensus-specs 仓库。EIP-8371 还重申了 EIP-8136 的非歧视性指导仅适用于存在完整消息回退路径的列 topic并继承了其对位图更新去抖debounce、限速以及限制每 peer 跟踪 GroupID 数量的建议。从实现层面看EIP-8136 的核心概念cell 位图、GroupID、按需拉取、mesh 与非 mesh 消息空间预留都在这些后续提案中得到了复用与扩展这也印证了其「最小语义变更、向后兼容」设计原则的有效性。总结EIP-8136 以极小的协议改动换取显著的网络带宽收益在 PeerDAS 框架下将「整列广播」细化为「基于 Gossipsub Partial Messages Extension 的 cell 位图交换 缺失 cell 按需拉取」充分利用节点本地 mempool 已持有的 blob 数据。它不改变 mesh 结构与 gossip 语义不需要硬分叉双边协商机制保证了对不支持节点的完全向后兼容。对于以太坊客户端与 Gossipsub 实现者而言落地要点集中在正确实现 partial messages 扩展与位图交互、默认 pull 策略与可选的 eager push 调优、以及文档强调的 peer 评分中立性与对恶意 Group ID 消息的韧性。该 EIP 已在 Glamsterdam 网络升级中被列为 Networking EIP并作为 RowDAS 的底层基础设施持续影响以太坊数据可用性层的演进。版权说明本文所述 EIP-8136 内容版权依 CC0 放弃可自由使用。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
