ERC-4430 交易说明书：合约自己写一份人类可读的签名提示

把 NFT 挂去市场，钱包弹出一串 0x... 让你确认；想弄清这笔调用动了哪些合约、转走了什么，得懂 ABI 编码再逐段拆字节。2021 年 11 月 7 日起草的 ERC-4430 想终结这种盲签，思路一句话：与其让钱包猜字节码的意思，不如让被调用的合约自己提供一段人类可读的说明。提案停在 Stagnant，但它指出的问题——交易不可读——至今仍是钓鱼得手的头号帮凶。

一对同源的输出

机制是一个命名约定加一次静态调用。合约暴露形如 eipXXXDescribe(bytes inputs, bytes32 reserved) 的函数，输入你要执行的操作数据，返回两样东西：一段说明文字和与之匹配的执行字节码。钱包在请你确认之前先静态跑一次这个函数，把人话显示给你，把字节码填进真正要广播的交易。这里的 XXX 是占位，一个合约可以为每种操作各配一个 Describe 函数，函数名与它描述的实际入口一一对应。规则相当苛刻：函数必须在静态环境执行，任何写存储、发日志之类的副作用都会被忽略；执行时 ADDRESS、CALLER、VALUE、GASPRICE 必须与即将发生的那笔交易一致，区块相关字段按最新块处理，COINBASE 用零地址；函数一旦回滚，签名流程必须中止。这套苛刻条件的目的只有一个——让说明书与即将执行的字节码来自同一次求值，不给两者各说各话留缝隙。

说明书为什么比直接解析交易数据可靠？原文给了一个 ENS 的例子：commit 提交上链的是哈希，名字被打码后藏进 commitment，交易数据本身已经读不出任何有意义的内容；而从原始的昵称、地址、密钥出发间接描述，既能拼出准确的人类语句，又能同步算出正确的提交数据。关键性质在于文字与字节出自同一次函数求值，只要合约是诚实的，说明书就不可能与实际执行脱节。

诚实合约的专利

提案作者对局限毫不含糊：这套办法只服务想说清楚的好合约，对存心说谎的恶意合约毫无办法——描述函数毕竟是合约自己写的代码，钓鱼合约完全可以生成一段甜美假话配一段毒字节码。它也无意取代审计：说明书和合约代码应当被同一批人一起审，让代码审查时顺手核对描述准确性，是提案设想的工作流。兼容性是另一条隐线：没有部署 Describe 函数的海量存量合约不受影响，钱包遇到不支持的合约只能退回原样显示十六进制，于是这个标准的价值完全取决于采用率，而采用它的动力来自用户体验竞争而非任何协议层强制——这正是它停在 Stagnant 最现实的解释。

站在 2026 年回头看，这条路线在生态里找到了别的外衣：交易模拟类服务用静态调用在钱包里回放余额变化，本质上做的是同族的事——先算一遍、给人看、再执行。两者的信任配方却不同：模拟器的结论来自重放链上状态，合约说谎不影响余额预览的真实性；ERC-4430 把声明权直接交给合约本身，胜在说明可以精确到意图层面，败在只对诚实者有效。对普通用户的启发也因此明确：无论确认界面显示的是代码生成的说明书、模拟器的余额预览，还是项目方的文案，判断标准只有一条——这个说明是怎么生成的，它与它描述的那段字节码有没有同源关系。文字越让人安心，越要问这一问。本文为机制说明，不构成任何投资建议。