钱包让你签的从来不只是数据，还有一段排版。ERC-7730 给可读签名定了 JSON 描述文件的规矩：钱包取来模板，把交易数据填成人话再给用户过目。模板本身由此成了新攻击面——编号 ERC-8176 的草案在 2026 年 2 月 26 日递交，作者 Bartosz Rozwarski，它要给这份模板加上公证：用 Ethereum Attestation Service 声明谁看过哪一版内容、签名担保、可以撤销。
描述文件的三种被掉包
动机段列了三种失败模式：注册表或仓库被投毒，贡献者提交一个故意藏字段、错标签的模板；传输中间人把 API 返回的描述文件半路换掉；供应链镜像、CDN 缓存或内容网关塞过来一份伪造版本。ERC-7730 自带的上下文绑定只能保证模板对准了合约地址与链，管不了显示逻辑是否被可信方审查过；git 提交签名能证明作者身份，可文件一旦被抽出来走接口分发，签名就随包装一起被扔掉了。声明式公证填的是内容被谁看过这个空档，并且设计上必须能脱离仓库独立流转——这正是 git 签名做不到的。
一条 schema 与一套哈希纪律
规范锚定一条登记在以太坊主网的声明 schema，载荷只有一个字段：bytes32 descriptorHash。schema UID 与声明合约地址都白纸黑字写进文本；resolver 字段是零地址，意味着任何人都能发声明——信任过滤被整体推到钱包层：钱包自己决定采信哪些公证人，规范不排名。哈希的计算纪律是整个 ERC 的脊柱：先把描述文件里所有 includes 引用按 7730 的合并规则递归展开，再按 RFC 8785 的 JSON 规范化方案序列化成唯一字节串，最后取 keccak256——文本特意用大写字母强调是以太坊生态一直在用的那个 keccak256，不是 NIST 的 SHA3-256。被引用文件不可得时哈希算不出来，相关声明的核验随之悬置，这些边角都有条文兜底；改动被引用文件会连坐地作废旧声明，属于设计意图。
链上声明与链下声明共用一把尺
声明有两种形态：写进声明合约的链上记录，或一份随描述文件分发的 EIP-712 签名 JSON。验证走声明服务的标准流程，外加一条本 ERC 的硬要求：声明里的 descriptorHash 必须与手头这份描述文件的实际哈希逐字节对得上。撤销用声明服务原生原语，schema 建为可撤销，公证人翻脸有路可退。文本还顺手把依赖的合约接口与数据结构整个列出——声明服务本身并不是一份 ERC 标准，作者选择把主网合约的行为当作规范性引用，实现者不必再翻别的文档。
快速问答
问：公证人无许可发声明，怎么防人海战术？ 答：规范明说零地址 resolver 即无许可，信任模型留给钱包——只采信白名单公证人即可，人海不影响判定。
问：改一个空格会影响 descriptorHash 吗？ 答：JCS 规范化正是为这类漂移设计的，先归一字节再哈希，格式噪声被抹平。
问：普通用户会感知到它吗？ 答：设计上不会——它是钱包与公证人之间的机器层，用户看到的仍是 7730 渲染出来的文案。
一条判断线
评估任何给元数据做签名层的方案，照三问拆：绑定什么——内容哈希还是指针；谁可签发——许可与成本；验证者需要额外拿什么。ERC-8176 的三答依次是整文件展开后的内容哈希、无许可声明、一条 schema UID 加声明本身。绑定内容而非指针，意味着上游悄悄换文件骗不过哈希。
常见误区
一是把它读成钱包厂商的资质认证，文本里没有任何审核流程，只有某方审过这一版的自我声明；二是忘了 includes 展开计入哈希——被引用模块被换，声明自动作废，这是特性不是漏洞；三是以为声明一锤定音，可撤销 schema 意味着信任是随时间流动的活数据，验证方要回看撤销状态。
风险提示：本文解释草案阶段的签名标准，不构成投资建议；接口与地址细节以 EIPs 仓库当期原文为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。