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

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

你的答案会是什么？

那次（臭名昭著的）红色婚礼？2016年的上海DoS攻击？CryptoKitties的闹剧？还是那次“未宣布”的硬分叉？选择其中任何一个选项似乎都很合理——毕竟，这些事件都足够重要，值得社区广泛关注——但赢得奖金则需要选择一个更简单的选项，像导致DAO黑客攻击的漏洞一样简单。

想一想：一个关键的共识漏洞将区块链分为两部分，对于以太坊未来的威胁远不及影响到在网络上部署的成千上万的合约中一个合约的漏洞。当然，如果该合约恰好持有流通中1/3的所有ETH，规则可能就会有所不同——但你明白我的意思。

DAO攻击还强调了智能合约安全对以太坊未来作为全球经济活动协调平台的重要性。这反过来又促使以太坊社区中的一个多元化专业团队更关注在分布式（和潜在敌对）计算环境中运行的应用程序的安全问题，如以太坊虚拟机（有些甚至将DAO攻击归功于区块链安全行业的孕育）。

但依然存在需要解决的问题。

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

准备阶段：为什么审计（和审计信息）对区块链安全至关重要？

得益于以太坊安全社区各个个人和团队的努力，开发者用于构建安全dapp的安全工具数量近年来增加了——从测试框架到形式验证工具和经过战斗考验的库。然而，审计仍然在智能合约安全堆栈中占据了关键部分，原因有以下几点：

• 查找某些漏洞需要一个人（即审计员）能够理解另一个人（即开发人员）对特定代码片段的意图，比较合约的执行与原始意图（合约规范与运行时行为之间的任何差异都代表了潜在的漏洞）。
• 黑客并不是AI代理（目前还不是），因此审计员在作为安全审核员的角色中，可以对潜在攻击者可能采用的策略进行有根据的猜测，并提出开发人员可以实施的措施和减轻策略，以防止去中心化金融（DeFi）协议受到之前识别的攻击向量的影响。
• 审计员（与工具不同）在其中也有风险，并且（理想情况下）会与开发团队紧密合作，以确保智能合约满足安全的最低要求，并在项目的主网启动之前实施安全的最佳实践（没有审计员希望看到那些与项目发生黑客攻击相关的匿名者将他们的公司与项目联系在一起）。

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

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

前两个问题具有社会动态，使得这些问题较难解决，但第三个问题却（令人惊讶地）是可以处理的——特别是如果我们利用区块链来实现数据的不可篡改和透明性。这正是ERC-7512尝试通过提供验证智能合约审计信息的统一方法来实现的。

最后一点很重要：你总是可以通过检查审计员网站上的PDF报告来验证审计的详细信息，或者咨询其他链下来源以获取有关协议审计的任何信息（例如，Etherscan包含某些代币合约的审计信息）。然而，这种方法（手动（链下）审计验证）遇到几个问题：

1. 审计数据是中心化的：无论审计报告是上传到GitHub/GitLab仓库，还是存储在公司服务器上，都可能被删除或更改。它也可能被永久删除，无法供需要该信息的人使用，以便在与协议交互之前做出（知情）评估。

可以通过将审计信息的数据存储在第三方平台中来实现审计信息的去中心化——例如，CoinMarketCap、CoinGecko和Etherscan根据审计员提供的数据，展示其平台上某些代币合约的审计信息。但这样的方案仍然是 过于 中心化的：你需要信任平台去保存这些信息，并且通常只有合伙审计员的审计信息才会在上述网站上展示。

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

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

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

本节提供ERC-7512的技术细节的高层概述；请注意（a）该ERC处于草案阶段，因此细节可能会发生变化（我将鼓励通过ERC网站或以太坊魔法师论坛跟踪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-20和ERC-721，审核合约所实施的ERC的列表），auditHash（原始审计报告的哈希），以及auditUri（指向原始审计报告可以检索的位置的URI）。

Contract

ERC-7512风格的审计表示中的Contract数据类型包括chainID（基于EIP-155的32字节表示形式）和deployment地址（审计合约的字节码被部署的地址）。ERC-7512在审计信息中包括chainID，因为合约的行为在不同的（EVM）区块链上可能会有所不同——即使在两个实例中使用的是相同的代码。

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代币”以获取示例）。我之前已经描述过可组合性（包括以太坊代币能够无缝互操作的能力）是以太坊的杀手级特性之一，但这带来的风险是合约之间存在缺陷交互，可能导致安全漏洞（正如我们过去所看到的情况）。

替代方案是简单地阻止所有未通过尽职调查的代币交互（由协议内部团队进行的尽职调查）；然而，这只会引入中心化，并可能破坏依赖于代币在不同应用和基础设施之间自由互操作的假设。ERC-7512通过提供一种简单的方式来验证代币合约是否遵循ERC规范，消除了必须进行这样的权衡的需要，并充当桥接可集成到其安全基础设施中的可插拔模块。

人们可能还会看到ERC-7512对更广泛的应用类别也是有利的：

• 一个去中心化交易所（DEX）可能希望验证新的代币没有实现ERC-777风格的钩子（这在过去启用了重入攻击），以便在创建以该资产作为可交易对一半的流动性池之前进行确认。
• 像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方面表现出色——提供了关于采用ERC-7512以支持代理的一些见解，值得一读。

3. ERC-7512提议第三方验证者在验证审计报告的真实性之前，应注册与“受信任审计员”相关联的公钥。我已经解释了通过这种方式验证审计员身份为何重要，但在这里不再细述；对ERC-7512的讨论所引发的重要内容是“受信任”一词。ERC文档未提及审计公司如何获得“受信任审计员”分类的细节，但很容易想到，协议很可能将那些在行业中意图良好和声誉良好的审计公司视为“受信任”。

这一点非常不错——如果有的话，公开发布审计报告的吸引力在于，推动审计员提供高质量的安全审查，以避免如果经过审计的协议被黑，会损害他们的声誉。不过，问题在于，将“受信任审计员”状态限制于少数高调名称，可能会提升新进入者的门槛。

这种做法可能会引发一系列新问题，例如，由于新参与者的竞争，可能会减少或消除现有审计公司提高服务水平的动机。Gregory Makodzeba先前提到的文章提出了一种“民主”的机制，个人可以投票将审计公司加入受信任审计员列表，但这种情况是否可行仍然是一个未解之问。

4. ERC-7512当前版本未解决的最后一个问题——也许是最重要的——是如何处理在审计后影响智能合约安全性的问题。我不是在谈论新的零日漏洞（尽管这些也 应该 被考虑），而是指合约代码的变更，这会改变威胁模型并引入新的、未评估的攻击向量。除非修改后的代码基再由同一 审计公司重新审查（并且没有出现重大漏洞），否则让审计员继续为相关合约的安全过渡证明是有失公允的。

这就需要某种机制，使审计员能够根据新信息潜在地使审计无效，例如（未经审计）合约升级（例如，改变代理的实现），系统关键部分的变更（例如，新行政控制）或任何其他可能使审计员在初次审计期间所做的安全假设失效的问题。这样，审计员就可以在需求问责和保护商业声誉之间达到平衡，尤其是在安全审计行业，声誉（几乎）是王道。

ERC-7512的最终思考

Web3安全是一个长期的游戏；自DAO黑客事件以来，确实有了改善，但新的威胁不断出现（你可以查看Blockthreat和Rekt获取定期评论），迫使审计员、项目、平台和其他关键参与者演变出新的防御策略。这也是一场 重要 的游戏：缺乏信任无疑是阻碍加密普遍采用的最大因素之一；为了WEB3能够达到规模，用户需要对自己与之交互的应用程序的安全性充满信心，而项目也需要评估外部协议的安全担保，以避免可组合性的负面影响。

ERC-7512使我们更接近于在链上应用程序中建立信任，并可能激励更多努力去标准化安全审查过程的其他方面。例如，鉴于项目现在越来越多地采用“深度防御”方法——漏洞赏金、形式验证、审计竞赛、事件监控等等——一种在同一位置汇聚（可验证）项目各种安全措施信息的系统（与这些信息分散在多个网站和仪表板上相对比）将对投资者、用户以及为DeFi协议进行尽职调查的业务开发（BD）团队有很大的帮助。（DeFi Safety曾经拥有一个类似的服务，但最近转向了营收模型）。

如前所述，ERC-7512仍处于草案阶段，可能在提议采纳为以太坊标准的最终版本之前会有更多变化；与此同时，你可以在以太坊魔法师和ERC-7512 Telegram群组上追踪该提案的讨论。最后，不要忘记订阅以太坊2077获取更多EIP指南；如果你觉得这篇文章信息丰富，请与你认为会欣赏此内容的人分享。

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