EIP-7542 详解eth/70 可用区块范围扩展协议available-blocks-extended protocol【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-7542 提出在以太坊执行层点对点网络devp2peth线协议上新增eth/70协议版本让节点在握手阶段就向对端通告自身可服务的区块范围并新增两类消息用于按需请求与分享区块范围的更新。本文以 EIPS/eip-7542.md 为骨架结合仓库中 EIPS/eip-7642.mdeth/69、EIPS/eip-4444.md历史数据剪枝与 EIPS/eip-5793.mdeth/68等关联提案系统讲解该协议的设计动机、消息格式、字段语义、兼容性策略与测试方向并梳理其与最终落地版本 eth/69 之间的继承与差异关系。读完本文你将完整掌握如何在 eth 线协议中通告与查询区块范围这一网络层扩展方案的技术全貌。一、提案定位与状态项目内容EIP 编号7542标题eth/70 - available-blocks-extended protocol类别Standards Track / Networking状态Withdrawn已撤回作者Ahmad Bitarsmartprogrammer93创建时间2023-10-21依赖要求 EIP-7642需要特别说明的是该 EIP 在仓库中处于Withdrawn状态。根据 EIPS/eip-1.md 的定义Withdrawn 表示EIP 作者已撤回该提案该状态具有终局性无法再用此 EIP 编号复活如果日后重新推进该想法将被视为一个新提案。撤回的来龙去脉在 EIPS/eip-7642.md 中有直接记载A similar idea was proposed in EIP-7542 but was later withdrawn because a political decision on history expiry had not been reached at the time.即由于当时社区对历史数据过期history expiry尚未达成政治性/方向性决策该提案被撤回而类似的想法随后由 eth/69EIP-7642正式落地。因此本文将 EIP-7542 视为一份已被取代的技术方案档案在完整还原其设计的同时对照 eth/69 的最终实现阐明两者的演进关系——这对理解以太坊网络层协议迭代的历史脉络极具价值。二、核心动机让节点知道谁拥有哪些区块2.1 历史数据剪枝带来的新需求EIP-7542 的出发点与 EIP-4444Bound Historical Data in Execution Clients密切相关。EIP-4444 主张执行客户端停止在 p2p 层提供早于HISTORY_PRUNE_EPOCHS33024 个 epoch的历史区块头、区块体与收据并允许客户端在本地剪枝这些历史数据见 EIPS/eip-4444.md。一旦部分节点开始剪枝历史数据网络就分裂为两类节点仍愿意服务历史数据的节点archive 服务方希望剪枝历史数据、只保留近期数据的节点轻量存储方。EIP-7542 的原文指出在 EIP-4444 的第一阶段一部分节点仍需对外提供链的历史数据而另一些节点可能开始尝试剪枝。当前协议的问题在于节点必须实际连接对端并发起区块请求才能试探出对方是否持有所需数据——这既浪费带宽也浪费时间还会产生大量无效请求。2.2 对同步效率的附带收益除历史数据场景外该机制还能提升常规同步效率通过握手阶段直接获知对端的可用区块范围节点可以判断某个可能仍在同步中的对端是否已经具备所需区块从而避免无谓的区块请求与空响应empty response——这在链首次同步initial sync场景下尤为有价值。2.3 与 eth/69 的演进对照eth/69EIP-7642在动机部分同样强调了这一点历史过期工作组决定客户端可在 2025 年 5 月 1 日后丢弃合并前历史对于希望通过eth协议同步历史的客户端而言必须知道对端是否仍在服务旧历史。可以看到EIP-7542 提出的在协议中显式通告区块范围这一核心思路正是 eth/69 设计的前身。三、协议规格eth/70 的握手与消息扩展EIP-7542 的规范部分包含三个层次的改动新协议版本、握手消息字段扩展、两个新消息类型。3.1 新增协议版本 eth/70通告一个新的eth协议能力capability版本eth/70旧的eth/69协议应继续与eth/70并行保留直到eth/70被实现者充分采纳为止。这种新旧版本并存的策略正是 devp2p 线协议迭代的标准做法同一线协议可以同时运行多个版本未升级的节点可继续使用旧版本网络不会因协议升级而分裂。3.2 修改 Status (0x00) 握手消息Status消息是eth协议连接建立后的第一条消息用于交换双方的基本网络身份信息。EIP-7542 提出在eth/70中为Status消息新增blockRange字段位置紧跟在forkid之后eth/69 原封包[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid]eth/70 新封包[version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid blockRange]其中新增的blockRange结构为blockRange [startBlock: uint64, endBlock: uint64]字段语义字段类型含义versionPRLP 整数协议版本号networkidPRLP 整数网络 ID区分主网、测试网等blockhashB_3232 字节当前最新区块哈希genesisB_3232 字节创世区块哈希forkid结构体分叉标识用于快速识别链与分叉状态startBlockuint64该节点可提供的最早区块高度endBlockuint64该节点可提供的最新区块高度在握手阶段直接携带区块范围意味着双方在建立连接的最初瞬间就能理解对方的服务能力而无需任何额外的探测请求。3.3 新增消息类型 RequestBlockRange 与 SendBlockRangeEIP-7542 引入了两个新消息类型用于在连接存续期间追踪对端区块范围的变化消息类型消息 ID方向载荷语义RequestBlockRange0x0b节点 → 对端无载荷请求对端当前可服务的区块范围SendBlockRange0x0c对端 → 请求方[startBlock: uint64, endBlock: uint64]响应RequestBlockRange告知当前可用区块范围完整交互流程使用eth/70建立连接后双方交换Status消息其中已包含初始blockRange后续任何一方需要最新范围时发送RequestBlockRange (0x0b)对端以SendBlockRange (0x0c)回复[startBlock, endBlock]。之所以需要按需查询机制是因为节点的可用区块范围是动态变化的节点可能持续同步endBlock增长也可能执行剪枝startBlock后移。握手中的快照信息会随时间过期因此需要一套轻量的更新通道。3.4 连接保持策略EIP-7542 明确要求无论对端的可用区块范围如何节点都必须保持与对端的连接只有一个例外——当节点的对端槽位peer slots已满、且现有连接中缺乏持有必要区块范围的对端时节点可以主动断开连接以寻找满足需求的节点。这一设计的意图很清晰平时保持网络连接的韧性与拓扑稳定在同步关键时刻槽位紧张且缺少所需数据的提供者则允许择优换连从而在网络韧性与同步效率之间取得平衡。四、设计理由Rationale剖析EIP-7542 给出了三点核心设计论证握手即知能力将可用区块范围放进eth握手让节点立即理解对端能力可基于自身数据需求优先建立/维持连接提升整体网络效率按需更新而非广播由于同步与剪枝都会改变区块范围引入独立的消息类型让节点在需要时请求更新避免持续广播带来的流量开销默认保持连接 例外换连维持与范围不符对端的连接可保障网络韧性而槽位已满且缺少必要范围对端时的例外则为满容量下的高效区块同步提供了机制出口。这套论证与 eth/69 的BlockRangeUpdate (0x11)消息设计一脉相承。值得注意的是eth/69 在落地时对更新频率做了更具体的约束客户端应至少每隔一个 epoch32 个区块才发送一次更新以降低流量见 EIPS/eip-7642.md。这可以视为对 EIP-7542 中按需查询思路在工程效率上的进一步细化——两者的目的都是以最小流量代价维持对端区块范围的近似最新认知。五、向后兼容性分析5.1 协议版本并行的可行性EIP-7542 对eth协议握手的修改是向后不兼容的新增字段改变了Status消息编码因此必须引入新版本eth/70而非原地修改。但 devp2p 允许同一线协议并发运行多个版本因此未升级的节点可以继续使用eth/69、eth/68或eth/67等旧版本新旧节点可以在同一网络中并存逐步完成版本迁移。这种渐进式升级路径与 eth/69 的推广方式完全一致EIPS/eip-7642.md 中同样强调支持多版本线协议、旧客户端可继续使用eth/68。5.2 不涉及共识层EIP-7542 明确指出该提案不影响共识引擎也不需要硬分叉。它只改动执行层的点对点网络协议属于纯网络层Networking 类别的改进对区块验证规则、状态转换函数等共识逻辑零影响。六、测试方向Test CasesEIP-7542 给出的测试重点包含两个层面握手阶段验证节点能否在Status消息中正确编解码blockRange信息双方能否相互理解尤其是与旧版本节点混连时消息交互阶段验证节点能否正确发起RequestBlockRange、正确响应SendBlockRange以及范围更新能否被准确传达。结合 eth/69 的工程实践EIPS/eip-7642.md此类网络协议测试通常会覆盖不同协议版本节点的互操作、区块范围随同步推进的更新、剪枝导致startBlock后移的通知以及对端发送异常/非法范围值时的健壮性处理。测试的目标是确保节点间能正确交流并理解区块范围信息这一核心不变量在任何拓扑组合下都成立。七、安全考虑与边界澄清EIP-7542 的安全考虑部分只有一条且是一条澄清性说明本变更并非在替代性历史区块存储方案实现之前就不存储、不服务历史区块的标准化。也就是说该 EIP 只解决**如何告知对方我有哪些区块的通信问题而不改变**节点应当存储哪些历史数据的存储策略问题——后者由 EIP-4444 及未来的历史数据存储方案如 Portal Network 等带外方案见 EIPS/eip-4444.md另行定义。这是理解该提案边界的关键协议层的信息披露与存储层的策略决策是解耦的。八、从 EIP-7542 到 EIP-7642方案的继承与演进将仓库中两篇文档对照阅读可以清晰还原这段网络协议演进史维度EIP-7542eth/70已撤回EIP-7642eth/69Final区块范围通告Status新增blockRange: [startBlock, endBlock]Status新增earliestBlock, latestBlock, latestBlockHashblockhash移至末尾范围更新机制RequestBlockRange (0x0b)/SendBlockRange (0x0c)按需查询BlockRangeUpdate (0x11)主动推送每 epoch32 块至多一次附加改动无移除合并后无意义的td字段从收据消息中移除bloom字段每同步节点节省约 530 GiB、snappy 压缩后约 95 GiB 带宽状态WithdrawnFinaleth/69 在动机部分明确承认其灵感来源A similar idea was proposed in EIP-7542 but was later withdrawn because a political decision on history expiry had not been reached at the timeEIPS/eip-7642.md。这说明 EIP-7542 虽未直接落地但其在握手阶段通告区块范围的核心思想已成为以太坊网络层的正式标准——这正是研读该文档最重要的现实意义它是一份思想被采纳、载体被替换的协议设计档案。九、结论EIP-7542 提出了一套完整的可用区块范围扩展协议通过eth/70版本在Status握手中携带[startBlock, endBlock]并辅以RequestBlockRange/SendBlockRange两个消息维持范围的动态更新从而让节点在连接建立之初即可做出更明智的对端选择服务于历史数据剪枝EIP-4444时代的效率需求与同步优化。尽管该提案最终被撤回但其设计思想被 EIP-7642eth/69 正式继承并落地。对网络层研究者与客户端实现者而言对比阅读这两份文档可以完整理解以太坊线协议从隐式探测对端能力走向显式通告区块范围的设计演进也能为未来任何涉及 p2p 能力通告的协议设计提供可复用的范式参考。参考文档索引EIP-7542 原文EIP-7642eth/69 - history expiry and simpler receiptsEIP-4444Bound Historical Data in Execution ClientsEIP-5793eth/68 - Add tx type to tx announcementEIP-1EIP 状态定义Withdrawn仓库许可证CC0【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考