把一笔签好名的交易发上链，今天几乎所有工具走的都是同一条流水线：调用 eth_sendRawTransaction 拿到交易哈希，然后每隔若干秒去问一次 eth_getTransactionReceipt，问到 null 就继续等。链路要是不顺，还得再调一次账户接口确认是不是序号跳了号。EIP-7966 提议给这条流水线做减法：一个名为 eth_sendRawTransactionSync 的方法，把提交和等回执合并成一次请求，等不到就带结构化错误返回。提案目前是 Draft（草案）状态，本文按草案文本拆解设计，不能按现成功能使用。
草案定义的参数与返回
方法收两个参数：第一个是必填的已签名交易十六进制数据，与现有发送方法完全一致；第二个是可选的等待上限（毫秒），必须是不大于节点配置上限的正整数。节点的处理顺序在规范里写得很细：入池前先检查交易能否立即执行——序号比账户期望值高（nonce gap）就不进池，直接报错误码 6，并在错误数据的 data 字段里回填十六进制表示的期望 nonce；因为其他原因暂不可执行的报错误码 5，同样不进池；能立即执行的才按原语义进池，然后同步等待回执。超时了还没等到回执，报错误码 4，data 字段带回交易哈希。也就是说三个错误码各自对应三种完全不同的下一步：4 是交易已进池只是没打包（去查内存池与费用），5 是压根没进池（排查账户与状态），6 是序号错位（对齐 nonce 后重发）。
提案还建议节点侧超时可配置，推荐值为两秒，并允许根据网络实况动态调整。
它省掉的到底是哪一段
轮询模式的代价分三层。第一层是延迟：提交一次、每次查询一个来回，确认反馈天然是若干个往返之和；同步方法在服务端内部等回执，把”问—睡—再问”压成一次长请求，提案估算整体提交到确认延迟约减半。第二层是流量与配额：高频应用每笔交易额外产生的查询请求会占用 RPC 配额，轮询和订阅两种消费方式的区别见 监控工具怎么知道事件发生了：轮询与订阅推送的分工。第三层是错误质量：现有流程里 nonce gap 常常要再查一次账户状态才能确诊，草案直接把期望 nonce 塞进错误响应，省掉一次往返也减少一次误判。对区块时间以毫秒计的链与 Layer2，这套动机更强；对主网这种十秒出块的链，收益相对温和。
为什么说现在还不能当既成事实
Draft 在 EIP 流程里意味着仍在设计讨论，可能改参数、可能改错误码、也可能迟迟没有客户端实现。规范里的行为全部用 MUST/SHOULD 语气的要求描述”实现应当如何”，而不是”哪家节点已经支持”。普通用户此刻能做的只有观察：你用的钱包和 RPC 服务商如果实现了它，一定体现在文档的方法列表里；对账脚本如果要用，必须做好方法不存在的回退分支，退回传统发送加轮询的组合，别把主链路押在一个草案方法上。
对钱包和产品开发者的现实含义
即便未来有节点实现了这个方法，它改变的也只是提交与等待的交互形状，交易本身在链上的命运不变——费用竞争、重组、重新打包的风险，和 一笔手续费的三本账：钱包估算、签名上限与链上回执怎么对上 讲的费用三本账里描述的一样照常存在。同步等待还会带来一个新的运维点：长连接挂起两秒与短平快的轮询相比，对网关超时、负载均衡空闲回收都更敏感，产品端需要把客户端超时配得比节点超时更长，否则会出现”节点还在等、客户端先断线”的错位。这些细节恰是草案阶段留给实现者的空间。
一句话定位
把 EIP-7966 理解为”把轮询写回服务端”的接口实验：用一次请求换掉一串请求，同时把三类发送失败的诊断信息标准化。状态以提案页为准，读机制、备前瞻，不指导你今天改代码。
本文为机制科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。