以太坊的交易传播是两步舞：节点先用一条公告消息告诉邻居我这儿有新交易，邻居再按公告来把正文取走。公告里只有三样东西——交易哈希、类型和体积。EIP-8077 在 2025 年 11 月提出把公告扩容：在既有字段之外，再补上发送方地址与这条交易的 nonce。提案标注为草稿，挂在 EIP-7642 的协议版本框架上。看起来只是多塞两个字段，解决的却是内存池调度多年的老大难。
只看哈希的公告为什么不够用
节点从好几个邻居同时收到几十条公告，得决定先向谁拉哪笔。可公告里没有正文信息，节点只能按到的先后排队。麻烦在于交易是有依赖顺序的：同一地址的后续交易，要等前一号的 nonce 落地才能被打包。如果节点先拉了一笔前面缺号的老乡，这笔交易在自己的内存池里就是不可包含的占位货，白占带宽与缓存；更糟的是它还会挤掉本可以立刻转发的合法交易。提案把这种困境写得很具体：拉回带缺号的交易，等于自己制造了需要回填的坑，而回填在没有发送方视角时近乎碰运气。
地址加 nonce 能解锁什么
有了发送方与序号，调度器的视野完全不同。它可以先算出这笔交易离当前账户序号差几步，差为零的先拉，差得远的缓拉或者干脆观望；它还能识别同一发送方连续一串交易，找其中性价比合适的那笔直接要，把缺的号段留给后续。对费用波动期的追价交易也友好：替换交易本质是同一地址递增 nonce 的新一号，节点能一眼判断该丢旧公告还是等正文。这些决策全部发生在拉取之前，省下的不只是带宽，还有内存池的有限名额。
为什么不干脆改推送
提案的动机章节顺带比较了另一个方向：把公告改成直接推正文。以太坊的折中传统是小交易对少数邻居做推送、其余一律公告，就是为了防带宽放大。多带地址与 nonce 的公告体积只增长一个量级很小的定长段，却把调度自由度带回来，这笔交换在提案看来远比分两种模式更划算。同时它也兼容 EIP-8094 那条 blob 交易按内容寻址的路线——两条改进处理的是同一份公告消息的不同字段。
带宽账与降级
任何给公告加字段的提案都要过带宽这一关。提案自己算了账：公告消息目前被频繁交易流放大得厉害，增加地址与 nonce 会让公告体积上升，但换来的是更少的无效正文拉取与更少的重试，净账在模拟与实现中再校准。兼容性上，这条改动属于协议版本协商的新版本能力，不支持的旧节点照旧按老格式交流，网络不会裂开。
快速问答
问：这会影响普通用户发交易吗？ 答：不会改变钱包或交易格式，只影响节点之间怎么传播与调度，收益体现为内存池更稳、缺号占位更少。 问：nonce 是指区块头那个随机数吗？ 答：不是。这里是账户序号，表示该地址第几笔交易，与挖矿工作量里的随机数毫无关系。 问：草案落地了吗？ 答：状态为草稿，需经客户端实现与协议评审，未进入任何升级清单。
一次填坑的完整旅程
设想某节点同时收到同一地址的第 7、8、9 号三条公告，而它本地只看到第 6 号已确认。旧流程下它可能先拉回第 9 号：正文到手，却因缺 7、8 只能压箱底，还顺手把邻居的带宽用了。新流程下公告自带地址与 nonce，节点能立刻判断该先补哪一号、哪几号可以等同一批邻居捎带来，甚至识别出这是连续追价的一串替换，只取最贵的一号。调度决策从盲选变成查表，这类改进的收益不在单点，而在拥堵期被放大的那批无效拉取。
风险提示：本文为节点网络机制科普，不构成投资建议；文中提案状态以仓库为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。