ERC-7512 审计报告上链：你读的 PDF 绑的是哪份合约

“我们审过了”是加密项目最常见的四个字，但它绑定的到底是什么？审计报告通常是一份 PDF：正文里截图的合约地址可能来自测试网，提到的接口版本可能已经迭代，签名和哈希算法五花八门，合约方还能不能对得上号全靠人眼核对。ERC-7512（Onchain Representation for Audits）提出的思路是把审计报告压缩成一个结构化数据对象，让合约、脚本和索引器能直接解析出“谁审的、审的哪份部署、审到哪一步”，并用签名把这个对象锁死。按以太坊 ercs 仓库的记录，该提案状态为 Draft，创建于 2023 年 9 月 5 日。

AuditSummary：六个字段把模糊承诺变成硬数据

标准定义的核心结构是 AuditSummary。审计师部分（Auditor）包含名称、可查询更多信息的 URI，以及实际参与审计的作者名单。审计条目本身要求带签发时间 issuedAt，并明确 auditedContract 必须由两部分组成：被审合约所在链的链 ID（以 EIP-155 口径、用 bytes32 表示）与部署地址 deployment——这两个字段合在一起才锁定“一份具体部署”，换条链、换个代理地址都不在同一份报告的覆盖范围内。ercs 字段列出被审合约完整实现的 ERC 编号，标准特别强调列出的就必须是完整实现，允许为空，但不允许拿“部分支持”充数。auditHash 是原始报告的哈希，用来把链上对象和链下文件钉在一起，auditUri 则指向可获取原始报告的位置。

签名类型与验签：报告能不能被机器确认

审计机构侧最大的单点风险在密钥。标准的取舍写得直白：整套机制的前提是参与各方管好密钥，一旦审计师密钥失陷，被冒名签发的记录会把从未合规的合约伪装成已审计合规的样子；文本提到的一种补救是让审计机构之间建立关联，允许二级密钥在成员密钥出事时撤回其既有签名。对读者，这条信息落成一个具体动作：验签通过不等于高枕无忧，看到机构发布密钥事件公告时应把手头的报告重验一遍。ercs 字段的硬规则也值得较真——列出的标准必须完整实现，声称支持某个 ERC 却在回调或接口上偷工的合约，按规矩不该出现在那栏里，清单与字节码的出入本身就是一条现成的审计发现。

把视角切回普通用户，这套标准带来的最大改变是核对顺序可以机械化：以前读审计报告是先读结论再找地址截图，以后先看结构——目标链与部署地址是否正是要交互的合约，签名是否可解析回署名方，报告哈希是否与手里的文件一致——三步都过了，才值得花时间去读报告里的漏洞列表。任何机器核对都先于人类阅读，正是这类结构化表示的全部意义；反过来，一份只有 PDF、拒绝提供结构化表示的报告，在信息透明度上已经先输了一分。

值得一提的是签名类型里的 ERC1271 分支：它允许审计机构以多签合约或智能账户的名义签署报告，验证时按链 ID、地址与区块号上下文解析，这意味着署名主体本身可以是一套有阈值的治理结构而非单把密钥，机构密钥管理因此多了一层缓冲。

签署环节使用 EIP-712 结构化签名，AuditSummary 是主类型，附带域名信息区分签发环境。签名本身带类型标签，枚举列了 SECP256K1、BLS、ERC1271 和 SECP256R1 四种：前两种与以太坊常见密钥体系对应，ERC1271 允许合约账户（比如多签金库）作为署名主体，SECP256R1 对应硬件安全模块里常用的曲线。对读者的实际意义是一条核对顺序：先比对链 ID 和部署地址是否与你正要交互的合约一致，再验签名能否解析回署名审计机构的密钥，最后用 auditHash 去核对手里的报告原文。任何一环对不上，“有审计”三个字就不该被当作通过。本文为机制说明，不构成任何投资建议。