业务逻辑漏洞在 DeFi 项目中最为常见， 需对涉及代币基本信息的函数及铸币、销毁代币、更改 owner 等特殊权限作严格审查。

原文标题：《DeFi 合约审计中的那些「套路」》
撰文：成都链安

DeFi 项目正式部署前，通过合约的安全审计，不仅可以对项目的代码规范、漏洞情况以及业务逻辑等方面进行全局核查。同时，项目审计对于项目方在投资市场的形象也具有一定塑造作用。

市场投资者在遴选项目时，如有项目方加持合约审计经历，并对审计方、审计报告等信息进行公开披露，投资可信度无疑会大幅提高。并且，项目方完善的安全立场建设意识，在无形中也将赋予项目额外的价值。

与此同时，DeFi 项目方在运营过程中，保持与安全审计公司的长期业务合作，不论是对安全管理还是业务扩展都将大有裨益。毕竟，在项目长期发展过程中，阶段性安全审计机制能够及时发现和有效助力解决整体、局部的风险问题。

那么，DeFi 合约审计的主要流程、内容以及特点，那些「套路」又是什么呢？

套路 1：前期「把脉」

与 DeFi 项目方的合约审计合作关系达成后，在了解项目整体情况，包括构架、业务设计等方面的基础上，指派具有相关项目审计经验的安全测试团队进行专项服务，同时，明确项目检测范围以及相应需求侧重点。做好前期「把脉」，其主要内容包括：

1. DeFi 项目方提供真实、有效且为审计所需的各项技术、代码、文档等资料。
2. 正式进入检测环节前，安全团队将对提供的材料进行全面评估，以确定周期。
3. 确定测试服务范围，包括定向模块、局部代码、全面安全审计等。
   4、. 完成相关需求对接，即对源代码、应用程序、文件信息、测试环境的最终确认。

为了对 DeFi 项目合约的代码规范性、安全性以及业务逻辑等方面进行严格的安全审计，在测试明确后，处理合约审计的常规方式有：

• 形式化验证
• 静态分析
• 动态分析
• 典型案例
• 人工审核

套路 2：形式化验证

形式化方法是实现安全、可信软件的最可靠的手段，它利用基于数学的符号系统给出软件正确性、安全性的严格定义和形式证明。其中，严格定义被称为形式化规范，是一种用清晰、简明的手段来刻画软件功能或特性的逻辑表达式。

在合约审计中，形式化方法通过的是定性需求属性，从而证明程序不存在某类安全漏洞。另一方面，传统测试方法则是通过检查代码在一组选定的输入上是否按照预期运行，以此说明程序是否存在安全漏洞，但这无法证明同类型安全漏洞不存在。

此外，传统测试方法很容易漏掉在罕见或恶意构造场景下触发的错误，以及由于大量「不可能事件」连续发生导致的错误。然而，形式化方法则可通过明确代码意图、提供输入空间的完整覆盖来发现上述微妙错误，进而实现程序的安全性、可靠性增强。

传统检测 vs 形式化验证

成都链安创始人、多年形式化验证研究专家杨霞教授表示：

「传统验证手段无法穷尽可能的情况，而形式化验证则可以做到穷举，对智能合约漏洞检测而言，该方法最为可信和有效。

作为针对以太坊智能合约安全检测开发的定制化工具，成都链安的 Beosin-VaaS 一键式智能合约自动形式化验证工具，可精确定位到含有风险的代码位置并指出风险原因，有效检测智能合约常规安全漏洞的精确度高达 97% 以上，为智能合约代码提供‘军事级’的安全验证。」

套路 3：代码规范审计

在代码规范审计中，主要测试项目有：

编译器的版本问题可能会导致各种已知安全问题，开发者应在代码中指定合约代码采用最新的编译器版本，并消除编译器告警。

同时，Solidity 智能合约开发语言处于快速迭代中，部分关键字已被新版本的编译器弃用，如 throw、years 等，为消除其可能导致的隐患，当前编译器版本已经弃用的关键字应被禁用。

在智能合约中，冗余代码会降低代码可读性，并可能需要消耗更多的 gas 用于合约部署，因此，必须找出并消除冗余代码。此外，合约中是否正确使用 SafeMath 库内的函数进行数学运算需要严格检查。

Solidity 使用状态恢复异常来处理错误，该机制将会撤消对当前调用及其所有子调用中的状态所做的所有更改，并向调用者标记错误。

函数 assert 和 require 可用于检查条件并在条件不满足时抛出异常。assert 函数只能用于测试内部错误，并检查非变量。require 函数用于确认条件有效性，例如输入变量，或合约状态变量是否满足条件，或验证外部合约调用的返回值。

以太坊虚拟机执行合约代码需要消耗 gas，当 gas 不足时，代码执行会抛出 out of gas 异常，并撤销所有状态变更。合约开发者需要控制代码的 gas 消耗，避免因为 gas 不足导致函数执行一直失败。

另外，合约函数的可见性是否符合设计要求，以及在当前合约中是否正确使用了 fallback 函数都需要进行严格检查。

套路 4：DeFi 安全漏洞审计

目前，业务逻辑漏洞在 DeFi 项目中最为常见。由于项目业务逻辑设计的不严谨，极可能导致项目在特定情况下出现内部失衡。

需要注意的是，DeFi 项目基于区块链智能合约开发，具有很多传统金融体系以外的特性，比如：

• 单笔交易可发起多个内部交易，失败可回滚
• 具有通缩性质的代币
• 合约代码不可修改

同时，审计中常见的还有合约权限错误，即合约中函数的可见性修饰错误。通常，这是由于调用者和参数没有进行有效验证，导致函数被恶意用户调用，从而酿成巨大的损失。

类似传统安全问题，错误的权限配置和无效的安全检查都会给系统带来巨大的风险。但不同的是，智能合约的不可修改性使得此类问题即便被发现也不一定能得到有效修复。

另外，重入漏洞也是审计的重点。具体而言，当合约向外发起 call 调用后，攻击者可利用合约调用的特性反复调用函数，导致合约预期的执行顺序发生错误，以此窃取目标账户的资产。

在审计中，代码错误出现频率也很高。这主要是由于开发人员失误导致的一些代码编写错误。常见的有单位错误、忘记乘以精度、& 使用错误等。在 YAM 漏洞事件中，代码在进行弹性调整 rebase 时，其代码正是忘记乘以精度，如图所示：

在确保代码和漏洞深度检测的同时，项目业务方面也设置有业务逻辑和实现方面的相关审计，包括对 DeFi 项目中涉及代币基本信息的检查，以及代币标准相关的函数的确认，特别是对铸币、销毁代币、更改 owner 及其它特殊权限的审查和风险分析。

很多项目中都存在代理转账的逻辑，在处理此类逻辑时，很多项目方会直接要求用户授权最大值代币给项目方的合约，如下图所示：

如此一来，合约就有权将用户资金全部转走。此外，还有双重授权的问题，项目方网站在进行授权时，发起了两笔授权，一笔授权给合约地址，一笔授权给外部地址，如用户对此没有提防，将会面临极大的资金风险。

套路 5：审计报告

合约审计最终服务于 DeFi 项目中的资金安全，而这方面诸多问题的出现都与函数、算法的不当存在关联。因此，合约审计就是要指出可能引发资金风险的内容，也就是潜藏隐患以及亟需修正的代码、漏洞、逻辑等问题。

在审计报告中，除了审计时间、历时以及审计人等基本信息外，还会体现对项目的投资预警提示。审计报告的核心内容，是体现受检智能合约在设计和代码实现等多方面、多维度的审计结果。同时，报告将指出发现的各类风险问题，并将其告知项目方以便修复。

通过审计报告，合约的风险成分，包括潜在可遭遇的攻击，不同级别、层面的漏洞将被详尽提示。只不过，安全审计报告中醒目的「通过」二字，不应该作为投资者仅有的投资判断依据。

结语

合约审计并不属于项目本身的利好消息，而是上线前必要的一项安全工作，无论是对项目方还是投资者都具有重大的意义。

投机市场或是狂暴或是萧条，行走其间不按套路出牌，终将也会受制于「套路」。略瞥其中，唯有防患于未然的安全之峰，巍然。