在以太坊上发一笔交易，失败了为什么不告诉我是因为什么？这个问题有一个技术性答案：失败原因确实存在——REVERT 指令会把一段“回退数据”（通常是 Solidity 自定义错误的选择器加编码参数）留在执行环境里——但它从不写进任何会上链的东西。回执里那条交易的日志列表是空的，状态字段只说失败。想拿到原因，工具要么调 debug 类追踪接口让节点把整笔交易从头重放一遍、在 REVERT 那一刻把内存里的字节抠出来，要么依赖钱包自己提前发的解释性日志。EIP-7889 想把“查原因”变成一次普通查询。
方案：回退自动发日志
规则一句话说完：任何以非零长度数据执行的 REVERT，都必须同时发出一条等价于 LOG1 的日志——固定主题加上回退数据的原始字节（长度截断到上限）。不需要新操作码，不需要新 RPC 方法，日志结构就是合约世界用了几十年的那套 topic 加 data，区块浏览器、索引器和客户端库天然认识。向后兼容性上唯一的语义变化是：一笔失败的交易从此可能携带至多一条日志——此前失败交易不带日志是所有人的隐含假设，任何把这个假设写进代码的工具需要复查。
账怎么算才安全
免费写日志当然有滥用面。提案的安全考量算的是这样一笔账：一笔回退的交易仍然要付至少 21000 的固有 Gas，而单条 LOG1 的开销远小于这个数，所以恶意者想靠制造失败交易灌日志，每字节的成本反而被固有费垫高——这个成本差保证了“多发日志”不构成放大状态存储的新路径。直觉线是这样的：攻击者想让你多存一百字节，得先付掉一整笔交易的固定入场费；相对收益极差。
现状含义与状态
对普通用户的直接收益很具体：钱包弹窗从“交易失败”变成“失败：滑点超过你设的上限”这类可读原因；对开发者，CI 里读一眼回执就知道断言死在哪。对节点运维，追踪请求的昂贵重放压力下降。状态方面，EIP-7889 创建于 2025 年 2 月 20 日，目前标记为 Stagnant，未进入任何已激活升级，日志主题值与数据上限在文中还是待定项——也就是说连“发出来的日志长什么样”都还没有可依赖的定稿，工具方不宜提前按草案实现解析逻辑。
排查动作清单
在这条日志真正上链之前，普通用户遇到失败交易仍可用三步缩小原因面：第一步，用同一参数向节点发一次模拟调用，多数节点会在错误信息里带回退数据，能立刻知道是滑点、权限还是额度问题；第二步，把回退数据的十六进制前四位对照常见错误选择器（工具站可反查函数与错误名）；第三步，核对钱包给的余额、授权与路由报价是否本来就是失败的可解释原因。三步都做完仍然不明，再把原始数据连同块高发到客户端或钱包的支持渠道，而不必给任何第三方私钥。
快速问答
问：现在所有失败交易都查不到原因吗？ 答：用追踪接口或模拟调用可以拿到回退数据，但那是额外请求，不是回执里的现成字段。
问：合约怎么让失败原因更可读？ 答：用带名字与参数的自定义错误而非裸 require 字符串，选择器可反查。
问：这条日志会进正常交易的回执吗？ 答：不会，它只在交易确实执行了 REVERT 时产生，成功交易行为不变。
风险提示：本文仅描述协议提案，不构成投资建议；据回执判断交易结果时，请同时核对链上状态与你发起的模拟调用。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。