签字前先给你一句人话：ERC-3224 描述串接口与两个 JSON-RPC 方法

钱包弹窗里那串 0xa9059cbb… 长什么就是什么，中间的参数是什么地址、多少数量，全靠用户自己拼。常见场景里钱包只能给一笔“二进制黑盒签名”。2021 年 1 月 23 日创建的 ERC-3224 提供了一种补法：让合约自己交出一份带说明书的数据，状态为 Stagnant。动机部分说得坦率：除非是 ERC-20 转账这种被钱包特判过的常见操作，其余时候钱包等于请用户签一段看不懂的字节。

describer：一边写说明一边备数据

机制的核心是一个约定函数：Describe（占位名 eipXXXDescribe）收一段 describer 输入，同时返回两样东西——一段给人类看的描述字符串、一段真正要签的字节数据。两者由同一段合约代码同时生成，避免“说明与数据各改各的”。求值有严格的静默条件：这是在静态上下文里跑的，日志、存储写入等副作用即便存在也会被忽略；ADDRESS、CALLER、VALUE、GASPRICE 必须与被描述的那笔交易保持一致，区块相关指令按 latest 块就近取值，COINBASE 取零地址；签名消息场景下 VALUE 恒为零。函数一旦 revert，签名流程必须中止——说明书印不出来，单子就不签。

两个 JSON-RPC 方法

钱包侧新增两个入口：eth_signDescribedMessage(address, describer, describerInput) 给“消息”配描述后签名；eth_sendDescribedTransaction 则在发送交易前先取描述、展示、再上链。标准的兼容姿态很务实：如果钱包没有用户界面或不打算用，直接忽略描述字符串、按原数据执行即可。文档里的演示例子值得一提：给 ERC-20 的 transfer 与 approve 两种调用生成描述，同一族字节串，说明文字能明确报到目标地址与数量级。

防 honest 不防 liar

原文的安全模型只有一句话级别的坦率：它解决的是“诚实合约想让用户体验好一点”，不解决“恶意合约撒谎”。描述文本由 describer 合约生成，坏合约完全可以在描述里写“这是一笔空投领取”而数据是授权全部资产。标准给的缓解是审计路径：交易描述和合约代码可以一起被审计，评审者顺带检查描述是否如实。对用户的推论是：出现带描述的签名请求体验更好，但描述的存在本身不构成安全证据，核对的对象仍然是地址、授权范围与数额，描述只是帮你更快读到它们的把手。

值得记住的组合

静态求值的完整条件表与一个签名约束

把静态求值的条件补全，才发现标准抠得比想象中细。执行描述代码时，区块相关指令必须对齐 latest 块：BLOCKHASH、NUMBER、TIMESTAMP、DIFFICULTY 都要取自“最新区块”口径，COINBASE 固定为零地址——这些规定保证描述过程可重放，不同客户端算出的描述字符串应当一致。更要紧的是环境变量的镜像要求：ADDRESS、CALLER、VALUE、GASPRICE 必须与那笔正在被描述的真实交易完全相同，描述代码里任何按调用者分支或按金额分支的逻辑，算的都是真实场景下的回答。两类操作各有专门约束：签名消息场景 VALUE 恒为零——描述一段文字时不该掺钱；函数一旦 revert，签名流程必须中止——说明书印不出来就停笔，而不是默默降级成裸签。

钱包侧的两个 JSON-RPC 方法之外，标准还交代了实现分布策略：同样的能力会做进以太坊标准库，JSON-RPC 描述只是这些能力的规范化入口；若某个客户端没有界面或不打算展示描述，忽略描述串、直接按 described_data 执行即可，兼容性就此兜底。文档给的示例选得讨巧：对 transfer 和 approve 两个最常用的函数生成描述，说明文字能把隐藏的地址与数量级摆到台面上——而这两个函数正是钓鱼签名最常冒充的门面。读这份 Stagnant 提案的最终收获也在这：它证明了“让合约自己印说明书”在接口上完全可行，缺的从来不是技术，而是钱包与 dApp 愿不愿意为诚实合约的多那一次静态调用买单。

描述由代码生成而非文档手写，这是它区别于“项目方自己写的提示”的关键：说明和指令同源，才谈得上可审计。钱包是否实现这两个 JSON-RPC 方法取决于客户端，签名前你能不能看到人话，还取决于目标合约是否老实实现了接口。本文为机制说明，不构成任何投资建议。