用自动化工具替你做一件事，中间要经过一层又一层的程序，每一层都有可能看见甚至改动你要签的数据。NFT 场景里这种链路越来越常见：一个 AI 代理帮你比价、拼参数，再把铸造或购买的调用转交给钱包。ERC-8410 就是针对这条链路提出的提案，2026 年 9 月在以太坊改进提案官网登记，状态是 Draft，也就是尚未定稿的规则草案，接口在定稿前仍可能调整。
要理解它想修什么，先看没有它时的一天是怎么过的。一个代理型工具通常分两步干活：先调用一个准备工具生成完整的调用数据，再把这串数据原样塞进执行工具的参数里，由执行工具转发给钱包。问题在于，这串调用数据全程以明文躺在代理的上下文和工具参数里。代理记录日志时会留下它，模型被诱导回显时会吐出它，上游工具被攻破时能篡改它。对普通收藏者来说，最直观的隐患是：你以为自己只签了一次 Mint 页面的铸造调用，转交途中参数里的收款合约、Token ID 范围或支付上限却可能被人悄悄改写。
ERC-8410 给出的修法是把数据本身从代理眼前挪走。提案定义了一种叫工件引用的东西：准备工具把执行计划存放到某个位置，交给代理的只有一张引用条，上面写三样东西——计划存放的位置、计划的字节长度、计划内容的完整性摘要。代理的职责退化成了快递单搬运工：它把引用转交给钱包，但看不见包裹里是什么。钱包拿到引用后自己去取回原始字节，核对长度与摘要是否对得上，再基于核验过的内容独立决定是否授权签名或执行。
这套设计里有三个值得展开的细节。第一，完整性摘要是防篡改的锚点：只要取回的字节和摘要算出来的结果不一致，钱包就应该拒绝，篡改在机制层面失去意义，而不是靠平台自觉。第二，提案把同一套引用格式也扩展到 EIP-712 签名请求——你熟悉的 NFT 挂单签名弹窗里那一屏结构化数据，同样可以用引用方式传递，让代理经手的只是一张指路条。第三，钱包对取回的字节要检查来源，也就是说它不是谁递来引用就照单全收，引用本身也要带可信出处，防止有人伪造一个指向恶意内容的引用骗钱包去取。
放在 NFT 与铭文的日常场景里看，这个提案瞄准的是三类动作：一键批量铸造、条件复杂的白名单认领、以及需要同时安排多条链上调用的组合操作。这些恰恰是目前 AI 代理化包装最热情、也最容易在参数里夹带私货的地方。提案文本也明确它不依赖任何特定的代理框架或工具协议，换句话说它是给整个行业立规矩，而不是给某一家产品做适配。
作为普通用户，你现在能做什么？答案仍然是先核对再签名，与有没有这个提案无关。在 ERC-8410 这类标准普及之前，任何声称代你编排调用的工具都应当这样对待：把它输出的调用数据拿到区块浏览器或独立解码器里逐字读一遍，确认目标合约地址、调用的函数名、支付上限三个字段与页面描述一致，再决定签名。引用式的取回验证普及之后，这道人工核对理论上会由钱包自动完成，但在标准落地前，人肉核验仍是唯一可执行的防线。
从机制演进的视角看，ERC-8410 延续的是近年钱包安全的一条主线：把信任从传话的人身上，挪到可验证的数据本身上。EIP-712 让签名内容变得可读，各类授权撤销接口让长期授权可以被收回，这份提案则试图让中间人连读都不用读。它的代价也不小：钱包需要多一套取回、校验、来源审计的逻辑，计划存到哪里、由谁长期保管，都是草案阶段还要继续讨论的问题。需要强调的是，草案状态的提案不构成任何已生效规则，链上资产与授权的安全判断，请以定稿文本与所使用钱包的官方文档为准。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。