对ERC-7512的深入分析：安全审查的链上表现

ERC-7512

对 ERC-7512 的深入分析：安全审查的链上表示

反思

本文代表了我们与 Octane Security（ Nathan Ostrowski）、Rektoff （ hyperstructured.greg、Yehor）及 Trustblock（ Timur、Sacha）团队合作收集的数据和见解。我们试图分析最近发布的 EIP7512 架构，并对提案及其普遍思想进行一些思考。然而，我们很高兴看到一些团队朝着这个重要的行业方向努力，推动安全审查的标准化，并准备为尽快实现激励计划提供帮助。对协议有利，对用户有利，对黑客不利。

以下是信息的导航结构：

• 引言
• 我们为什么需要这个？ - 三个基本问题。
• 标准化
• 用户与协议的不信任关系。
• 数据碎片化
• 主要考虑事项
• 附加（代理）
• 代理/工厂中的复杂性关键要素是什么？
• 直接处理代理的替代方法
• deploymentCode 和 runtimeCode 的区别是什么，为什么这很重要？
• 缺乏构造函数参数会给我们带来什么麻烦？
• 编码构造函数参数的方法
• 展望未来
• 参考文献

引言

实施“链上审计”的想法在封闭聊天和 Discord 服务器中已酝酿了几年。有无数的想法被分享，只有少数例外仍然存在或以 EIP 的形式提前执行。这个复杂的挑战打破了许多人的思维，同时也激发了他们的愿望和灵感。为了加速进展，我们决定合作并增强新兴的与安全相关的提案，没有任何争斗或竞争，而是通过互动支持以促进所有专注于以太坊领域的工程师。

视角应当颠倒。旅程应从用户与智能合约的互动开始。

然而，一些公司服务器上隐藏的关键安全信息，对于任何想要验证项目合法性的人来说，都成为了虚假信息的丛林。

• Daniel（twitter.com/daniel_de_witte），WorkX CTO。

我们为什么需要这个？——三个基本问题。

标准化

在网络安全方面，标准至关重要。如今，没有呈现 web3 协议安全审查的基本方法，且每个研究人员在提交报告时和提交后都说着自己的语言。这无论如何都令人困惑和混乱。EIP-7512 希望通过创建一个通用的链上审计框架来清理这一点。这是为了让涉及过程的每一方更加轻松。

增加用户与协议互动的信任

审计报告不仅仅是为协议开发人员创建的，也是为了其社区。正如你所知，建立一个可信和忠诚的社区是一个大问题，且是有原因的。

Jack Sanford，Sherlock 的联合创始人，强调了 DeFi 领域中的一个关键问题，集中在一个涉及 FEGtoken 的漏洞上。根据他的主题，FEG鼓励用户与另一个未审计的合约进行互动，而不是与他们声称已经审计的那个合约进行互动。这种欺骗导致了约 200 万美元的损失。他指出，FEG 和 DeFiLlama 网站给人们留下了协议经过审查的印象，这具有误导性。

借助 EIP-7512，审计细节成为智能合约本身的核心部分，不留任何此类欺骗行为的余地。这是一种确保你所看到的确实是你所得到的手段。链上审计的概念旨在通过将安全审查验证转移到区块链上来巩固这种信任。不再仅仅相信某人的话或一份华丽的 PDF。

数据碎片化问题

这引出了另一个问题——目前，找到安全审查数据就像是在进行找宝藏的游戏。你可能会在项目的网站、文档、某些 GitHub 上找到这些安全报告，甚至可能在推文中公布审计结果。数据支离破碎，杂乱无章，老实说，拼凑这些信息十分麻烦。7512-man 直面这一问题，创建了一个单一、可靠的审计数据源——就在特定链上。

在一个去中心化的环境中，这种集中方式消除了数据碎片化的混乱。它使用户更加容易找到他们所需的信息，并增强了对审计过程的信任和可靠性。简而言之，这再次是为了让每个人的生活变得更简单和更安全。

主要考虑事项

首先，让我们谈谈 EIP 设计核心的 Token Bridge 示例。这个示例触及了 (1) 提案所期望的样子，以及 (2) EIP-7512 可能被滥用的方式。

在上面的图片中，作者描述了一个假设的 Token Bridge 协议，该协议将链上审计纳入其流程。该桥接 (1) 获取审查的 数据，(2) 验证相关审计人员的身份，并 (3) 检查代币是否符合接受的标准。

这个示例展示了作者想象中的 EIP-7512 可能是：一个可组合的协议逻辑和决策的组成部分。

但这也清楚地展示了它可能被滥用的方式。我们担心作者所描述的过程 将审计的人工验证放到了后座。在这个过程中，没有任何一步是桥接操作员明确验证审计的 内容。相反，检查审计实际内容的关键步骤被最小化——这是该 EIP 结尾处的一项免责声明。

而如果一个协议直接解读这个图示，他们可能会忽略该免责声明。因此，他们将忽略一些关键问题，例如：

• 这个协议的审计范围有多大？
• 所有建议的变更是否都已经修复？
• 如果协议将某些漏洞标记为“已承认”，审计员对此是否感到满意？

因此，如果这个 Token Bridge 示例传达出 链上审计旨在可组合的，如果协议将利用这些数据做出安全决策，它们需要什么样的更为重要的部分来做出更明智的决定？

下面是一些建议：

审计人员身份识别： 当前模型将安全研究人员视为具有名称、URI 和作者列表的统一实体。在实践中，多个专家通常匿名参与审计。他们各自的声誉可能与公司的声誉不一致。

• 我们的想法：在公司和个人审计员的层面上整合身份管理。理想情况下，这将以加密密钥的形式出现，允许对每个报告的信用/责任进行细粒度的控制。
• 当前提案建议将密钥管理问题留给审计员和注册机构，我们对此表示赞同。

审计人员认证： 目前没有关于审计人员如何被认定为可信的信息。决定是由一个封闭的圈子决定，还是会考虑新来者？

• 我们的想法：决策过程应建立在去中心化的投票基础设施上，或者采用一种坚实的民主方法。某种形式的终极 DAO。

静态审计，演变中的安全性： 安全是一个不断演变的领域——新的威胁向量和零日漏洞会随着时间的推移而出现（见：只读重入）。2018 年被视为“安全”的标准，可能在 2023 年不再适用，因为存在未在原始审计范围内的新的漏洞。

我们的想法：我们建议通过以下两种方式来缓解这个问题：

1. 审计员可以选择控制他们的数据是否有到期日期，超出该日期后明确不应由协议使用。
2. Trustblock 的团队建议注册机构或审计员也可以包括动态信息——例如新的零日漏洞、协议升级、可靠的漏洞赏金报告或其他更改。这些信息可以被整合到现有的可组合项目中，以便那些集成该协议的项目可以在必要时“ 暂停”他们的集成。

合同vs协议层审计： 目前，EIP-7512 将单个审计报告与单个智能合约地址绑定。然而，正如任何观察过跨合约重入漏洞的人所知道的，协议内的合约之间的交互可能会导致问题行为。此审计是针对个别合约吗？还是它关乎整个协议的安全，该合约是其一部分？

我们的想法：这可以是与这次审查过程相关的所有地址的哈希。需要进一步讨论。

然而，Trustblock 的团队指出，考虑到数据消费的便捷性是重要的。对于寻求与该协议集成的协议而言，更直接地获取审计范围内的合约地址最为方便。这样，协议就可以轻松检查，例如，一个想要集成到 DEX 的给定代币的每个合约是否已通过审计。

合同内范围： 审计是昂贵的，审计人员可能会因协议预算限制而迅速耗尽分配的时间。因此，合约内的一些功能、集成或功能可以被排除在范围之外。在当前提案中，注册机构/最终用户将负责追踪这一关键信息。这可能导致虚假的安全感。

• 我们的想法：可以将其整合到上面的 scope 参数中，或将其单独设为一个参数。可以是作为此次审计一部分的这些功能的哈希，注册机构的工作的职责是识别哪些功能没有经过审计。需要进一步讨论。

已审计 vs 通过审计： 安全公司明白审计人员只能提供建议和意见；他们无法保证协议创建者将解决这些问题。虽然协议可以“已审计”，但不一定“通过审计”。

• 我们的想法：当前的 EIP 在最后有一项免责声明，声明“这个 ERC 不得被视为合约安全的证明。”它将链上审计框架视为“与智能合约相关的数据”，这些数据仍然应进行手动审核。
• 然而，在一个充满黑客攻击的行业中，用户渴望安全保障。我们担心这些报告的链上性质可能会使一些人将其视为安全证明——主要是因为没有更好的替代方案，以及“链上”给人一种可信赖的感觉。当关键信息未被包含时，这种虚假的安全感更为严重，例如：

1. 总范围（“审计员审查了该协议中的所有合约吗？”）
2. 每合约的范围（“审计员审查了该协议中的每个功能吗？还是他们超时了/预算用完了？”）
3. 解决状态（“协议是否实施了所有建议的修复？如果某些发现被标记为‘已承认’，审计员是否仍然将该协议视为通过审查？”）

• 我们支持将发现的标准化留给将来的实施，但我们相信包含关键元数据将大大提高社区成员对链上审计表示的信任。

附加（代理）

正在进行中的后续工作概述了应对代理的挑战。

代理是以太坊中非常重要且丰富的一部分。为了与现代 rhombus 生态系统相关，我们认为任何涉及链上审计的提案都必须考虑如何处理代理。

从实际的角度来看，由于代理是如此丰富，我们认为如果提案不考虑如何处理它们，市场也可能会自发要求这样做。如果协议发现链上审计提高了他们的可信度，那么使用代理的协议也会渴望参与。因此，审计员将被激励不以某种方式进行链上审计以应对这些代理。

如果没有建立标准，可能会出现不同的实现。这些实现可能对整个生态系统造成不利影响——损害 DeFi 项目常依赖的组合性，并可能错误地向用户和其他组合协议展示协议的安全性。

在此，我们将主要聚焦于 Diamond 模式，但未来的工作应考虑如何将标准适用于所有代理模式。

为什么为代理/工厂链上审计数据制定标准具有困难？

tl;dr: 每种形式的代理可能使用不同的方法加载实现合约地址。

由于存在许多形式的代理合约，并不是所有都遵循已建立的标准，因此很难为所有合约定义适用的规则。

然而，忽略这些似乎也不是个好解决方案。

作者目前在跟进中提出了什么？

目前的跟进编辑在这里: \\\\ 专注于 Diamond 模式代理。虽然作者讨论了将更多明确数据（例如合约是否为代理或是否可升级）添加到安全审查摘要中，但他们最終选择将这些细节留给生态系统来决定。

作者花费大量时间辩论 runtimeCode 或 deploymentCode 哪种更适合表示代理指向的底层实现合约。

最终，runtimeCode 和 deploymentCode 的选择可能是附加中的最大争论关系。它指出了一个关键的权衡：我们能多精确地匹配实现，同时又让检索和验证变得容易？

deploymentCode 和 runtimeCode 之间有什么区别，为什么这很重要？

如果我们深入了解，我们会记住代理并不是魔法。在其核心，代理只是标准化使用 delegatecall 指令，这个指令使用由某个地址和某些 runtimeCode 组成的哈希链。

然而，尽管 runtimeCode 包含在 EVM 上执行的代码，但它 并不包含 构造逻辑或构造参数。这些构造逻辑可以包括关键的安全机制，如角色分配，如果被改变可能导致漏洞。

deploymentCode 在这一问题上解决了一些问题，因为它还包含构造函数和任何初始化逻辑，而 runtimeCode 缺乏。但是，检索过程更困难（我们不能像获取 runtimeCode 那样简单调用 web3.eth.getCode，我们需要抓取创建该合约时的交易中的字节码），而且 它仍然不包含构造参数。

缺乏构造函数参数会给我们带来什么麻烦？

让我们考虑工厂合约的例子。在以太坊生态系统中，一个工厂可以部署多个看似相同的合约——使用相同的 runtimeCode 和 deploymentCode——但具有不同的构造参数。这些不同的构造参数可能会引发完全不同的行为，带来新的攻击向量和“割韭菜”的机会。

让我们看看几个例子：

1. 未初始化状态：如果一个合约期望某些状态通过构造函数进行初始化但没有，那么这可能导致漏洞行为。例如，考虑一个应该在构造函数中设置的管理员角色。如果未正确初始化，则任何地址——甚至没有地址——可能会在部署后声称管理员角色。
2. 参数配置错误：构造参数通常包括配置参数，如费用和支出限制。这些也可能包括诸如电路断路器等停止机制的阈值。如果这些参数设置不当，可能导致利用向量或使合约无法使用。
3. 预言机初始化：如果合约依赖于预言机，而地址是通过构造函数设置，则不正确的地址或恶意的预言机可能会提供错误的数据。
4. 初始铸造：在代币合约中，构造函数可能盘定初始分发或直接铸造代币。不正确的参数可能会导致不平衡，造成“割韭菜”的机会，其中初始接收者通过出售其不成比例的持仓来崩溃市场。
5. 初始治理参数：在 DAO 或其他基于治理的系统中，构造参数可能包括初始投票权或其他治理参数。不正确的设置可能导致治理攻击。
6. 白名单/黑名单：在具有受限访问的合约中，构造函数通常设置初步白名单或黑名单。不正确的设置可能允许黑客进行未授权访问或阻止合法用户。
7. 时间锁定功能：一些合约有函数是时间锁定的，或者只能在特定区块号之后调用。这个区块号可能在构造函数中设置。不正确的设置可能导致功能无限期锁定，或立即可用。

编码构造函数参数的方法

由于像 工厂 这样的机制可能引入歧义，因此让审计指向具体的部署状态是很重要的。构造函数参数在这个过程中起着至关重要的作用。以下是我们关于编码此信息的两种方法的初步想法：

• 方法 A：预部署审计人员验证。 被审计的协议可以提供将在部署时使用的确切构造参数。审计员可以将所有构造参数依次整理在一起，并提供该压缩对象的哈希。任何想要验证该实现不仅与预期的 runtimeCode 和 deploymentCode 匹配的人，也可以从初始交易的数据字段中抓取所有的参数，连接在一起，哈希化，并验证该哈希是否与审计员提供的哈希相符，以确保这些参数（1）与预期的参数（2）匹配。

这一连接方法可以实现标准化，提供用于原始参数（预部署）的接口，以及解释从初始化交易抓取的数据（后部署）的接口。

• 方法 B：后部署审计人员验证。 被审计的协议也可以选择在部署后进行此类验证。核心思想有点像 etherscan，尽管初始化交易的 input 参数可能无法立即解析，但可以以人类可读的形式提供给注册机构并寻找与初始化交易的匹配。为了更好地实现这一点，审计员可以证明某些由协议提供的构造参数和存储值之间的链接。

展望未来

我们非常感谢你的关注，并将不断努力以提升敏感区块链领域 多层安全 的伟大愿景。我们的研究团队并不限于特定的个人；相反，我们非常开放，渴望倾听你对上述主题的想法和观点。欢迎任何人通过评论或直接通过我们的私信分享他们的反思。再次强调…… 我们的目标不是与其他组（我们深切尊重）竞争，而是帮助他们构建一种技术标准，从而增加可靠的广泛采用的可能性。希望我们的材料给你带来 乐观 的能量！和平与进化，匿名者！

参考文献：

1. https://eips.ethereum.org/EIPS/eip-7512
2. https://safe.mirror.xyz/Li4Mb4teTEmosE6dAsnJ_iz3aMKOV_4lDU84W4TSfc0
3. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7512.md

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

关注 Rektoff：

• Twitter: https://twitter.com/rektoff_xyz
• Discord: https://discord.com/invite/QSHRSHqXMA
• 网站: https://www.rektoff.xyz/
• 更多链接: https://linktr.ee/rektoff

若要订购安全审查，请联系：

Telegram: t.me/gregorymakodzeba

电子邮件: greg@rektoff.xyz

• 原文链接： medium.com/rektoff/an-in...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～