铸造失败到底为什么：ERC-838 想把报错装进 ABI 的尝试

抢铸造时钱包弹出一句执行失败，Gas 照扣，原因不明——这是 NFT 新手最憋屈的一次交互。链上失败的回执叫 revert，合约可以把一段原因塞进 REVERT 操作码的 reason 参数里，但在早期规范里那只是一段自由文本，应用拿到后最多原样显示。ERC-838 想做的是把这段文本变成有名字、有参数的错误：ABI 里先声明这个错误，失败时返回带选择器的编码，工具端据此翻译成用户看得懂的话。标准创建于 2020 年 8 月 20 日，仓库记录状态为 Draft，作者之一是社区里长年回答 EIP-838 进度问题的 Federico Bond。

ABI 里多一种声明

按规范，编译产物的 JSON ABI 里应当像函数和事件那样加入 error 项：一个错误对象必须有 name 和 arguments 两个键，arguments 的类型写法与函数入参一致，type 字段固定写 error。原文给的例子是一个余额不足错误：名字 InsufficientBalance，带一个 uint256 参数 amount。错误的选择器和公共函数、事件一样由函数式签名计算得到，客户端拿着返回数据的前 4 字节就能回查 ABI 找到对应声明；参数编码与函数返回值同路。为了让新旧工具共存，方案借用了一个前缀约定：结构化错误以 0 字开头，而 Solidity 当时允许的自由文本 reason 恰好有空间用 uint256(0) 开头的形式作区分——没实现这份规范的工具可以直接忽略整段。

两个顺带的扩展

提案还描述了两个可选延伸。其一是给人看的消息：在错误声明上方写 NatSpec 注释，把参数插值进一句人话模板，比如转账金额不够时提示中的金额就用真实参数填出来；这解决了机器可读之后最后一公里的可读性。其二是函数声明自己能抛哪些错：ABI 的函数项下加 errors 键，调用前应用就知道这个函数可能用哪些失败原因拒绝你。原文同时提醒，同名不同参的错误会产生不同选择器，重名歧义要额外设计。

从提案到落地之间

把它接到日常排障上，能提炼出一条清楚的操作线。钱包里显示的执行失败，第一手资料永远是那条交易的输入数据与返回数据：返回体为空多半是 Gas 不足或通用 require 未带消息，返回体以 08c379a0 一类选择器开头说明是可解码的 Error(string) 或自定义错误，工具能顺着 ABI 把参数还原成人类字段——这正是本提案当年梦想的场景。读不到结构化原因时，重放交易做只读模拟、比对手里各笔调用的先后条件，通常能定位是哪一道检查拦住了你。需要提醒的是边界：失败原因解释的是这次为什么没执行成功，不构成重试指南，尤其在Gas高企的时段，反复重签同一笔失败交易只是连续捐手续费；能改条件的先改条件，不能改的先查明原因为止。

顺带澄清一个常见误解：revert 不等于资金损失之外还有追责渠道。结构化错误让失败原因变得可检索之后，同一份合约、同一条失败原因在浏览器和讨论区里可以被聚合成一类问题——项目方配置错了价格上限、Gas 参数默认值不合理，这类系统性缺陷会被大量重复的选择器暴露出来。读者在 Mint 页面反复失败时，不妨先按合约地址搜一搜这个错误选择器的历史记录：大面积同错说明问题在服务端，你的重试只是给全网拥堵添柴；零星独错才更可能是自己地址条件不满足。这一层排查思路本身就是 ERC-838 设想中能带来红利的用户侧收益。

这份草案本身长期停在 Draft，Rationale 与安全考量两节甚至仍是待讨论的占位。但它指的方向最终没有落空：Solidity 后来正式引入了自定义错误机制，编译器把 error 声明编进 ABI，失败返回带选择器的编码，钱包与开发框架再据此还原成人话。对照今天排铸造失败的常见顺序——先还原交易输入判断调了哪个函数，再看返回数据前 4 字节能否在 ABI 里匹配到已声明错误，最后才回落到重放估算——你会发现自己用的正是 ERC-838 当年勾画的流程。对读者的实际意义是：遇到 revert 时优先找支持错误解码的工具而不是只看钱包提示的失败二字，Gas 花了至少要把原因带走；而任何声称能替你判断该不该重试的第三方，都以只读诊断为宜，签名权仍留在自己手里。本文为机制说明，不构成任何投资建议。