图1: burnFrom()函数
图1中burnFrom函数受到ownerOnly修饰词限制，只允许项目管理者执行该函数。该函数内部逻辑实现允许通过设置account, balance和subtractValue的值，间接对_totalSupply和给定账户的_balances值进行任意修改。
PowerPool.Finance (CVP)
图5：Management智能合约接口与getFee函数接口
图6：当前manager变量存储的地址值
图7：当前manager变量存储的地址值指向的智能合约
大家都知道2020年最知名的一个例子——DeFi项目Yam于北京时间8月12日3:00启动后，尽管该项目的博客文章警告称尚未对其合约进行任何审计，但疯狂的Yield farmers在不到一小时内向该项目存入了7600万美元。
后期不出意料，Yam在短短36小时内，数亿美元因为一个小小的漏洞，消失于无形。
安全审计现在已经是高质量DeFi项目的标配。当前DeFi项目热潮持续不减，很多项目为了抓住热点与机遇，在未经严格测试和审计的情况下便匆忙上线。
这些项目中，大部分的漏洞是无法通过常见的测试方法和工具来发现的。只有寻找专业的审计专家进行严谨的数学模型证明，才可以发现该漏洞。形式化验证是当前唯一被证明可以产生可信数学证明的软件验证方法。
因此，采用基于形式化验证方法的区块链检测工具来验证项目中的安全漏洞，应成为每一个项目在上链前的必经步骤。
每一个项目受到攻击或是损失资产的原因，都是因为一个非常小的代码漏洞。
计算机领域中，平均每1000行代码中，会有1-25个bug。也就是说，这个概率的区间是千分之一（0.1%）至百分之二点五（2.5%）。
那么那些已经接受安全审计并通过的项目呢？
CertiK选取了三家公开审计信息的安全公司进行了数据统计。
此次统计了这三家公司的共计377个被审计的项目（包括重复审计项目）。
其中有8个项目在至少被审计过一次的情况下，仍旧遭受到了黑客攻击。
这8个已审计却被攻击的项目，整整损失了6900万美元。
根据此三家审计公司的数据来计算审计后被黑客攻击的比例是：8/377 = 2.12%
代码产生bug的几率和项目已通过审计但仍旧被攻击的概率大抵都约等于2%，在这里举个简单的例子：
根据SquareTrade数据统计显示——在美国，短短一小时内就有5761个手机屏幕壮烈牺牲。假设，美国人均一部手机，并且没有重复摔同一部手机的癖好。那么50天内，一位美国小伙儿有2%的几率把手机屏幕摔碎。
但是一部手机的使用寿命肯定不止50天，如果用一年呢？这个概率骤增为15%！使用超过三年半，概率就超过了50%！
这就印证了上文中的墨菲定律——小概率事件的必然性：时间基数够长的情况下，坏事总会轮到你的。
而空难发生的几率是五百万分之一（0.00002%）。
相比之下，代码产生漏洞的概率以及项目已通过审计但仍旧被攻击的概率是空难的整整12.5万倍！
如果在飞机颠簸的时候，你害怕飞机失事，那么不妨用超出10万倍的担心，去保护你的项目。
这么对比过后，你还觉得项目不需要额外的保障吗？
为之于未有，制治于未乱。
除静态审计之外，动态的安全防护更能够防范攻击事件。CertiK开发的动态安全工具：快速扫描——安全预言机——CertiKShield，从预警到实时评测到保险计划，可以全方位为项目方提供安全保障。