Receipt与Confirmation回调的区别及以太坊交易有效性验证问题

核心问题解答 #

1. 拿到交易收据是否意味着交易脱离pending状态？ #

是。getTransactionReceipt 返回非null值的唯一前提是交易已经被打包进合法区块，只要能拿到收据，交易一定不在pending队列中。

2. 仅靠receipt回调能否确认交易真实生效？ #

不能，存在两个核心漏洞：

• 收据仅能证明交易被打包，不能证明交易执行成功：你需要额外判断收据中的status字段，status = 1代表交易执行成功，status = 0代表交易被打包但执行失败（gas仍会扣除，业务逻辑未生效）。
• 刚打包的区块存在链重组风险：刚出1个块的交易有概率被网络回滚，仅拿到1块确认的交易并不完全可信。

3. receipt和confirmation回调的结合使用方案 #

两种回调的定位完全不同，配合使用流程如下：

• 第一步：优先监听receipt回调
  • 拿到收据后首先校验status字段，若为0直接判定交易执行失败，终止后续校验流程。
  • 若status为1，进入确认数等待阶段。
• 第二步：监听confirmation回调累计确认数
  • 普通业务场景（小额转账、低价值交互）：等3~6个确认即可判定交易最终生效，不会被网络回滚。
  • 高安全场景（大额转账、资产交割）：建议等12个及以上确认再判定交易生效。

如果采用轮询getTransactionReceipt的方式验证，逻辑完全一致：拿到收据校验status通过后，用当前最新块高减去收据中的blockNumber得到当前确认数，达到阈值后即可判定交易有效。

内容的提问来源于stack exchange，提问作者Daltrey Waters