ChainSecurity:2026年以太坊安全审计师愿望清单

chainsecurity 发布于 2026-05-05 阅读 217

ChainSecurity团队基于多年审计经验,提出2026年以太坊安全的五项关键改进:持续白帽模糊测试基础设施(基于主网状态)、编译器级合约分拆以规避24KB限制、运行时组合性风险检查(而非仅审计时)、共享安全基础设施的资金支持(如漏洞注册表和标准测试套件)、以及用户签名流程的UX安全改进(如模拟交易结果)。这些建议旨在从底层提升生态安全性,减少常见漏洞。

ChainSecurity 审计师对 2026 年以太坊安全的愿望清单

我们从 2017 年(DeFi 出现之前)就开始审计智能合约,见证了智能合约审计从简单的重入检查演变为保护着数十亿美元资产的协议。然而,某些问题依然存在。为此,我们根据研究团队(包括我们的七位 ETH Security Badge 持有者)的意见,整理了一份包含五项关键安全改进的“愿望清单”,重点关注必要的基础公共产品。这份清单并非详尽无遗,我们决定不重复那些更为明显的解决方案。

1. 在真实链上状态运行的白帽模糊测试基础设施

过去两年中披露和利用的错误中,相当一部分是通过模糊测试发现的。攻击者会持续对关键合约运行模糊测试,而白帽通常只在审计窗口期间,在本地分叉上偶尔运行。

本地模糊测试无法利用几个月的主网历史数据。它们综合出的状态看起来合理,但从未在链上发生过,并且会遗漏那些真实发生的状态。

我们建议:

建立共享的模糊测试基础设施,任何白帽都可以提交一个目标(合约地址加一组不变量或断言),并让其持续在分叉的主网状态下进行模糊测试。使用真实价格、真实流动性和真实升级历史。攻击者需要耐心观察数月才能发现的错误,通过协调的白帽行动应该能在数天内被发现。

目前,这一想法已通过 Echidna、Medusa、Foundry 的不变量测试以及各种专有内部模糊测试工具得以部分实现,当然还有像 Tenderly 这样面向开发者的出色付费解决方案。然而,目前还没有一个针对白帽的、协调一致的、持久运行的主网状态服务。

2. 在编译器中一劳永逸地解决问题,而不是在用户代码中重复修复一百次

当一个非平凡协议超过 EVM 合约大小限制(24KB)时,开发者需要将逻辑拆分到多个合约中,并立即继承一类新的问题。例如,模块间的访问控制、跨合约的状态一致性、跨合约的重入以及升级协调等。每一次拆分都可能引入一个在单一版本中本不存在的错误。

编译器的工作是隐形的、缓慢的,并且惠及除工程师以外的所有人。没有任何代币经济激励机制与让 solc 和 vyper 更好地处理大小限制相关联,也没有明显的客户为此付费。以太坊基金会只资助它愿意资助的项目。

我们建议:

开发者应该能够编写任意逻辑大小的合约,并由编译器处理拆分。编译器决定内容放置位置,管理跨模块的访问模式,并证明最终部署与源代码等价。在 Solidity 和 Vyper 中各做好一次,一整类错误就会消失。

这比听起来要宏伟得多。它要求编译器能够推理状态布局、调用模式以及跨已部署合约图的重入,而不仅仅是对单个字节码 blob。但这是在正确的层面解决问题,并且是可处理的。

3. 可组合性是持续存在的风险,而非审计时的单项检查

今天通过审计的合约,明天可能因其一个依赖项的变化而暴露风险。你集成的金库调整了份额计算方式,你信赖的预言机更改了底层数据源,你依赖的池子进行了重新平衡或增加了新的资产类型,等等。这些都不需要协议侧更改代码,但都能将其从“安全”推向“可被利用”。

我们最初在 2022 年针对 Curve 和 Balancer V2 池披露了只读重入。之后很多年,同一类错误不断重现,并非因为有谁部署了新的易受攻击代码,而是因为新的集成者不断将看似安全的代码连接到那些暴露了底层状态的池子上。

同样的动态现在围绕 ERC-4626 出现。该标准被广泛采用,也被广泛误解。舍入行为、份额与资产边角情况、捐赠攻击、在一个金库中成立而在另一个金库中失效的集成假设——我们每个月都会看到此类近失事件。该标准发布时没有附带一致性测试套件,因此每个集成者的解释都略有不同。错误自然随之而来。

依赖关系图没有规范的映射。当某个协议推送升级时,集成者通过关注治理论坛、扫描交易轨迹,或碰巧从安全研究人员那里得知。

我们建议:

理想情况下,两件事应同时进行:

  1. 整个生态系统的真实依赖关系图。不仅仅是导入图,而是协议级别的集成。这将使协调披露的效率大幅提高。当发现一类错误时,你应该能够查询“还有谁暴露了?”,并在几分钟内获得答案,而非数周。

‍ 2. 运行时不变性检查作为标准实践,而非事后想法。那句“这个断言应该永远不会触发,但以防万一”的代码已经阻止过多次攻击。防御深度因为暗示你不信任自己的代码而不受欢迎。但这本应是基本门槛。

4. 以太坊的 CVE,以及为枯燥的基础设施提供资金

智能合约漏洞分散在博客文章、治理论坛、事后分析报告和 Twitter 推文中。质量参差不齐。有些是公开且记录完整的。有些是公开但被埋没的。有些在技术上公开(发布在无人阅读的论坛上),但对任何需要了解它的人来说实际上是不可见的。

以太坊没有 CVE 数据库的等价物。没有一个权威的地方可以查询“这种确切的错误模式以前是否出现过,在哪里,以及如何修复?”。新协议不断重新发现同一类错误,因为缺乏共享记忆。

同样的模式也出现在标准中。ERC-4626 没有附带一致性测试向量。SEAL 911 和 SEAL Frameworks 依靠志愿者的善意运行。客户端测试基础设施与其重要性相比长期资金不足。这些都是同一个问题:没有人拥有共享基础设施,所以它只能由某位英雄一次性构建,然后慢慢腐烂。

公共产品问题很难解决。这些工作不产生收入,受益者分散,而愿意资助的人通常专注于自己协议的路线图。以太坊基金会资助了其中一部分,也有资助项目。

我们建议:

一个维护良好、结构化的漏洞注册库。主要 EIP 的一致性测试套件(从 4626 开始,因为那里是我们看到最多可预防问题的地方)。对 SEAL 911 式协调(不是出于善意,而是实际的组织能力)的持续资助。对客户端测试和模糊测试基础设施的持续资助,其水平应与保障数千亿美元资产的代码相称。

5. 账户入侵与签名流程

一次签名交易欺诈导致一家数十亿美元的交易所被黑,前端通过受感染的依赖项被接管,存在与合法界面完全相同的钓鱼流程,私钥从受感染的设备、恶意浏览器扩展和社会工程中被窃取。这是 ETH 安全领域房间里的大象。

这并非新问题,并且正在从多个角度得到解决。MetaMask、Rabby 等工具都包含某种形式的警报、交易模拟、尝试解码参数等。但这感觉都是权宜之计,经常被富有创造力的攻击者绕过,或者(更常见的是)被不堪重负的用户忽略。

安全的用户体验要求用户理解他们在批准什么。EIP-712 使得结构化签名成为可能,但“结构化签名成为可能”与“用户真正理解他们签的是什么”之间存在巨大鸿沟。硬件钱包仍然显示截断的地址,浏览器钱包在争夺用户参与度而非安全性。前端可以被替换。扩展可以撒谎。

我们建议:

签名流程应默认将危险操作设为困难,而不是让安全成为大多数用户从未发现的高级设置。钱包应模拟交易的实际结果并以人类可读的术语显示,例如“你将会失去 12 ETH 并获得 0 USDC”,并在模拟异常时拒绝继续,除非用户明确第二次确认。硬件应显示有意义的交易摘要,而不是原始的调用数据。前端完整性检查不应依赖于用户是否注意到。

6. 结论

总结一下,以下是我们最希望优先处理的事项,以切实提升以太坊的安全基线:

  • 为白帽提供更好的模糊测试基础设施
  • 在编译器层面解决合约大小问题
  • 将可组合性视为运行时问题,而非审计时的单项检查
  • 为无人拥有的共享基础设施提供资金
  • 以及一项可能改变游戏规则的事:提升钱包用户体验的基线

显然,这份清单并不完整,还有很多其他重要事项。这些仅仅是我们最近一直在思考的问题。

因为更安全的以太坊惠及所有人,我们相信应资助保护它的工作,并支持当前社区的努力。每位 ChainSecurity 员工都已获得资金,可捐赠给他们认为在当前由 The DAO Fund 和 Giveth 举办的 ETH Security Quadratic Funding 轮次中最重要的项目。

外部链接

  • 原文链接: chainsecurity.com/blog/a...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论