ERC-7512：通过链上审计增强智能合约安全性

想象一下这个场景：你正在玩 谁想成为百万富翁？ ，而一个百万美元的问题出现了：“在以太坊历史上，哪个事件代表了最大的生存威胁？”

你的答案会是什么？

那是（不）著名的红色婚礼吗？2016年上海的DoS攻击？CryptoKitties事件？还是“未公布”的硬分叉？选择这些选项似乎都合理——毕竟，这些事件足够重要，值得社区广泛关注——但赢得奖金需要选择一个更简单的选项。就像导致DAO黑客攻击的bug一样简单。

想一想这一点：一个关键一致性的bug导致区块链分裂成两半，远没有威胁以太坊的未来那么多，反而是影响了网络上数千个合约中的一个合约的漏洞。当然，如果那个合约持有流通中1/3的ETH，规则可能会有所不同——但你明白我的意思。

DAO黑客攻击还强调了智能合约安全对以太坊未来作为协调全球经济活动的平台的重要性。这反过来又激励了以太坊社区内的多元化专业人员更关注确保在分布式（并可能对立的）计算环境中运行的应用程序安全的问题（有些人甚至将DAO黑客攻击归功于区块链安全行业的诞生）。

但是，仍然有许多问题需要解决。

例如，由安全专业人士对智能合约代码进行的独立第三方审查，也就是“审计”，已变得非常普遍；然而，当前对审计的验证方法面临各种问题——限制了审计作为评估合约安全性的工具的有效性。ERC-7512是一个新的以太坊改进提案（EIP），旨在通过创建一种标准化的方法在链上发布审计报告来解决这个特定问题，也是本文的重点。

设置舞台：为什么审计（和审计信息）对区块链安全至关重要？

由于以太坊安全社区各种个人和团队的努力，近年来可供开发者用于构建安全dapp的安全工具数量已经有所增加——从测试框架到形式化验证工具以及经过验证的库。但出于特定原因，审计仍然代表了智能合约安全堆栈中的一个关键部分：

• 一些bug的发现需要理解其他人（即开发者）对特定代码的意图的人工（即审计员）对合约执行与原始意图进行比较（合约的规范和运行时行为之间的任何差异都会成为潜在漏洞）。
• 黑客还不是人工智能代理（还没有），因此审计员可以在他们的安全审查角色中，进行有关潜在攻击者可能采用的策略的合理猜测，并提出开发者可以实施的措施和缓解方案，以保护DeFi协议免受先前识别的攻击向量。
• 审计员（与工具不同）有切身利益，理想情况下会与开发团队紧密合作，以确保智能合约满足安全的最低要求，并在项目主网上线之前实施安全的最佳实践（没有审计员希望看到被“发现”的匿名者将他们的公司与遭受黑客攻击的项目联系在一起）。

这就是为什么——与2016年前的以太坊相比——委托审计被视为赢得用户信任的标准要求；这也是为什么区块链安全如今已成为一个利润丰厚的行业的原因。尽管取得了这样的进展，但在以下几个领域仍然存在问题：

• 评估智能合约审计的质量（例如，“审计应检查智能合约哪些内容？”）；
• 标准化与第三方沟通审计相关细节的方法（例如，“什么算作严重漏洞？”）；
• 验证审计员与客户的参与信息（例如，“谁审计了这个合约，他们何时审计的？”）等。

前两个问题具有社会动态性，使其难以解决，但第三个问题是（惊人地）可解决的——特别是如果我们利用区块链来确保数据的不可变性和透明度。这正是ERC-7512所试图做的，提供一种统一的方法来验证有关智能合约审计的信息在区块链上。

最后一点至关重要：你总是可以通过检查审计员网站上的PDF报告或咨询其他链下资源来验证审计的详细信息（例如，Etherscan包含与代币合约相关的审计信息）。但是，这种方法（手动（链下）验证审计）面临多个问题：

1. 审计数据是中心化的：无论审计报告是上传到GitHub/GitLab仓库，还是存储在公司服务器上，都可能被删除或更改。它也可能永久性地被擦除并对需要这些信息以进行（信息）评估协议安全性的个人而言变得无法获取。

可以通过与第三方平台一起存储审计信息来实现审计信息的去中心化——例如，CoinMarketCap、CoinGecko和Etherscan基于审计员的数据，对那些平台上列出的代币合约显示审计信息。但是这样的计划仍然过于集中：你需要信任平台能保留这些信息，而通常，只有合作审计员的审计才会显示在上述网站上。

2. 手动验证审计信息繁琐：在查阅一个项目的文档并找到审计报告的链接后——如果这没有导致404页面——你仍然需要验证被审计的合约与在区块链上部署的合约是否相同。虽然有努力使源代码验证变得更容易，但这样做仍然需要相当可观的工作量，使得用户和协议团队都难以进行DYOR（做你自己的研究）。

将审计报告上链并不会完全解决DeFi的安全问题（这是一个微妙而关键的考虑），但它可以解决上述问题——并在此过程中增加透明度，增强用户对各种智能合约安全性的信心。在接下来的部分中，我将深入讨论ERC-7512的技术细节，然后再谈谈该提案对以太坊生态系统的重要性。

ERC-7512概述：链上审计表示

本节提供ERC-7512技术细节的高层概述；请注意：（a）该ERC处于草案阶段，因此细节可能会发生变化（我将鼓励在EIP网站或以太坊魔法师论坛上跟踪该EIP的变化）；（b）该概述的范围较简单——对于更技术倾向的读者，ERC文档提供更全面的ERC-7512技术规范。

快速概述：ERC-7512是创建链上可验证的审计报告的标准，外部合约可以解析以提取有关合约审计过程的特定信息，例如参与审计的审计员和支持的ERC标准列表。ERC-7512并未声明用于提取审计数据的特定接口或函数，而是允许开发者实现定制的方案以从链上审计中检索信息。

以下是ERC-7512定义的链上审计表示结构的高层描述：

Auditor

Auditor数据类型提供有关合约审计背后实体的信息，包括以下值：name（审计员名称）、uri（URI（统一资源标识符）在该方案中提供有关审计公司的更多信息；URI可以包含指向审计员网站的可人读链接，例如），以及authors（贡献于合约审计的个人列表——如果有多个人审计了合约）。

AuditSummary

AuditSummary数据类型总结了审计的关键信息，包括以下值：auditor（有关审计员的信息）、auditedContract（审计中提到的合约实例）、issuedAt（审计发布日期，由auditHash标识）、ercs（由被审计合约实施的ERC列表，例如ERC-20和ERC-721）、auditHash（原始审计报告的hash）和auditUri（指向可检索原始审计报告的位置的URI）。

Contract

ERC-7512风格审计表示中的Contract数据类型包括chainID（根据EIP-155的32字节表示的chainID）和deployment地址（被审计合约字节码的部署地址）。由于合约的行为可以在不同的（EVM）区块链上有所不同——即使在这两种情况使用相同的代码，ERC-7512将chainID包含在审计信息中。

ERC-7512可以通过与EIP-712集成以结构化方式和有意义的方式表示上述所有信息（该标准提供了一种签名结构化数据（如枚举和结构体）及验证签名者身份的方法）；具体而言，它允许审计员（由他们的公钥表示）签署包含审计细节的摘要，通过链下方法进行签名，并使第三方（例如用户或协议）能够在EVM中验证链上签名的真实性。

然而，EIP-712仅支持验证来自EOA（外部拥有账户）的签名。为了考虑使用智能合约钱包的审计公司——例如因为它支持多重签名审批——ERC-7512提供了附加支持，将EIP-1271签名附加到审计摘要中。

为什么选择ERC-7512？链上验证智能合约审计的案例

ERC-7512设计的核心思想很简单（在你想“为什么之前没人这样做？”之前，其他人也试图实施类似方案，但成功较少；希望这次有所不同）：一旦审计员向客户项目提供签名的审计，感兴趣的各方就可以通过验证审计员的签名在链上自动验证合约的审计状态。

与现状不同的是，审计报告位于链下，代码位于链上，ERC-7512使得审计验证更接近区块链。感谢公钥基础设施的魔力，可以使验证抵御一些类型的欺诈，例如冒名顶替和审计报告伪造（这假设审计员具有适当的密钥管理实践，以防止未授权签署链上审计）。

那么，这在实践中是如何工作的呢？

ERC-7512的作者（幸运的是）提供了一个示例，来演示该标准的一个应用：在将代币与桥集成之前验证ERC兼容性。下面是一个表示“用户”（负责提供签名审计以进行验证）、“桥运营商”（负责验证代币合约审计）和“验证器”（一个智能合约，用于验证从签名审计的哈希中提取的签名，并检查审计报告中的特定安全相关信息）之间交互的图示：

• 图示中的用户是首次为代币提供桥接，并将审计报告传递给桥运营商。假设桥运营商已经在验证器合约中注册了与“可信”审计员相关的公钥列表。验证器是一个检查新代币是否符合桥接资格的合约（根据桥运营商定义的规则）。
• 验证器合约检查（a）审计是否由可信审计员签名，以及（b）被审计合约是否实现了所需的ERC（在这个示例中是ERC-1115）；这可以通过检查审计摘要摘要的ercs部分来完成。如果审计检查通过，桥运营商现在可以继续（手动）提供桥接新代币的许可。

这是一个简单的示例，但它展示了ERC-7512对处于以太坊应用层协议的价值——特别是如果考虑到有多少利用出了问题后的漏洞，都发生在与那些与表现出意外行为的代币合约集成的桥接上（请参见 “ 奇怪的ERC-20代币”作为示例）。我之前提到过组合性（why composability matters for web3）——包括在以太坊上代币无缝互操作的能力——是以太坊的 killer feature之一，但这伴随的就是合约之间的交互缺陷可能会导致安全漏洞（正如我们过去看到的那样的例子）。

替代方案是简单地阻止所有未通过尽职调查（由协议内部团队进行）的代币的交互；然而，这只会引入中心化，并可能破坏依赖于代币将在没有约束的情况下跨应用和基础设施保持互操作的假设的功能。ERC-7512通过提供验证代币合约是否遵循ERC规范的简便方法，而不需要做出这样的权衡，从而消除了这一需求。

人们也许能看到ERC-7512对更广泛的应用类别是如何有用的：

• 一个去中心化交易所（DEX）可能希望验证新代币不实现具有ERC-777样式的hooks（这曾经导致重入攻击），然后再与该资产创建交易对的流动性池。
• 像MetaMask和Coinbase Wallet这样的钱包应用可能会在允许涉及该代币的兑换之前验证代币的审计；一个扩展将是在与代币交互时直接向用户显示“已审计”或“未审计”标签——有效降低进行尽职调查的难度（顺便提一下，TrustBlock提供类似的服务，但疏忽的是，它作为一种专有产品运营，钱包开发人员将不得不集成该平台的API，以使用TrustBlock存储的审计数据）。

ERC-7512的替代方案

一些人（可见这里 、这里 和这里）提议建立一个审计员的链上注册表，作为ERC-7512的替代方案；这里（注意我在简化这个概念）：

• 部署一个注册表合约，审计员可以在其中注册公钥（用于第三方验证目的）——或遵循由注册表所有者决定的某种录取流程。
• 审计员可以生成签名的不可替代代币（NFT），其中包含有关特定合约的审计信息（例如，审计员发现的漏洞数量（按严重程度排名）和链接到审计报告），并将其包含在NFT元数据中。
• 任何人都可以通过从签名的NFT恢复公钥并与存储在公共注册表合约中的公钥列表交叉检查来验证审计NFT。理想情况下，NFT将是一个灵魂绑定代币（SBT），以防止转让（这将使验证来源更困难）。

链上注册表将使协议不再承担根据ERC-7512的规范注册可信审计员密钥的负担；然而，这在使用便利性与更多复杂性之间进行了权衡——而且还存在一个或多个注册表所有者试图控制链上审计信息表示的风险（这可能导致不同的、冲突的审计表示，从而给开发人员带来更多麻烦）。另一个风险是中心化：特定审计能否在链上验证取决于审计员进入注册表的机会。

相比之下，ERC-7512通过标准化链上审计表示的结构，确保了整个生态系统中审计验证的一致性（这也有助于去中心化，因为它允许任何审计员创建可验证的审计，无需依赖于特定的注册表）。ERC-7512的简易性也使其更灵活，适应不同的用途——例如，已签名的审计摘要可以用来生成灵魂绑定代币（SBT），

其来源可根据存储在另一个注册表中的公钥进行验证。此外，注册表合约还可以在将审计公司添加到注册表之前，需要ERC-7512风格的链上审计表示。

分析ERC-7512的局限性

像所有提案一样，ERC-7512并非没有缺点——其中一些相当明显且简单明了，而另一些则更为微妙。以下是我提供的简要总结，但你可以查看这篇文章，以及以太坊魔法师讨论以获取更多详细信息：

1. ERC-7512提案文档添加了一个免责声明，即链上审计不应被视为对合约安全性的证明，而只是表示合约是否已被审计的方法。这是相当明智的；但如果我们学到了什么，那就是项目将用一切作为营销的杠杆，包括拥有链上审计（即使“审计”并不等于“没有漏洞”）。

ERC-7512的设计（出于对简化的需求）也使问题变得复杂：审计员发现的安全问题的信息（即发现）未在审计摘要中提及；若要获取这些信息，用户需要找到审计报告本身——重新引入依赖集中（链下）基础设施来存储审计信息的问题。

尽管初衷令人赞赏，但是遗漏诸如漏洞发现等关键信息可能会降低所提议在链上表示审计的方案的价值。关于ERC-7512讨论的一条评论（来自Dexaran）为此提供了背景：

“当前ERC没有提及审计的发现……这老实说是最关键的部分。一个合约可能有多个审计报告，如果至少有一份报告指出该合约存在问题——这个问题比所有其他无问题的报告要重要得多。如果你有三个审计员审核了一个合约，其中两个没有发现问题，而第三个发现了一个严重的漏洞——指出“该合约可能存在严重漏洞”比去假设“如果至少有一份审计报告没有表明存在问题，则该合约很可能是安全的”要更有逻辑。我认为一个不允许发现说明和多名审计员独立提交审计的系统——是行不通的，甚至更糟糕的是，它会欺骗用户，让他们认为某些合约是安全的，然而实际上它们存在问题。”——u/Dexeran_

2. ERC-7512的初始版本试图通过在AuditSummary数据类型中包括一个指向被审计合约的部署地址的deployment值，来创建审计与审计员覆盖的智能合约之间的可见连接。这样，协议就不必通过从PDF中复制粘贴合约地址的迂回过程，并通过像Etherscan这样的区块链浏览器搜索相关合约地址。

然而，“代理合约”的流行对ERC-7512验证智能合约审计的方法提出了一点小挑战。对于初学者而言，代理合约将一个或多个功能的执行委托给另一个合约，而不是执行其逻辑（使用Solidity的DELEGATECALL功能）；代理合约的主要用例是使合约能够升级，而无需迁移旧状态或部署新合约并初始化新状态。

秘诀是（a）将dapp的状态和逻辑分离到不同的合约中：一个保存状态的代理合约（例如用户余额）和存储dapp逻辑的实现合约；以及（b）在代理中存储指向实现的地址的指针（这是代理在执行过程中转发函数调用的方式）。如果开发者希望升级dapp并修改其逻辑，只需将代理指向新的实现合约。

尽管使用过的代理模式（一个代理合约和一个实现合约在任何时候）变得更简单，但更新的模式——尤其是钻石模式——允许合约指向任意数量的实现合约。以下是代理模式中合约之间交互的便利图示（你可以阅读该文章，以获得对代理升级的更全面介绍）：

如果我没有让你退去开发者术语，或许你已经看到了问题所在：如果被审计的合约是代理，ERC-7512风格的链上审计并不会保证外部验证者合约的安全，因为在用户调用代理功能时执行的实际代码——并且是任何严重漏洞的来源——存储在一个单独的地址。为了使ERC-7512在这种情况下有用，审计摘要中必须有一个额外的数据块，以显示代理及其在运行时使用的任何实现已通过审计。

幸运的是，ERC-7512的作者们已经开始为代理添加支持，如GitHub上编辑ERC提案的最新拉取请求所示。尽管如此，考虑到代理的复杂性，可能还需要解决更多问题，以使验证合约代理的审计信息更容易且更安全。由Gregory Makodzeba撰写的这篇文章出色地探索了从审计员的角度来看ERC-7512的挑战，值得阅读。

3. ERC-7512提议第三方验证者应在验证审计报告真实性之前，注册与“可信审计员”相关的公钥。我解释了以这种方式验证审计员身份的价值，不在此细节；对ERC-7512局限性讨论的重要部分是“可信”部分。ERC文档中未提及审计公司将如何获得“可信审计员”分类的详细信息，但很容易想到协议可能会考虑审计行业中有良好表现和良好声誉的审计公司。

这一切都是好的——如果说有什么吸引力，发布审计报告公共目的在于激励审计员提供高质量的安全审查，以避免持有声誉的失去 。然而，问题在于，将“可信审计员”状态限制在少数知名人士身上可能会提高新进入者的门槛。

这种方法可能会引入新问题，例如由于来自新玩家的竞争而减少或消除对已有审计公司改善服务交付的激励。Gregory Makodzeba之前链接的那篇文章提出了一种“民主”机制，个人可以投票将审计公司添加到可信审计员注册表中，但这是否切实可行还是一个悬而未决的问题。

4. ERC-7512当前形式中未解决的最后一个——也是可能最重要的——关注点是如何处理审计后影响智能合约安全性的问题。如果我这里不是在谈论新的零日漏洞（尽管这些也应被考虑），而是类似于对合约代码的改动，改变了威胁模型并引入了新的、未评估的攻击向量。除非更改的代码库必须由同一家审计原始代码的公司进行额外审查（且没有出现重大漏洞），否则继续让审计员证明所涉及合约的安全性可能是不公平的。

这需要某种机制，允许审计员基于新信息潜在地使审计失效，例如（未审计的）合约升级（例如更改代理的实现）、系统的关键部分变更（例如新的管理控制）或任何其他可能使审计员在初步审计期间产生的安全假设失效的问题。通过这种做法，审计员可以在 accountability 的需要与保护商业声誉之间取得平衡，尤其是在安全审计行业中，声誉几乎就是一切。

对ERC-7512的最终思考

Web3安全是一场持久战；自DAO黑客攻击以来，情况确实有所改善，但新的威胁不断出现（你可以定期查看Blockthreat和Rekt），迫使审计员、项目、平台和其他关键参与者进化出新的防御策略。它也是一个重要的游戏：缺乏信任可以说是阻碍加密货币广泛采用的最大因素之一；如果Web3要扩大规模，用户需要对他们所互动的应用程序的安全性充满信心，项目需要评估外部协议的安全保障，以避免组合性的负面影响。

ERC-7512使我们更进一步，建立了对链上应用程序的信任，并可能激励更多努力来标准化安全审查过程的其他方面。例如，考虑到项目如今越来越多地采用“深度防御”方法——漏洞奖励、形式化验证、审计竞赛、事件监控等——一个在同一位置聚合（可验证的）项目信息的系统，各种安全措施的任意同一位置（而不是在多个网站和仪表盘上信息分散）将对进行尽职调查的投资者、用户、商业开发（BD）团队有很大的帮助。（DeFi Safety曾经提供类似服务，但最近转向了营收模式。）

如前所述，ERC-7512仍处于草案阶段，可能会在提案采用最终版本之前经历更多变更；与此同时，你可以跟进有关该提案的讨论，在以太坊魔法师论坛和ERC-7512 Telegram小组。最后，别忘了订阅以太坊2077以获取更多EIP指南；如果你觉得这篇文章内容丰富，不妨分享给你认为会欣赏此内容的人。

• 原文链接： research.2077.xyz/erc-75...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～