跳到主要内容

2 篇博文 含有标签「security auditing」

智能合约安全审计和分析

查看所有标签

18 天损失 6.06 亿美元:为什么升级引入的漏洞正成为 DeFi 的首要攻击向量

· 阅读需 14 分钟
Dora Noda
Software Engineer

仅在 2026 年 4 月的 18 天内,攻击者就从 DeFi 中抽走了 6.06 亿美元。这一时期的损失是 2026 年第一季度总损失的 3.7 倍,使该月成为自 2025 年 2 月 Bybit 被盗案以来最糟糕的一个月。两个协议——Solana 上的 Drift 和 Ethereum 上的 Kelp DAO——占据了 95% 的损失。这两个协议都经过了审计,都通过了静态分析,都发布了常规升级,但这些升级悄无声息地使审计师验证过的假设失效了。

这是 DeFi 风险的新面孔。2026 年的灾难性漏洞利用不再是模糊测试工具在 CI 中就能发现的重入漏洞或整数溢出。它们是升级引入的漏洞:对桥接配置、预言机源、管理员角色或消息传递默认设置的细微更改,将原本安全的代码变成了敞开的大门——而 Solidity 的任何一行代码看起来都没有明显错误。

如果你在 DeFi 中进行开发、托管或仅仅是持有资产,2026 年 4 月带来的教训是令人不安的:三个月前的一份干净的审计报告,已不再能证明该协议在今天仍然安全。

4 月的模式:配置而非代码

要理解为什么“升级引入”值得被归为单独一类,请看这两起最大的漏洞利用是如何实际发生的。

Drift Protocol —— 2.85 亿美元,2026 年 4 月 1 日。 Solana 上最大的永续合约 DEX 在攻击者对团队进行了为期六个月的社会工程学攻击后,损失了超过一半的 TVL。一旦建立了信任,攻击者就利用 Solana 的“持久化 nonce (durable nonces)”功能(一种旨在让用户预先签署交易以便稍后提交的 UX 便利功能),诱骗 Drift 安全委员会成员授权他们认为是常规运营签名的操作。这些签名最终将管理权限交给了攻击者,攻击者随后将一个伪造的抵押品代币 (CVT) 列入白名单,存入了 5 亿个单位,并提现了 2.85 亿美元的真实 USDC、SOL 和 ETH。Solana 的功能运行正常。Drift 的合约也在执行管理员的指令。攻击完全发生在多签签署者认为他们批准的内容与实际批准的内容之间的鸿沟中。

Kelp DAO —— 2.92 亿美元,2026 年 4 月 18 日。 LayerZero 认为攻击者是朝鲜的 Lazarus Group,他们劫持了支持 Kelp 跨链 rsETH 桥的两个 RPC 节点,更换了其上运行的二进制文件,并利用 DDoS 强制验证器故障转移。随后,恶意节点告诉 LayerZero 的验证器发生了一笔欺诈交易。该漏洞之所以能被利用,是因为 Kelp 运行了 1-of-1 验证器配置——这意味着单个由 LayerZero 运营的 DVN 拥有确认跨链消息的单方面权限。据 LayerZero 称,这种 1-of-1 设置是其快速入门指南中的默认设置,目前该网络上约有 40% 的协议在使用。在 46 分钟内,攻击者抽走了 116,500 个 rsETH(约占总流通供应量的 18%),并将封装好的抵押品滞留在 20 条链上。列出 rsETH 的 Aave 因存款人竞相退出而被迫陷入流动性危机。

这两起攻击都不需要智能合约漏洞。两者都要求理解一种配置——多签签名流、默认 DVN 数量、RPC 冗余——是如何被默默地从“运营细节”提升为“承重的安全假设”的。

为什么静态审计会遗漏这类漏洞

传统的 DeFi 审计针对的是错误的威胁模型。Certik、OpenZeppelin、Trail of Bits 和 Halborn 等公司擅长逐行代码审查,并针对冻结的合约版本运行不变性测试。这能发现重入、访问控制错误、整数溢出和 OWASP 类型的故障。

但升级引入的漏洞类别具有三个令该工作流失效的特性:

  1. 它存在于组合的运行时行为中,而非源代码中。 跨链桥的安全性取决于其消息层的验证器配置、DVN 集合、这些 DVN 的 RPC 冗余以及这些运营商的罚没风险暴露。这些都不在审计师阅读的 Solidity 代码中。

  2. 它是通过变更引入的,而不是初始部署。 Kelp 的桥接在最初集成 LayerZero v2 时想必看起来是没问题的。只有当 TVL 增长到足以成为攻击目标,且 Lazarus 投入资源攻击 RPC 基础设施时,DVN 数量才变得危险。

  3. 它需要行为差异测试 (behavioral differential testing) —— 即回答“在新的代码路径下,不变性 X 是否仍然保持?”——目前主要的审计公司都没有将此作为定期的升级后服务进行产品化。你在 1.0 版本获得一次性审计,在 1.1 版本获得另一次性审计,但没有持续的声明来证明从 1.0 升级到 1.1 不会破坏 1.0 所依赖的特性

2026 年第一季度的统计数据量化了这一差距。整个季度 DeFi 在 34 起事件中记录了 1.655 亿美元的损失。仅 4 月份就在 12 起事件中产生了 6.06 亿美元的损失。部署侧在扩张——第一季度新增了超过 400 亿美元的 TVL——而审计能力、事件响应和部署后验证则基本保持持平。总有些环节会出问题。

使 2026 年成为风险大规模爆发之年的三大力量

1. 各个层级的升级节奏都在加快

每个 L1 和 L2 都在以更快的速度迭代。Ethereum 的 Pectra 升级正在积极推出,Fusaka 和 Glamsterdam 处于设计阶段,而 Solana、Sui 和 Aptos 都在以数周为周期发布执行层变更。每一次链级升级都可能微妙地改变 Gas 语义、签名方案或交易排序,从而对应用层的假设产生波纹效应。Drift 的漏洞利用是一个典型的例子——一个旨在提供 UX 便利的 Solana 特性(持久化 nonce)成为了管理员权限接管的载体。

2. 再质押加剧了升级的暴露面

再质押技术栈——EigenLayer(仍占据 80% 以上的市场份额)、Symbiotic、Karak、Babylon、Solayer——为这个问题增加了第三个维度。像 rsETH 这样的单一 LRT 位于 EigenLayer 之上,而 EigenLayer 又位于原生 ETH 质押之上。每一层都按照自己的计划发布升级。EigenLayer 削减(slashing)语义的改变,会对每个节点运营商以及消费该运营商验证服务的每个 LRT 产生隐含影响。当 Kelp 的桥接被抽干时,这种传染风险立即威胁到 EigenLayer 的 TVL,因为同样的存款人面临着他们从未被强制建模过的三层再抵押敞口。随着即将到来的 EigenDA、EigenCompute 和 EigenVerify 扩展,EigenCloud 的路线图只会进一步扩大这一暴露面。

3. AI 驱动的 DeFi 活动比人工审查更快

XION、Brahma Console 和 Giza 等代理栈(Agent stacks)现在正以机器速度与升级后的合约进行交互。人类财务主管可能会在合约升级后等待数天再重新参与,而代理则会在数小时内完成回测、集成并引导资金。任何悄悄破坏不变量的升级,在人类审计师能够重新审查之前,都会受到对抗性流量的压力测试。

正在浮现的防御性架构

令人振奋的消息是,安全研究社区并未坐以待毙。2026 年 4 月的损失催生了四个方面的具体提案。

持续形式化验证。Certora 与 Aave 的长期合作——作为持续验证赠款而非一次性业务资助——现在已成为模板。Certora Prover 在每次合约更改时都会自动重新运行不变量证明,在合并之前发现破坏点。Halmos 和 HEVM 为实现同一目标提供了替代的开源路径。当形式化验证最近在与 Ethereum 的 Electra 升级集成中捕获了一个传统审计遗漏的漏洞时,这并非偶然,而是一个预兆。

升级差异(Diff)审计服务。Spearbit、Zellic 和 Cantina 已开始试点付费服务,专门审计两个合约版本之间的“差异”,而不是孤立地审计新版本。该模型将每次升级视为一次新的认证,并明确检查先前的不变量是否得以保留。Ethereum 基金会于 2026 年 4 月 14 日启动的 100 万美元审计补贴计划,其合作伙伴名单包括 Certora、Cyfrin、Dedaub、Hacken、Immunefi、Quantstamp、Sherlock、Spearbit、Zellic 和 Zokyo,部分目的就是为了扩大处理此类工作的能力。

混沌工程和运行时监控。OpenZeppelin Defender 和新兴工具正将分叉主网模拟(forked-mainnet simulations)接入 CI 流水线,允许协议针对每一个提议的升级回放对抗性场景。这种学科直接借鉴了 Web2 SRE 的实践——在 DeFi 领域早已迫在眉睫。

时间锁升级托管。Compound Timelock v3 模式中,每个经治理批准的升级都会在执行前在公开队列中停留一段固定的延迟时间,这为社区提供了发现内部审查遗漏问题的机会。它不能防止升级引入的 Bug,但它为漏洞利用前的发现赢得了时间。

TradFi 对比:持续审计是 DeFi 之外的常态

传统金融在几十年前就解决了类似的问题。SOC 2 Type II(大多数机构服务提供商遵循的标准)不是一次性认证,而是一个 6 到 12 个月的持续审计窗口。巴塞尔协议 III 的交易对手风险框架要求银行在风险敞口发生变化时更新其资本模型,而不是每年更新一次。升级结算系统的托管银行将不被允许基于“我们审计了 v1,v2 只是个小改动”的基础进行运营。

DeFi 盛行的文化——“审计一次,永久部署,仅在重大重写时重新审计”——是 TradFi 在 2008 年危机后明确拒绝的做法。按照目前的损失率,该行业有望达到 20 亿美元或更多的年度升级漏洞利用损失。这足以引起监管机构的注意,他们已经认为 DeFi 的审计标准不达标;这也足以使持续验证成为机构资本入场的先决条件。

这对开发者、存款人和基础设施意味着什么

对于协议团队来说,运营任务是明确的,即便代价昂贵:每次升级都必须被视为一个重新推导(而非继承)其安全保证的新发布。这意味着基于差异的定期重新审计、随每个治理提案同步的形式化验证规范,以及执行前的实质性时间锁。这意味着需要像 Aave 那样发布一个量化的级联风险框架,指明你依赖哪些协议,以及当其中一个协议失败时你的风险敞口。

对于存款人来说,教训是“该协议已通过审计”本身不再是一个有用的信号。正确的问题应该是:“针对哪些不变量、针对哪个部署代码版本,进行了最近一次持续验证运行?”无法回答该问题的协议应在定价中体现相应的风险。

对于基础设施提供商(RPC 运营商、索引器、托管商)来说,Kelp 事件是一个直接警示。该漏洞存在于两个二进制文件被悄悄替换的 RPC 节点中。任何运行参与跨链验证的基础设施(DVN、预言机节点、定序器)的人,无论是否自愿,现在都是安全模型的一部分。可复现构建、经过认证的二进制文件、高于 1-of-1 默认配置的多运营商法定人数,以及启动时的签名二进制验证,都不再是可选的。

链级升级——Ethereum 上的 Pectra 和 Fusaka,Solana 和 Aptos 上的并行执行推广,Glamsterdam 的吞吐量目标——将继续扩大暴露面。能够在 2026 年幸存下来的协议和基础设施运营商,将是那些尽早采用持续验证的人,使得他们的下一次常规升级同时也成为下一次可证明的安全检查点。

BlockEden.xyz 在 Sui、Aptos、Ethereum、Solana 和其他十几个链上运行生产级 RPC、索引器和节点基础设施。我们将每一次协议升级(无论是在链层还是应用层)都视为一次新的安全事件,而非维护任务。探索我们的企业级基础设施,在旨在应对未来升级节奏的基石上进行构建。

来源

探索 Web3 生态系统中安全审计的用户认知

· 阅读需 6 分钟
Dora Noda
Software Engineer

对于 Web3 领域的专业人士而言,安全审计不仅是技术必需,更是项目生命周期中的关键里程碑。然而,来自澳门大学和宾夕法尼亚州立大学的开创性研究——基于对 20 名用户的深度访谈以及对超过 900 条 Reddit 帖子的分析——揭示了一个严峻的现实:行业审计实践与终端用户的实际认知、信任模型和行为决策之间存在显著差距。

本报告不仅是学术讨论,更是面向所有 Web3 从业者的情报简报。它识别了当前审计生态系统中的痛点,并提供了明确的战略路线图,以更有效地利用审计来建立信任并引导用户行为。

核心洞见:用户如何看待你的“安全证书”?

1. 信息获取中的“隧道视野”效应 用户获取审计信息的主要且往往唯一渠道是项目的官方网站。所有受访者均确认了这一行为模式。

  • 战略意义:你网站是传达审计价值的主战场。不要假设用户会进一步查阅审计公司的官网或在链上交叉验证信息。审计信息在你站点上的呈现方式直接塑造用户的第一印象和信任基础。

2. 感知信息价值的两极化 用户普遍认为当前审计报告的信息价值不足,这表现为两种方式:

  • 对专家价值不足:技术熟练的用户觉得许多报告“仓促、公式化且重复”,缺乏深度和有意义的洞见。
  • 对新手门槛过高:非技术用户被专业术语和代码淹没,难以理解。对审计公司网站的外部审查进一步证实:超过三分之一的公司缺乏对服务流程的详细描述,且大多数未充分披露审计员的专业资质。
  • 战略意义:当前“一刀切”的 PDF 报告格式未能满足不同用户群体的需求。项目方和审计公司必须考虑分层、交互式的信息披露策略——简明摘要、可视化风险评估,以及供专家审查的完整技术细节。

3. 信任模型的脆弱性:在普遍怀疑中依赖声誉 用户将审计公司的“声誉”视为判断质量的主要标准,但该信任模型十分脆弱。

  • 声誉的模糊性:许多受访者无法说出超过一家审计公司,这表明用户对声誉的认知模糊且易受影响。
  • 对独立性的根本怀疑:由于审计服务由项目方付费,用户普遍质疑其公正性。一位受访者概括道:“他们不太可能公开批评或‘打垮’客户。”Reddit 讨论也呼应了类似的怀疑。
  • 战略意义:用户信任并非建立在技术细节上,而是对独立性和公正性的感知。主动提升审计过程透明度——例如披露与客户的工作流程——比单纯发布技术报告更为关键。

4. 审计的真实价值:“努力的证明” 尽管对有效性和公平性存在疑虑,几乎所有受访者都达成共识:进行审计本身是项目对安全和责任承诺的强有力信号。

  • 一位参与者解释道,这表明“该应用对安全非常重视,且至少愿意投入审计”。
  • 战略意义:审计不仅是技术防护手段,也是关键的营销和信任构建工具。其象征意义远超用户实际理解的内容。团队应在营销和社区沟通中强调对独立审计的投入。

5. 用户决策行为:二元且不对称

  • 关注“是否存在”,而非“质量”:用户审阅审计信息的时间极少——通常不足 10 分钟。他们更在意是否有审计,而非审计的细节。
  • 不对称影响:正面的审计结果显著提升社区信心。负面结果虽会引起关注,但对高风险用户的威慑作用有限。
  • 战略意义:二元的“已审计/未审计”状态是用户决策中最具影响力的单一变量。项目方应确保该状态清晰可见。审计公司则可设计报告结论,使其对用户决策产生更大影响。

面向未来的设计与战略转型

基于这些洞见,研究为从业者提供了明确的行动计划:

  1. 针对审计公司:重塑报告和服务模型

    • 从静态到交互:摆脱传统 PDF 报告,转向具备分层数据、可点击代码片段和内置反馈机制的交互式网页平台
    • 拥抱彻底透明:主动披露审计方法、关键流程,甚至客户互动(除核心机密外),以展示独立性和公正性。
    • 推动行业标准化:缺乏标准削弱行业可信度。公司应帮助建立统一的实践、风险分类和报告规范,并对社区进行教育。
  2. 针对项目团队:将审计融入用户体验与沟通策略

    • 优化信息呈现:在网站上清晰展示审计信息。简洁的“审计摘要”页面并链接至完整报告,比单纯的 PDF 链接更有效。
    • 利用“努力的证明”:在营销、社区 AMA 和白皮书中将完成第三方审计定位为核心信任里程碑。
    • 承担教育角色:与审计方合作共同举办安全教育活动。既提升认知,又增强项目和审计品牌的信任。
  3. 针对社区与生态系统建设者:利用集体智慧的力量

    • 赋能社区:支持技术专家或 KOL 提供审计报告的第三方解读和评审。
    • 探索 DAO 治理:尝试由 DAO 委托或监督审计的模型。此方式可通过社区投票和激励机制强化独立性和可信度。

总之,这项研究发出明确警示:Web3 行业不能再将审计视为孤立的技术职能。从业者必须正视当前实践与用户认知之间的差距,将用户体验和信任构建置于核心。唯有提升透明度、优化沟通并推动标准化,才能共同构建更安全、更可信的去中心化未来。