节点广播交易为什么要带类型和大小？EIP-5793与eth/68协议

只发哈希的公告为什么浪费带宽

以太坊的全节点靠 gossip 机制互相转发交易：节点看到一笔新交易，先向邻居广播它的哈希，邻居如果没见过，再主动来取整笔交易。这个先报号、再取货的流程在 EIP-5793 之前有一个明显缺陷——公告里只有哈希。哈希本身不携带任何类型和体积信息。接收节点收到一串看不懂的哈希，只能先取回交易，解析之后才知道这是什么类型的交易、自己是否支持、体积是否超过自己的处理预算。对带宽敏感或配置了过滤规则的节点来说，这些取回是纯粹的浪费。

EIP-5793 的修复方式很直白：在 eth 协议的第68版里，给 NewPooledTransactionHashes 这条公告消息追加两个字段——每笔交易的类型和按 EIP-2718 定义计算的字节大小。类型沿用 EIP-2718 的交易类型编号体系，大小则让接收方在拉取之前就能做预算判断。这份 EIP 属于 Networking 类标准，作者是 Marius van der Wijden，官方仓库中标注的状态是 Final，也就是说它已经进入正式规范，成为现行节点间协议的一部分。

拉取决策提前到哪一步

有了类型和大小，节点的决策链条整体前移。举几类典型情形。不支持某类交易的旧版本客户端，看到类型字段就能直接跳过对应的哈希，不再发起注定失败的取回。配置了内存池限额的节点，可以按大小字段筛掉超预算的交易，避免为大交易支付带宽后又丢弃。带类型偏好的中继或监测服务，可以在协议层就只订阅自己关心的那一类。这些过滤过去都发生在取回之后，现在发生在取回之前，省下的正是往返流量。

值得注意的是，这一改动只影响公告消息，交易本身的请求与响应格式没有变，也不改变任何共识规则或交易有效性判断——它纯粹是传输层的效率优化。节点之间的eth协议版本需要协商，支持eth/68的节点与支持更早版本的节点可以共存，只是退回旧的先取后筛行为。

对普通用户和运维者意味着什么

用户一般不会直接感知这层协议：转账、Gas、确认速度都不受它影响。真正关心它的是两类人。一是自跑节点的运维者：网络里公告消息非常高频，每次公告多带一个类型和一个大小字节，换来的是大幅减少无效拉取，节点对外带宽账单和内存池压力都更可控。二是做交易监控、MEV 观测或 Mempool 分析的服务开发者：从公告流里就能按类型分流数据，不需要先全量下载再过滤，索引服务的资源模型因此更简单。

从更大的图景看，EIP-5793 是以太坊持续修剪 gossip 低效环节的一个小样本。这类网络层 EIP 从不登上升级公告的头条，但节点越多、交易类型越丰富，它们的价值越扎实。

风险提示：本文为网络协议机制的技术性介绍，不构成投资建议，不构成对任何节点软件或服务的推荐。部署节点前请核对所用客户端的官方文档。

协议版本是怎么协商的

节点连接时的握手里会交换各自支持的能力清单，双方自动取共同支持的最高 eth 版本，因此升级是渐进的：新节点对老邻居自动降级回旧公告格式，对等新邻居则启用带类型与大小的新格式，没有任何开关需要人守。运维排查同步慢、带宽异常时可以顺手利用这一点：通过节点的接口查询对端使用的协议版本，能区分带宽浪费来自旧式先取后筛，还是另有原因。另一条值得记住的边界是，公告带类型不等于节点会优先收某类交易——内存池的准入、计价与驱逐逻辑由各自的规则决定，这层协议只优化谁来取货，不改变交易竞争的规则。