报错也被套娃：ERC-7751 打包上抛的回退让失败原因可追溯

在聚合器或 NFT 市场发起一笔复杂交易，结果失败了，钱包只甩给你一句 execution reverted——可到底是谁失败的：代币额度不够、市场手续费条件变了，还是中途某个合约余额检查没过？调用链越深，这类“失真报错”越常见。ERC-7751 打包上抛的回退（Wrapping of bubbled up reverts）想把失败现场规范化：让回退带着“案发地点”一起上抛。标准状态为 Final，创建于 2024 年 8 月 6 日，文档点名这类格式便于 Etherscan、Tenderly、Foundry 一类工具生成更准确的调用栈展示。

一种统一的打包错误

规定只有一种错误形状：WrappedError(address target, bytes4 selector, bytes reason, bytes details)，合约在包装下层合约的回退时必须以它抛出，对应的错误签名是 0x90bfb865。四个字段各有分工：target 是真正回退的那个合约地址；selector 是失败函数的四字节选择器——如果失败发生在一笔不带数据的 ETH 转账上，规定选择器为 bytes4(0)；reason 是原始回退的裸字节，一字不改带上；details 可选，通常是抛出方合约自己声明的一个自定义错误做补充说明，没有额外上下文时留空字节。

为什么非要标准化？调用链的固有缺陷是“逐级转述会丢信息”：A 调 B、B 调 C，C 因为余额不足失败，B 若只是简单 revert，A 拿到的往往是一团无法归因的字节。统一格式后，回退可以多层嵌套：外层把内层的 WrappedError 塞进自己的 reason 字段再抛，形成一串可逐层反解析的证据链——只要中间任何一层守规矩。

用户端怎么用这个标准

你不写合约也能受益于它。第一类用法：看交易失败详情。支持解析 7751 的区块浏览器或模拟工具会把 WrappedError 逐层解包，你一眼看到“失败发生在市场合约的 fulfillOrder，原因是价格保护条件未满足”，而不是全局回退四个字。第二类用法：排查授权与余额。NFT 结算失败最常见的真实原因就是 ERC-721 未授权、ERC-20 额度不足、原生币余额差一点 gas——打包错误让“到底差在哪个环节”变得可读，省去逐层猜。第三类用法：验证报错来源。target 是个地址，你可以直接核对它是否是你预期交互的那个合约——报错信息与合约地址对不上，本身就是被重定向或多跳路由的信号。

边界也要讲：7751 是“报错更好读”，不是“错误更好治”。标准 2024 年才创建，生态渗透需要时间，大量存量项目不会回头补做包装；遇到没有 WrappedError 的失败，仍然回到模拟交易、查事件、看钱包 trace 的老路径。对开发者，标准是纯可选、可增量采用的——从当前版本开始对新的调用做包装即可，不必改动已部署合约。

顺带一个调试习惯：凡是复杂协议交易，失败后先看模拟里最后成功的那一步停在哪里——在 7751 的语境里，这一步往往与 target 指向同一个合约；把该地址抄下来去浏览器核对是否为项目官方公布地址，一次失败就顺带完成对你合约清单的一次校验。对自动化脚本，捕获 0x90bfb865 前缀的 revert data 并递归解包，比正则匹配字符串原因可靠得多。

还有一条容易忽略的规定：details 若使用，必须是抛出该 WrappedError 的合约自己声明的自定义错误的 ABI 编码——不是任意字符串，也不是原始调用数据。这条约束让工具在解包完下层回退后还能继续解析上层补充语境，两层信息各自有结构。顺带区分两个动词：被调用合约的原始回退进 reason，本合约想额外交代的语境才进 details，混填会让嵌套解析失去意义。回退签名 0x90bfb865 是所有工具识别这类错误的锚点，脚本按前缀匹配即可分流。 最后提醒：本文讲调试与错误格式机制，不构成投资建议；交易失败的资金含义以具体协议逻辑为准，重试前先确认资产当前状态。