O3swap被黑，你所看到的合约审计报告真的可信么？

Defi 世界里我们都知道智能合约的代码安全性是非常重要的，这也关系到项目的成败，因此在去年defi火热之后，大量defi项目方纷纷都将自己的代码交给第三方审计机构，以确保项目不出现漏洞，当然一部分项目方也因此招揽用户，审计机构在这次的牛市中赚得盆满钵满。
但是随着行情日益分化，一些defi项目频频出现资产被黑客盗走的现象，而随着近年行情的下调，这种情况愈演愈烈，远的不说，在最近一两月内，就接连发生多起规模庞大的defi项目被黑事件，它们分别是：
1、8月10号，o3swap资金被盗2、8月4日，Sorbetto Fragola遭到攻击，造成损失3、8月2日，加密指数协议Levyathan遭到攻击，造成损失4、7月16日，THORChain遭受攻击，造成损失5、7月12日，anyswap遭到攻击，私钥被黑客推算出来，资产被盗，造成损失6、7月3日，RAI Finance因ChainSwap合约漏洞，资产被盗，造成损失
令人触目惊心的是这样的攻击和被黑事件几乎每个月都会发生，DEFI俨然成为黑客的提款机。
那么审计机构不是之前已经审计完成了么，为什么defi项目的漏洞问题还是有增无减？审计机构的报告到底有没有意义成为很多人关注的话题。

审计报告一般都审计什么对于项目的第三方审计而言，很多人认为审计的作用就是将项目所有的代码都审计一遍，保证代码没有漏洞。其实这种想法是错误的，第三方审计机构其实主要审计的是链上智能合约的代码，对于不在区块链上部署的代码比如网页前端代码之类的是不进行审计的。
我们以灵踪为例，在他们在某项目的审计报告里明确指出，审计的文件都是sol为后缀名的solidity智能合约代码，而对于网页前端部署代码是没有进行审计的，也就是说，如果用户因为网页显示问题而导致合约执行错误，这部分锅并不由审计机构背。

换句话说，用户在执行defi项目的合约时，需要在区块浏览器上查看自己的钱包是否和审计报告中规定的合约进行交互，如果有，那么项目方是正常部署合约和网页前端，如果没有，那就说明项目方提交给审计机构的代码没有问题，但是实际给用户使用的是另一套有问题的代码，那么这个时候就可以得出结论，项目方故意想要坑钱跑路。
当然我们前面也说到，区块链上智能合约的代码安全性可以通过审计机构审计，但是用户使用前端的网页代码没有进行审计，因此从理论上来讲，即使审计代码通过了，用户在使用DEFI产品的时候仍然会有一定概率出现问题。
审计报告的缺陷1、代码第三方审计的滞后性对于区块链项目代码尤其是智能合约代码来说，其实审计是一个比较学习和完善的过程，区块链项目大部分技术都是新兴技术，而且创新性也比较高，因此对于审计机构来说，今天审计没问题并不代表以后就一直没有问题，只能说在当时的条件下，代码审计机构没有发现之前已经被市场证实的漏洞出现在本次被审计的项目中。也就是说，审计报告有一定的滞后性。
比如去年大部分被攻击的项目都是swap类项目，而最近一段时间里出现问题的项目普遍是跨链类项目，比如o3、ploynetwork、THORChain和anyswap等，实际上，这在一定程度上来说，代码的创新性越高，其漏洞的可能性也越高，市场中审计机构也就会遇到各种各样被黑客攻击的案例，从而为以后审计代码提供参考。

2、审计机构参差不齐导致出现遗漏不可否认的是本次牛市使得代码审计机构的工作任务出现大幅上升，也就是我们说的过饱和现象，而对于审计机构来说，人员数量和精力是一定的，因此一部分审计机构为了方便起见，对审计流程做了高度流程化，比如先看哪些，后看哪些，注意有没有出现某些漏洞，而不是通过审计流程+同行评审等方式来进行，这样的好处是能够提高审计效率，使得审计机构能够在短时间内完成大量项目的审计工作，而问题就是就会造成只看到会不会出现某些漏洞，而对于其他方向的漏洞没有研究或者没有考虑到，这样一些名气并不太好的审计机构出现这种问题的概率更大。

某项目的审计结果，基本都是按照模板来进行审计，没有一定的灵活性
当然对于这种方式，一般有实力的defi项目方都会请两到三个审计机构进行代码审计，最后公布在项目官网上，以期待能够提高知名度。目前多个审计机构进行代码审计确实能够降低一部分代码漏洞的风险，但是仍然有大量DEFI项目并没有这样做，或者都选择多个不知名审计机构进行审计，以给用户一种多个机构审计完成，项目安全性高的错觉。
投资者对审计报告的盲目崇拜审计报告虽然对项目来说，有一定作用的，但是另外一点比较关键的是投资者对审计报告的崇拜，而不是认真研究审计报告，从而造成某种误区。
我们以某defi项目为例：
一般审计结果会给出代码的风险等级，比如下图：

这里审计报告并没有直接说该合约是否存在问题，而是以风险数量为标准，有的defi项目更简单点直接会说明高风险和中风险的数量，故意忽略低风险，因为这里低风险代码有时候是项目方自己设定的，比如：

审计机构在判定结果为所有风险皆为0的情况下，却给出了增强建议，也就是一个合约文件的某个参数可被修改，经过项目方的反馈之后，审计机构认为这种情况合理，到底是否正常，这一点有待商榷。
另外一点就是审计的过程其实是项目方改作业的过程，一般来说，项目方将代码提交给审计机构之后，审计机构在审计完成后对有问题的代码进行标识出来，然后项目方进行修改，审计机构对修改后的代码进行确认，这样就完成了审计过程，比如o3的某个代码问题：

这里会出现一个错误，而最终的结果是fixed

类似的情况还有很多，比如下图

也就是说，项目方的漏洞被审计机构发现之后，项目方会按照要求进行修改，但是对于投资者而言，如果审计机构没有发现的漏洞呢？项目方会进行反复自查么？这里除了项目方自己，没有人能知道。
结语网上曾经有一个段子，说的是程序员甲担心自己的代码出现bug，乙问能不能跑，甲反问是代码能跑还是人能跑，乙回答只要有一个能跑就行。这也在一定程度上说明对于快速搭建项目之下代码的质量堪忧，很多项目方其实并不是特别关心，代码能用和代码安全实际上是两个事情。从去年牛市到现在，实际上有很多项目方都是抄袭的代码或买其他项目全套代码，修修改改之后就能直接运行，那么这种氛围之下，DEFI频繁出现被盗的问题也就能够得到很好的解释了。

https://www.cybtc.com/forum.php?mod=viewthread&tid=81565