给合约发一笔交易之后，钱包和脚本最常见的动作就是反复追问节点：这笔交易进块了吗。EIP-8072 想把这个动作反过来——不再由你一遍遍问，而是让节点在交易被打包的那一刻主动通知你。这份提案的全名叫 Transaction Inclusion Subscription（交易包含订阅），2025 年 10 月 31 日提交，目前在以太坊官方仓库里的状态是 Draft（草案），还没有被任何一次网络升级激活。下面按它解决什么、怎么调用、参数怎么选、什么时候轮不到它来讲。
它针对的是发送与确认割裂的问题
今天的标准流程是两段式：先调 eth_sendRawTransaction 把签名交易丢进网络，再不停调 eth_getTransactionReceipt 查回执。中间那段等待完全靠轮询消耗连接和带宽。EIP-7966 走过另一条路——eth_sendRawTransactionSync，把 HTTP 连接一直挂着直到出回执，提案文档自己就列了这条路的毛病：每笔交易占用一条连接、多个交易难以并行、超时参数要按链的出块节奏细调。EIP-8072 选择的方案是借用各主流客户端早已实现的 eth_subscribe 长连接机制（WebSocket 订阅），把发送与等待合并进同一个订阅。eth_subscribe 本身并不在 EIP-1193 的接口规范里，属于各家实现的通用扩展，这也是读这类提案要先建立的口径：规范文本描述的是节点该怎么做，不等于你现在连的公共 RPC 一定开放了这个开关。
订阅请求只有两种形状
第一种是发送并监听：在订阅参数里放进 transaction 字段（完整签名交易的十六进制），节点必须先立即把它广播到网络，同时开始盯打包结果。第二种是只监听已发出的交易：放进 hash 字段（32 字节交易哈希）。两个字段有且只能有一个，都填或者都不填，节点必须返回错误码 -32602（参数无效）。订阅成功后节点回一个订阅 ID，之后的打包事件都推到这条订阅通道上。
includeReorgs 决定你看到多深的后续
第三个参数 includeReorgs 默认是关。关闭时，第一次”已打包”通知发出后订阅自动结束，重组不再监视；打开时，订阅会继续报告重组（reorg）、重新打包与最终化事件。对用户侧的含义很直白：只要通知到账、转币等低价值场景，默认档够用；替别人代付、批量结算这类”进了块也可能被撤”的资金动作，才值得开重组监视。它与发一笔交易要来回问三次回执？EIP-7966 想把发送和回执合并成一个请求的同步等待构成同一问题的两个方向：一个占连接等结果，一个挂长连接收结果。
它排不进你现在的排障手册
要清醒地划边界：EIP-8072 是 Draft，不是以太坊已上线的功能；写”以太坊已支持交易打包订阅”的文章与现状不符。交易卡在等待中的第一排查仍然是节点广播、手续费与 nonce 序列，方法在交易卡在“等待中”怎么办？Pending 状态的排查、加速与取消里已经写过；自建监听服务在轮询与订阅推送之间怎么取舍，监控工具怎么知道事件发生了：轮询与订阅推送的分工有专门对比。此外，订阅推送解决的是”什么时候知道”，不是”为什么没打包”——手续费出价不足、被更高费替代的交易挤掉，这类问题订阅事件里看不见，仍需回到费用与替换交易的逻辑里去查。还有一类容易被忽略的失败：订阅通道断开期间的打包事件不会自动补发，重连后要么按交易哈希重新订阅一次，要么回到回执查询兜底。工程上稳妥的做法是把订阅当加速器、把查询当保底绳，两条腿走路——这也正是订阅类方案必须与其他确认手段长期共存的原因。
对普通用户意味着什么
普通用户短期内不会直接和 EIP-8072 打交道，受影响的是钱包和工具商：确认提示可以从”反复刷新”变成”一次订阅、事件驱动”，界面更省流量、状态更及时。但对任何声称已用”打包订阅”提速的产品，可以反问一句它连的是哪类节点、重组监视开没开、断线后事件补不补。规范状态、参数名与错误码以官方提案文本为准。本文为机制科普，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。