EIP-2464 深度解析eth/65 交易公告与按需检索协议把交易传播带宽从线性降到平方根【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读本文围绕以太坊改进提案 EIP-2464eth/65: transaction announcements and retrievals展开系统讲解以太坊 devp2peth线协议中三个新增消息类型——NewPooledTransactionHashes (0x08)、GetPooledTransactions (0x09)与PooledTransactions (0x0a)——的设计动机、消息格式、带宽收益与演进脉络。读完本文你将理解交易传播从全量广播走向哈希公告 按需拉取的关键机制掌握 4096/256 等软性上限的工程含义并能将 eth/65 放入从 eth/64 到 eth/68 的完整协议演进序列中理解其历史位置。一、背景区块传播有双轨制交易传播却只有单行道以太坊的eth网络协议在传播新区块时提供了两种互补手段全量广播通过NewBlock (0x07)将整个区块10s–100s KB直接发送给约平方根数量的直连节点哈希公告通过NewBlockHashes (0x01)仅发送区块哈希10s–100s B以线性数量的节点规模补齐广播覆盖不到的退化拓扑degenerate topologies。平方根广播足以触达所有连接良好的节点线性公告则用来兜底连接较差的网络形态。区块传播由此在带宽与覆盖之间取得了良好平衡。然而交易传播却缺少同样的双轨机制。交易只能依靠Transactions (0x02)全量广播而为了照顾退化拓扑交易无法像区块那样做平方根广播只能线性地转发给所有 N 个对等节点。结果同一个交易会在每条连接上被重复传输双向计算共 N 次而在理想世界里 1 次就足够——这是巨大的带宽浪费。另一个类似的问题是新建连接时的交易池同步两个节点刚握手时需要同步各自的交易池txpool但交易池本质上是一堆悬空交易的集合且远程无法去重。每个节点只能把自己完整的交易列表朴素地转给对方。当池中存有数千笔交易时一次朴素传输就要消耗 10s–100s MB 流量其中大部分是无用数据。随着以太坊交易吞吐量与交易体积持续上升交易传播已成为网络资源消耗的最大头。由于eth协议缺乏远程去重机制同样的数据在每一条网络连接上被反复传输绝大多数资源被白白浪费。二、eth/65 的核心方案哈希公告 按需拉取EIP-2464 向eth协议新增三个消息类型并据此发布新协议版本eth/65消息消息 ID方向作用NewPooledTransactionHashes0x08单向公告仅公告一批交易的哈希不含交易内容GetPooledTransactions0x09请求按公告的哈希向对端请求一批交易PooledTransactions0x0a响应回复对端的交易请求携带交易本体这套机制让节点在付出昂贵的数据传输之前先就哪些交易需要跨连接传输达成一致从而实现交易传播带宽从 O(peers) 降到 O(√peers)先对平方根数量的节点做哈希公告只有确实缺交易的节点才按需拉取不再对每个节点全量转发初始交易交换从 10s–100s MB 降到约 128KB首次建连时只需交换哈希集合即len(pool) * 32B ≈ 128KB每笔交易的 keccak 哈希恰好 32 字节。EIP-2464 的期望是通过这个微小的协议扩展将以太坊网络的全局运营带宽使用量降低至少一个数量级。三、消息格式与语义详解3.1 NewPooledTransactionHashes (0x08)[hash_0: B_32, hash_1: B_32, ...]语义声明网络中新出现、且尚未被打包进区块的一笔或多笔交易。为最大程度地帮助对端节点应将其认为对方可能不知道的所有交易都告知对方。无协议违例的硬性上限协议本身不限制一次可公告的哈希数量唯一的硬约束是 devp2p 网络包的 10MB 上限但4096 个哈希约 128KB是文档推荐的理智分块sane chunk避免单个数据包长时间独占一条网络连接。去重策略节点只应公告对端合理推断为未知的交易但宁可过度公告over zealous也不要让对端交易池出现 nonce 缺口。3.2 GetPooledTransactions (0x09)[hash_0: B_32, hash_1: B_32, ...]语义指定一笔或多笔交易要求从远端节点的交易池中取回。无协议违例的硬性上限协议不限制一次可请求的交易数量同样受 devp2p 10MB 包限制约束但接收方可以自行对回复施加任意上限按大小或按服务时间且这不得被视为协议违例。推荐上限为降低未应答哈希造成的带宽浪费256 个哈希是文档推荐的理智上限。3.3 PooledTransactions (0x0a)[[nonce: P, receivingAddress: B_20, value: P, ...], ...]语义从本地交易池中取出远端通过GetPooledTransactions (0x09)请求的交易并返回列表中的每一项即主以太坊规范所描述的交易格式。顺序约束返回的交易必须与请求中的哈希顺序一致但允许跳过本地没有的交易。这样当响应达到大小上限被截断时请求方可以据此判断最后一个返回交易之后的所有哈希需要重新请求而最后一个返回交易之前的所有缺口哈希可视为不可用。空回复的边界条件仅当请求中的所有哈希都无法在池中命中时对端才可以回复空列表同时协议允许先公告、后不提供——如果某笔交易在公告与拉取之间被包含进区块节点有权不再提供它。四、Rationale 问答三个关键设计决策EIP-2464 的 Rationale 部分用问答形式澄清了三个关键取舍理解它们有助于真正吃透协议边界。Q1为什么GetPooledTransactions (0x09)只允许从交易池检索除交易池外以太坊中的交易总是以数百笔打包进区块体的形式存在现有网络检索也遵循这一数据布局。允许直接从数据库检索单笔交易没有实际用例反而会把昂贵的数据库读操作暴露到网络上。就交易传播而言也没有访问磁盘的必要——任何已落盘的交易最终都会随区块广播出去节点最坏情况下只是延迟几百毫秒拿到该交易。文档还提及区块传播或许能通过按需传输其中包含的交易进一步优化但这本身值得单独一个 EIP应当在需求明确后再放宽协议而不是提前设计届时维护一份近期区块包含交易的内存集合应该就足够了。Q2NewPooledTransactionHashes (0x08)是否需要针对磁盘去重与GetPooledTransactions同理公告去重也只应作用于交易池完全忽略磁盘。健康网络条件下交易的传播速度远快于其被打包进区块的速度因此新公告的交易已在磁盘上的情况几乎不存在。通过避免磁盘去重还能防范由远端交易公告发起的 DoS 折磨griefing。若想做到绝对严谨、避免公告去重时哪怕最轻微的数据竞争可以复用上文提到的近期已入块交易技巧把刚变 stale 的公告丢弃。Q3为什么不复用现有Transactions (0x02)作为回复消息EIP 初稿确实复用了Transactions (0x02)作为GetPooledTransactions的回复。但这会让客户端代码更复杂节点之间会持续以广播形式互发Transactions (0x02)难以区分众多消息中哪一条才是对请求的真正回复。将Transactions (0x02)gossip 广播与PooledTransactions (0x0a)请求响应拆分为独立消息既保持了语义清晰也为未来优化保留了协议灵活性——例如为请求/响应配对引入 request ID而这对于纯广播消息毫无意义。这一前瞻性设计直接催生了后续的 EIP-2481eth/66 request identifier。五、向后兼容并行版本与无需硬分叉EIP-2464 以向后不兼容的方式扩展了eth协议因此需要发布新版本eth/65。但 devp2p 支持同一线协议多版本并行运行所以eth/65的推出不需要客户端协调未升级的节点可以继续使用eth/64互通。更重要的是该 EIP 不改变共识引擎因此不需要硬分叉。它只是网络层devp2p 能力协商的优化任何客户端只要实现了新消息即可受益链上规则毫无变化。六、协议演进从 eth/64 到 eth/68 的完整链条EIP-2464 处于以太坊线协议版本演进的中间节点理解它的前后关系能更准确地定位其价值。仓库中的以下文档共同构成了这条脉络EIP-2364eth/64forkid 握手扩展在Status (0x00)消息中追加forkid字段源自 EIP-2124使握手阶段即可剔除不兼容节点。这是 eth/65 的直接前身也是 EIP-2464 的requires依赖。EIP-2464eth/65本文主体引入交易哈希公告与按需拉取。EIP-2481eth/66request identifier为eth协议所有请求/响应配对引入 64 位request_id使客户端能直接把响应匹配回待处理请求避免遍历全部挂起请求。其requires正是 2464——呼应了 EIP-2464 Rationale 中为未来优化保留灵活性的设计伏笔。EIP-4938eth/67移除 GetNodeData移除GetNodeData (0x0d)与NodeData (0x0e)消息fast sync 不再依赖哈希到状态节点的数据库映射改由 snap 协议的GetByteCodes/GetTrieNodes承担其requires同样包含 2464。EIP-5793eth/68公告中附加交易类型与大小将NewPooledTransactionHashes (0x08)从[hash_0, hash_1, ...]扩展为[types: B, [size_0, size_1, ...], [hash_0, hash_1, ...]]为 EIP-4844 blob 交易这类大体积交易提供按类型/大小选择性拉取与节流能力其requires为 2464、2481、4938。它直接继承并强化了 eth/65公告先行、按需拉取的设计哲学。此外EIP-2976Typed Transactions over Gossip定义了 EIP-2718 类型化交易在 devp2p 上的传输方式TransactionType || TransactionPayload并与上述各线协议版本回溯兼容——交易传播从传内容到传哈希再到传哈希 元数据始终以 eth/65 的公告/检索模型为地基。七、安全考虑与总结EIP-2464 官方文档的 Security Considerations 一节标注为None但通读全文可以发现其设计本身内嵌了多项安全考量防止 DoS 折磨公告与检索均限定在交易池内、不做磁盘去重杜绝了远端公告引发的昂贵磁盘读操作见 Rationale Q1、Q2软性上限防止资源独占4096 个公告哈希、256 个请求哈希的推荐值配合接收方可对回复施加任意上限且不视为违例的条款让节点有权按资源状况自我保护空回复与跳过语义请求方通过最后一个返回交易的位置即可推断哪些哈希需要重试、哪些已不可用避免在无响应哈希上反复浪费带宽。总结EIP-2464 用三个消息类型为以太坊交易传播引入了公告—请求—响应的异步模型将传播带宽复杂度从线性降为平方根把初始连接同步成本从 10s–100s MB 压缩到约 128KB。它不触碰共识、无需硬分叉、天然兼容多版本并行并为 eth/66 的 request ID、eth/68 的类型/大小元数据乃至后续大体积交易类型的传播优化铺平了道路。无论你是研究以太坊网络层实现还是对比各客户端go-ethereum 等的 txpool 同步逻辑eth/65 都是必须掌握的关键协议版本。版权说明本文所引用的 EIP-2464 原文遵循 CC0 协议 授权可自由引用与再分发。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-2464 深度解析：eth/65 交易公告与按需检索协议，把交易传播带宽从线性降到平方根
EIP-2464 深度解析eth/65 交易公告与按需检索协议把交易传播带宽从线性降到平方根【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读本文围绕以太坊改进提案 EIP-2464eth/65: transaction announcements and retrievals展开系统讲解以太坊 devp2peth线协议中三个新增消息类型——NewPooledTransactionHashes (0x08)、GetPooledTransactions (0x09)与PooledTransactions (0x0a)——的设计动机、消息格式、带宽收益与演进脉络。读完本文你将理解交易传播从全量广播走向哈希公告 按需拉取的关键机制掌握 4096/256 等软性上限的工程含义并能将 eth/65 放入从 eth/64 到 eth/68 的完整协议演进序列中理解其历史位置。一、背景区块传播有双轨制交易传播却只有单行道以太坊的eth网络协议在传播新区块时提供了两种互补手段全量广播通过NewBlock (0x07)将整个区块10s–100s KB直接发送给约平方根数量的直连节点哈希公告通过NewBlockHashes (0x01)仅发送区块哈希10s–100s B以线性数量的节点规模补齐广播覆盖不到的退化拓扑degenerate topologies。平方根广播足以触达所有连接良好的节点线性公告则用来兜底连接较差的网络形态。区块传播由此在带宽与覆盖之间取得了良好平衡。然而交易传播却缺少同样的双轨机制。交易只能依靠Transactions (0x02)全量广播而为了照顾退化拓扑交易无法像区块那样做平方根广播只能线性地转发给所有 N 个对等节点。结果同一个交易会在每条连接上被重复传输双向计算共 N 次而在理想世界里 1 次就足够——这是巨大的带宽浪费。另一个类似的问题是新建连接时的交易池同步两个节点刚握手时需要同步各自的交易池txpool但交易池本质上是一堆悬空交易的集合且远程无法去重。每个节点只能把自己完整的交易列表朴素地转给对方。当池中存有数千笔交易时一次朴素传输就要消耗 10s–100s MB 流量其中大部分是无用数据。随着以太坊交易吞吐量与交易体积持续上升交易传播已成为网络资源消耗的最大头。由于eth协议缺乏远程去重机制同样的数据在每一条网络连接上被反复传输绝大多数资源被白白浪费。二、eth/65 的核心方案哈希公告 按需拉取EIP-2464 向eth协议新增三个消息类型并据此发布新协议版本eth/65消息消息 ID方向作用NewPooledTransactionHashes0x08单向公告仅公告一批交易的哈希不含交易内容GetPooledTransactions0x09请求按公告的哈希向对端请求一批交易PooledTransactions0x0a响应回复对端的交易请求携带交易本体这套机制让节点在付出昂贵的数据传输之前先就哪些交易需要跨连接传输达成一致从而实现交易传播带宽从 O(peers) 降到 O(√peers)先对平方根数量的节点做哈希公告只有确实缺交易的节点才按需拉取不再对每个节点全量转发初始交易交换从 10s–100s MB 降到约 128KB首次建连时只需交换哈希集合即len(pool) * 32B ≈ 128KB每笔交易的 keccak 哈希恰好 32 字节。EIP-2464 的期望是通过这个微小的协议扩展将以太坊网络的全局运营带宽使用量降低至少一个数量级。三、消息格式与语义详解3.1 NewPooledTransactionHashes (0x08)[hash_0: B_32, hash_1: B_32, ...]语义声明网络中新出现、且尚未被打包进区块的一笔或多笔交易。为最大程度地帮助对端节点应将其认为对方可能不知道的所有交易都告知对方。无协议违例的硬性上限协议本身不限制一次可公告的哈希数量唯一的硬约束是 devp2p 网络包的 10MB 上限但4096 个哈希约 128KB是文档推荐的理智分块sane chunk避免单个数据包长时间独占一条网络连接。去重策略节点只应公告对端合理推断为未知的交易但宁可过度公告over zealous也不要让对端交易池出现 nonce 缺口。3.2 GetPooledTransactions (0x09)[hash_0: B_32, hash_1: B_32, ...]语义指定一笔或多笔交易要求从远端节点的交易池中取回。无协议违例的硬性上限协议不限制一次可请求的交易数量同样受 devp2p 10MB 包限制约束但接收方可以自行对回复施加任意上限按大小或按服务时间且这不得被视为协议违例。推荐上限为降低未应答哈希造成的带宽浪费256 个哈希是文档推荐的理智上限。3.3 PooledTransactions (0x0a)[[nonce: P, receivingAddress: B_20, value: P, ...], ...]语义从本地交易池中取出远端通过GetPooledTransactions (0x09)请求的交易并返回列表中的每一项即主以太坊规范所描述的交易格式。顺序约束返回的交易必须与请求中的哈希顺序一致但允许跳过本地没有的交易。这样当响应达到大小上限被截断时请求方可以据此判断最后一个返回交易之后的所有哈希需要重新请求而最后一个返回交易之前的所有缺口哈希可视为不可用。空回复的边界条件仅当请求中的所有哈希都无法在池中命中时对端才可以回复空列表同时协议允许先公告、后不提供——如果某笔交易在公告与拉取之间被包含进区块节点有权不再提供它。四、Rationale 问答三个关键设计决策EIP-2464 的 Rationale 部分用问答形式澄清了三个关键取舍理解它们有助于真正吃透协议边界。Q1为什么GetPooledTransactions (0x09)只允许从交易池检索除交易池外以太坊中的交易总是以数百笔打包进区块体的形式存在现有网络检索也遵循这一数据布局。允许直接从数据库检索单笔交易没有实际用例反而会把昂贵的数据库读操作暴露到网络上。就交易传播而言也没有访问磁盘的必要——任何已落盘的交易最终都会随区块广播出去节点最坏情况下只是延迟几百毫秒拿到该交易。文档还提及区块传播或许能通过按需传输其中包含的交易进一步优化但这本身值得单独一个 EIP应当在需求明确后再放宽协议而不是提前设计届时维护一份近期区块包含交易的内存集合应该就足够了。Q2NewPooledTransactionHashes (0x08)是否需要针对磁盘去重与GetPooledTransactions同理公告去重也只应作用于交易池完全忽略磁盘。健康网络条件下交易的传播速度远快于其被打包进区块的速度因此新公告的交易已在磁盘上的情况几乎不存在。通过避免磁盘去重还能防范由远端交易公告发起的 DoS 折磨griefing。若想做到绝对严谨、避免公告去重时哪怕最轻微的数据竞争可以复用上文提到的近期已入块交易技巧把刚变 stale 的公告丢弃。Q3为什么不复用现有Transactions (0x02)作为回复消息EIP 初稿确实复用了Transactions (0x02)作为GetPooledTransactions的回复。但这会让客户端代码更复杂节点之间会持续以广播形式互发Transactions (0x02)难以区分众多消息中哪一条才是对请求的真正回复。将Transactions (0x02)gossip 广播与PooledTransactions (0x0a)请求响应拆分为独立消息既保持了语义清晰也为未来优化保留了协议灵活性——例如为请求/响应配对引入 request ID而这对于纯广播消息毫无意义。这一前瞻性设计直接催生了后续的 EIP-2481eth/66 request identifier。五、向后兼容并行版本与无需硬分叉EIP-2464 以向后不兼容的方式扩展了eth协议因此需要发布新版本eth/65。但 devp2p 支持同一线协议多版本并行运行所以eth/65的推出不需要客户端协调未升级的节点可以继续使用eth/64互通。更重要的是该 EIP 不改变共识引擎因此不需要硬分叉。它只是网络层devp2p 能力协商的优化任何客户端只要实现了新消息即可受益链上规则毫无变化。六、协议演进从 eth/64 到 eth/68 的完整链条EIP-2464 处于以太坊线协议版本演进的中间节点理解它的前后关系能更准确地定位其价值。仓库中的以下文档共同构成了这条脉络EIP-2364eth/64forkid 握手扩展在Status (0x00)消息中追加forkid字段源自 EIP-2124使握手阶段即可剔除不兼容节点。这是 eth/65 的直接前身也是 EIP-2464 的requires依赖。EIP-2464eth/65本文主体引入交易哈希公告与按需拉取。EIP-2481eth/66request identifier为eth协议所有请求/响应配对引入 64 位request_id使客户端能直接把响应匹配回待处理请求避免遍历全部挂起请求。其requires正是 2464——呼应了 EIP-2464 Rationale 中为未来优化保留灵活性的设计伏笔。EIP-4938eth/67移除 GetNodeData移除GetNodeData (0x0d)与NodeData (0x0e)消息fast sync 不再依赖哈希到状态节点的数据库映射改由 snap 协议的GetByteCodes/GetTrieNodes承担其requires同样包含 2464。EIP-5793eth/68公告中附加交易类型与大小将NewPooledTransactionHashes (0x08)从[hash_0, hash_1, ...]扩展为[types: B, [size_0, size_1, ...], [hash_0, hash_1, ...]]为 EIP-4844 blob 交易这类大体积交易提供按类型/大小选择性拉取与节流能力其requires为 2464、2481、4938。它直接继承并强化了 eth/65公告先行、按需拉取的设计哲学。此外EIP-2976Typed Transactions over Gossip定义了 EIP-2718 类型化交易在 devp2p 上的传输方式TransactionType || TransactionPayload并与上述各线协议版本回溯兼容——交易传播从传内容到传哈希再到传哈希 元数据始终以 eth/65 的公告/检索模型为地基。七、安全考虑与总结EIP-2464 官方文档的 Security Considerations 一节标注为None但通读全文可以发现其设计本身内嵌了多项安全考量防止 DoS 折磨公告与检索均限定在交易池内、不做磁盘去重杜绝了远端公告引发的昂贵磁盘读操作见 Rationale Q1、Q2软性上限防止资源独占4096 个公告哈希、256 个请求哈希的推荐值配合接收方可对回复施加任意上限且不视为违例的条款让节点有权按资源状况自我保护空回复与跳过语义请求方通过最后一个返回交易的位置即可推断哪些哈希需要重试、哪些已不可用避免在无响应哈希上反复浪费带宽。总结EIP-2464 用三个消息类型为以太坊交易传播引入了公告—请求—响应的异步模型将传播带宽复杂度从线性降为平方根把初始连接同步成本从 10s–100s MB 压缩到约 128KB。它不触碰共识、无需硬分叉、天然兼容多版本并行并为 eth/66 的 request ID、eth/68 的类型/大小元数据乃至后续大体积交易类型的传播优化铺平了道路。无论你是研究以太坊网络层实现还是对比各客户端go-ethereum 等的 txpool 同步逻辑eth/65 都是必须掌握的关键协议版本。版权说明本文所引用的 EIP-2464 原文遵循 CC0 协议 授权可自由引用与再分发。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考