智能合约风险：审计、漏洞利用及其遗漏之处

TL;DR

少数几类反复出现的漏洞类型导致了合约层的大部分损失：重入漏洞、预言机操纵、访问控制失效、算术和验证错误，以及按代码原样运行却存在缺陷的业务逻辑。每类漏洞都与某个著名的“牺牲品”相关联，行业正是通过这些案例学会了给它们命名。
审计是在专家工时预算范围内，将代码的固定快照与已知的漏洞类别及团队声明的意图进行比对；几乎所有其他内容——经济模型、预言机、治理机制、运维、依赖项以及未来发展——均不在审查范围内。阅读审计报告的“范围”章节比查看其认证标识更能提供实质信息。
分层架构且预设故障：多重独立审查、在关键环节应用形式化方法和模糊测试、持续监控、经济断路器、定时锁定变更、漏洞赏金计划，以及针对漏洞突破时的演练方案。每一层都能捕获不同的遗漏模式，这正是分层架构的核心意义。

在一个街区

审计是在特定假设下对特定代码进行的、有时间限制的专家审查。它虽能降低风险，但设计上会遗漏整类故障：经济攻击、预言机信任、升级治理、编译器漏洞、链下基础设施，以及报告签署后发生的所有变化。损失数据已发生变化。2026年上半年，智能合约漏洞利用约占事件总数的60%，但仅占损失总额的很小一部分；基础设施和密钥泄露事件约占总事件的15%，却占损失总额的76%。代码变得更难被攻破，但围绕代码的运维措施却未能跟上这一步伐。经过审计的协议依然会出错。2025年5月，Cetus因一个被多次审计忽略的溢出检查漏洞，导致约2.23亿美元被利用，其中约1.62亿美元随后被冻结并纳入社区恢复流程；2023年，Euler因审计曾审查过的逻辑漏洞损失了1.

智能合约中究竟是什么导致了故障？

快速解答

少数几类反复出现的漏洞类型导致了合约层的大部分损失：重入漏洞、预言机操纵、访问控制失效、算术和验证错误，以及按代码原样运行却存在缺陷的业务逻辑。每类漏洞都与某个著名的“牺牲品”相关联，行业正是通过这些案例学会了给它们命名。

重入攻击是经典案例。合约在更新自身状态前向外部地址发送价值，而作为合约的接收方在更新生效前回调，从而形成循环套利。2016年的DAO黑客事件（当时损失约6000万美元）确立了这一攻击类型，并导致以太坊分裂为两派。十年后，重入攻击依然存在，有时甚至以奇特的形式出现：2023年的Curve事件，跨多个资金池损失约7000万美元，源于特定版本的Vyper编译器内部重入保护机制失效，这意味着源代码逻辑正确的合约被编译成了不正确的字节码。审查源代码的审计人员对此却视而不见。

预言机操纵攻击针对输入数据。信任价格馈送的合约可能会因价格被篡改而遭受盗取，而闪电贷则能在单个原子交易内提供用于篡改的资金。2022年Mango Markets事件（损失约1.14亿美元）是此类攻击的典型案例，其运作机制至今仍屡见不鲜；本专题的支柱部分将深入剖析这一模式。

访问控制失效是一类令人尴尬的漏洞：由于缺少修饰符，任何人都能调用函数；初始化器未加限制；部署者密钥保留了特权角色。2017年Parity钱包事件——数千万被盗，超过1.5亿美元永久冻结——均可追溯至此。

尽管采用了更安全的编程语言，算术和验证错误依然存在。2025年5月，Sui上最大的去中心化交易所（DEX）Cetus因一次溢出检查对比了错误的常量，导致精心构造的值通过验证并篡改了流动性核算，最终被利用，损失约2.23亿美元。根据事件事后分析报告，该合约曾经过多次审计。事件后续处理情况值得记录：通过验证者协调行动，约1.62亿美元被冻结，并经社区投票决定转入恢复与赔偿流程。被利用的总金额与被冻结或转入恢复流程的金额应分别报告，最终净损失数额应在存在带日期的会计记录后才予以公布，而非基于推测。

最后，纯粹的逻辑错误：代码能够编译通过、通过测试、按预期运行，却得出了错误的结果。Euler Finance在2023年遭受的1.97亿美元损失，源于捐赠机制与清算逻辑的结合，这种结合在任何单行代码中都无法显而易见。这一类错误没有检测工具，因为除了设计理念本身之外，技术上没有任何地方是错误的。

审计实际上检查什么，哪些内容是设计上被排除在范围之外的？

快速解答

审计是在专家工时预算范围内，将代码的固定快照与已知的漏洞类别及团队声明的意图进行比对；几乎所有其他内容——经济模型、预言机、治理机制、运维、依赖项以及未来发展——均不在审查范围内。阅读审计报告的“范围”章节比查看其认证标识更能提供实质信息。

一次严谨的审计包括由经验丰富的研究人员进行人工审查、静态分析、依据规范进行测试，以及按严重程度对发现问题进行分级的报告。当团队的规范有误时，审计会以错误的目标为基准检查代码；当规范未作说明时，审计人员会推断其意图。这两者都是导致遗漏的隐性原因。

这些结构性局限值得明确列出。审计是“点对点”的：被审查的提交版本是实际检查的对象，而三个月后发布的升级版本则不在其中。审计范围有限：出于预算考虑，外围合约、部署脚本、管理工具和集成通常会被排除在外。审计充满假设：报告通常假设预言机诚实、代币合理、管理密钥可信，而这些恰恰是攻击者绝不会认同的假设。除非另行购买经济审查服务，否则审计在经济层面存在盲区：受操纵情况下的偿付能力、激励机制失效以及与其他运行中协议的毒性组合性，属于另一门学科。此外，审计的堆栈深度有限：编译器、虚拟机及其底层的节点软件几乎从未被纳入审查范围，而Curve事件的根源恰恰就在于此。

时间压力使所有问题雪上加霜。审计公司仅对搜索空间进行抽样，而攻击者在部署后却拥有无限时间、实时状态以及整个链的组合性作为工具。这种不对称性是结构性的：审核人员必须在固定的委托范围内考虑一切；而攻击者只需找到一个被所有人忽略的漏洞，便能永久利用。

以上内容并非反对审计的论据。而是主张将“已审计”理解为“在限制条件下由专家抽样检查”，从而使该认证标签与其实际承载能力相匹配。

Diagram of smart contract audit scope showing reviewed code at the centre surrounded by out-of-scope risks including oracles, upgrades, governance, economics, compiler and operations — 图 1. 智能合约审计的覆盖范围及其框架之外的漏洞面。

为何经过审计的协议仍会损失数亿？

简短回答：因为损失分布恰恰反映了审计所遗漏的部分：审计后的变更、被排除的组件、跨协议交互、存在安全隐患的操作及经济设计，再加上抽样不可避免会遗漏的残余漏洞。那些“经过审计却仍遭黑客攻击”的案例已多到足以形成一种类型。

最新数据使这一模式得以量化。 TRM Labs统计显示，2026年上半年共发生207起安全事件，创下历史新高，但总损失额不足10亿美元，同比下降58%；其中智能合约漏洞利用约占事件总数的60%，但损失金额仅占很小一部分；而基础设施攻击、密钥、签名环境及运维访问等，虽仅占事件总数的约15%，却造成了约76%的资金损失。 2025年的数据则更直白地揭示了这一趋势：被盗金额约34亿美元，其中15亿美元的Bybit盗窃案占据主导地位——该攻击针对的是签名工作流，而非任何智能合约。攻击者正转向防御最薄弱的环节，而多年的审计工作使得相较于运营环节，智能合约漏洞已成为更难攻破的目标。

当经过审计的代码本身出现故障时，前文所述的分类体系通常能解释原因。Cetus：一种在非常规语言语境下的验证细节问题，此前已有数家公司遇到过类似情况，其中大部分被利用的资金后来被冻结并转入赔偿基金。Euler：跨功能的逻辑耦合，每个功能在局部看来都是正确的。 Curve：源代码下方的层级。除此之外，还有源源不断的小型事件：来自审核后发布的升级版本，来自尽管合约无懈可击但管理密钥却被随意处理的情况，以及来自协议与代币和市场交互时其模型从未预想到的场景。

此外还存在稀缺性带来的经济因素：顶级审核能力既有限又昂贵，因此项目往往仅进行一次审计就发布代码——尽管风险本应需要三次审计——或者仅采用一家因周转时间快而被选中的公司提供的营销级审核。审计徽章将所有这些差异浓缩为一个词，这就是为什么精明的资金分配者会阅读报告、核对提交哈希值与实际部署内容是否一致，并将未经审计的协议升级视为未经审计的代码。

Chart comparing smart contract exploits at sixty percent of incidents with a small share of losses against infrastructure and key compromises at fifteen percent of incidents and seventy-six percent of value, per TRM Labs — 图2. 2026年上半年：按攻击类型划分的事件占比与价值占比。

除了审计之外，一套完善的安全体系应该是什么样子的？

快速解答

分层架构且预设故障：多重独立审查、在关键环节应用形式化方法和模糊测试、持续监控、经济断路器、定时锁定变更、漏洞赏金计划，以及针对漏洞突破时的演练方案。每一层都能捕获不同的遗漏模式，这正是分层架构的核心意义。

冗余审查可填补审查者造成的漏洞：不同公司、不同方法、不同盲点，再加上竞赛平台——让数百名独立研究人员共同审查同一段代码。形式化验证通过数学模型证明特定属性、守恒性及访问不变量；其局限在于仅能验证那些被明确表述的属性。模糊测试和不变量测试能机械地遍历状态空间，在“Cetus”级别的验证边界上表现尤为出色；由于成本足够低廉，如今若缺失这些措施反而会成为风险信号。

漏洞赏金计划正在改变市场格局：一项针对风险价值设定合理金额的长期赏金计划，能为发现漏洞的研究人员提供与犯罪收益相当的合法回报。最大的 DeFi 赏金计划已支付数百万，而其成本却微乎其微。

运行时防御机制承认，预防措施在部署后即告终结。监控机制会观察内存池和状态以识别攻击模式；断路器会限制每个区块的资金流出额度，或在发现异常时暂停操作；升级和参数变更的时间锁机制，让世界有数天时间审查治理机构批准的内容，确保其在生效前经过审查，从而将隐蔽的变更转化为公开的变更。速率限制将总资金流出转化为部分流出，这与本学院托管文章中贯穿始终的“有限影响范围”理念如出一辙。

而且，鉴于损失数据显示运营风险现已超过代码风险：管理合约的密钥理应具备合约级别的严谨性。分布式签名权限、法定人数批准、在独立设备上进行明确签名，且任何单一操作员均无法单独升级金库合约。Bybit事件始终提醒我们：通过可被腐败的工作流管理的完美合约，本质上是一个带有后门的完美合约。

对于用户或资金分配者而言，检查清单可归纳为以下问题：已部署的提交需经过多少次独立审查；管理密钥在何种延迟和何种法定人数条件下能执行哪些操作；什么会从经济角度破坏协议，团队是否公布了相关分析；悬赏金额是多少；暂停计划是什么。在公开文档中回答这些问题的协议，是在向你展示其安全文化；而仅以认证标识作为回答的协议，同样在向你传递某种信息。

专家应该如何阅读审计报告？

简短回答：倒着读：先看范围和假设，其次是未解决的问题，第三是已部署提交的匹配情况，营销摘要若有的话放在最后。报告是流程质量的证据，将其视为“未涵盖内容”的地图来阅读最为有效。

从范围入手。涉及哪些合约、哪个提交、排除了哪些内容，以及部署的字节码是否与审查过的代码对应；区块浏览器使验证变得切实可行，且不匹配的情况足够常见，值得常规检查。对提交 A 的审计不会涉及提交 B。

将假设视为攻击面清单来阅读。“我们假设管理员是诚实的”意味着管理员密钥被泄露是您需要评估的风险。“Oracle 的行为不在审查范围内”意味着 Mango 模式未被审查。每一个明确的假设都是审查停止的边界，而边界正是攻击者伺机而动的地点。

评估发现时，应更侧重于响应情况，而非数量。一份包含十几个已解决高危问题的报告可能反映出团队积极投入且审核人员细致严谨；而一份“干净”的报告则可能只是流于表面。真正令人担忧的情况是：问题虽已确认，却仍被直接发布，或者以审计人员从未重新审核过的方式进行修复。请确认是否对修复方案进行了重新审计；修复引入的新漏洞是一种常见现象。

最后，要将报告置于时间维度中考量。报告有多旧？此后发布了多少次升级？该协议的变更日志是否遵循“已变更的代码即未经过审计的代码”这一原则？对于处于积极开发中的协议，真正有意义的是安全管道——每次发布都进行审查、设立常设赏金计划、持续监控——而非任何单一文档。一份数年前的强有力报告不过是历史遗留物，而历史遗留物无法保障运行中的系统安全。

严谨的总结：审计是必要的、有参考价值的，但并不充分，而委托进行审计的专业人士也会持同样观点。审计的真正成果是降低未知风险，而未知风险只能被管理，永远无法彻底消除。

常见问题

经过审计的协议使用起来安全吗？

更安全，但存在较大的误差范围。审计降低了已知漏洞类别在受审查代码中残留的可能性。它未能涵盖经济设计、预言机、升级、运维以及未被发现的漏洞类别，而最近的损失数据显示，目前大部分被盗资产正是通过这些漏洞流出的。请将审计视为与管理员密钥策略、时间锁、赏金额度、监控和过往记录并列的参考因素之一。

为什么不一直审计直到再也找不到漏洞为止？

因为审核是在预算限制下对一个实际上无限的搜索空间进行抽样检查，而攻击者则会针对实时状态进行无限期的搜索。增加审查虽能降低残余风险，但边际效益递减；残余风险无法降至零，且审计在结构上无法察觉的漏洞类别——如未来变更、新兴的可组合性、受损的操作员——也不会因增加审查工时而减少。这就是为什么成熟的系统会将边际资源投入到赏金计划、模糊测试、监控和影响范围限制上，而不是进行第五次完全相同的审计。

审计与形式验证有何区别？

审计是专家审查：由人和工具共同排查问题。形式验证则是通过数学证明，验证代码在特定模型下是否满足明确陈述的属性。形式验证在其适用范围内更为强大，但其有效性完全取决于属性和模型的准确性；如果合同中包含未明确陈述的属性，或者规格说明有误，即使经过形式验证被证明正确，该合同在形式上仍会被判定为失败。最强大的安全流程会在最重要的组件上同时采用这两种方法。

漏洞赏金计划真的有效吗？

其激励逻辑是合理的，且实际记录也印证了这一点：主要平台曾为关键发现支付了数百万的赏金，而这些发现若未被发现，本会让协议在实际运行中蒙受数亿的损失。赏金计划的可信度比其宣传口号更重要：范围明确、快速分拣、支付可靠，且没有拖欠研究人员的记录。一个资金不足或具有敌意的赏金计划甚至比没有计划更糟糕，因为它会促使研究人员转而向其他地方出售漏洞。

作为用户，判断协议安全文化的最佳指标是什么？

观察权力的运作方式：管理员密钥能做什么、由谁持有、受何种时间锁和法定人数机制约束，以及这些是否已公开记录。那些通过公开自我约束、延迟升级、分布式签名、发布经济分析以及设立有资金保障的漏洞赏金计划来展现自身团队的团队，正在向你展示其文化。页面上的徽章数量是信息量最少的数字。