加速之后，网页为什么显示异常
一笔交易迟迟不确认，你在钱包里点了”加速”，钱包换掉 Gas 价格重新签名广播，新交易几秒后落块，看起来一切顺利。问题出在网页这一侧：dApp 记的还是旧交易的哈希，它会按旧哈希一遍遍查区块，查到的永远是”不存在”。于是页面要么一直转圈，要么干脆报错，让你以为操作失败了，进而重试一次造成重复操作。EIP-2831 就是冲着这段信息断层来的：它建立在 EIP-1193 的 Provider 事件模型上，提出当钱包做了替换时，应当主动发出事件告诉页面上”旧的已被新的顶掉”。提案 2020 年 7 月提交，状态停留在 Stagnant，没有被主流钱包完整实现，但它对”替换”的分类定义至今仍是理解这类故障最有用的框架。
替换的判定条件先说清楚
提案给”交易替换”下了一个明确定义：在原始交易被打包之前，用同一个 nonce 和提高了至少百分之十的 Gas 价格再发一笔新交易。这一定义与 钱包的“加速”和“取消”按钮背后：替换交易是怎么起作用的 里讲的替换机制是同一套规则，提案把它搬进接口层的意义在于：只要发生这种结构的事件，Provider 就不该沉默。在此之上，它把替换细分为三个事件，页面开发者可以按事件类型走不同的修复逻辑。
tx_speedup：只动了价格的那种
tx_speedup 指用户想加快打包、仅调整 gasPrice 的替换。提案要求成立条件相当严格：新旧交易的 nonce、收款地址 to、转出价值 value、输入数据 data 四项必须完全相同，唯一变的是价格。这个约束对用户很有价值——如果你的”加速”动作改动的不止价格，比如把某笔授权换成了另一笔，那按这个定义它就不算 speedup，而是一次全新操作，页面有权不认。事件负载带四个字段：旧交易哈希 oldTx、新交易哈希 newTx、两笔共用的 nonce、签名地址 from。对开发者，这是把”旧哈希作废、请按 newTx 继续跟”写成了机器可读的通知。
tx_cancel 与更宽泛的 tx_replacement
tx_cancel 是取消场景：替换交易必须与旧交易同 nonce、同 from、同 to，价值为零、data 为空——也就是把排队的 nonce 用一笔什么都不做的自我转账占掉，让旧交易永远失去被执行的机会。剩下的情形归入 tx_replacement：只要发生了替换，无论结构是否吻合前两类，Provider 都至少应发这个通用事件。三个事件形成从精确到兜底的层级：speedup 和 cancel 是两种可自动恢复的特例，replacement 提醒页面”状态机需要重新同步”。提案同时要求这些事件按标准 EventEmitter 方式实现，让页面可以用统一姿势监听。
现实里大多数组合并没有实现它
提案停留在 Stagnant 的原因不难理解：主流钱包对”替换成功后告诉页面什么”各自有私有约定，有的沿用旧哈希继续返回状态，有的干脆让页面超时。对普通用户，这变成了需要自己动手的核对纪律。点了加速或取消之后，正确的确认顺序是：先在钱包的交易记录里找到那个 nonce 的最终去向，再到区块浏览器按 nonce 或按你自己的地址看该序号上最终落块的是哪笔（参见 区块浏览器怎么读：确认数、失败原因和交易状态逐项解释 的阅读方法），确认内容是预期那笔还是取消用的空转账。判断依据永远落在 nonce 上，而不是页面上停留的旧哈希。
一条值得记住的分层原则
把这套框架反过来用，可以总结成排查口诀：页面显示失败不等于链上失败；哈希对不上不等于操作没发生；同 nonce 有交易落块，就该以那笔的实际内容为准。EIP-2831 没有改变任何共识规则，它想补的只是钱包与网页之间的一句”嘿，这笔换掉了”。在补上这句话的标准普及之前，用户的手动核对就是最后一道防线。
补一个容易被忽略的时间细节：替换只在原交易尚未被打包时才成立。如果旧交易其实在你点加速的前一瞬已经进块，随后广播的”加速版”会因为同 nonce 已被执行过而变成无效交易，永远停在待处理状态后被丢弃。这时候页面上的异常提示反而接近真相——不是替换没通知，而是根本没有替换发生。分辨方法仍是回到 nonce：序号上落块的是哪一笔、内容是不是你预期那笔，看一眼便定案。本文为机制解读，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。