世纪金融网身在新冠日增确诊10万例美国的小编，因为硬核原因不得不搭乘飞机出门。出行前一直担心是否会被感染，途中却被飞机遇到猛烈气流的颠簸唬住了。
虽然心里默默安慰自己飞机空难发生的概率非常低，感染新冠肺炎的概率也没那么高，但还是想起来了四个字：“墨菲定律”
在现代科技发展的大潮流下，锁定在区块链领域里的资产愈发庞大。隐藏在计算机背后的危机也随着区块链的发展日益展露狰狞的面目。
智能合约当中，任何一个小bug，都可能会给项目或者投资者造成无法挽回的损失。
受此警示之下，CertiK安全团队利用CertiK天网系统 （Skynet），对自北京时间2020年12月4日0时至24时之间，新加入Uniswap的代币智能合约进行了监控分析。
在本次分析的时间段内，一共产生了29个智能合约代币项目。
经过CertiK的Skynet分析，总计发现16个智能合约存在漏洞或者缺陷！
大概有55%的智能合约项目或多或少存在漏洞或者缺陷，其中大约有10%存在严重漏洞，45%存在项目拥有者权限过大，权限中心化过高的缺陷。
本次分析的智能合约项目名称和合约地址如下：
分析结果如下：
虽然难以通过一天的情况来预估所有时间范围内的智能合约安全情况，但窥一斑而知全豹。
下面主要针对三个相对重要的漏洞进行分析：
nostromo.finance (NSTR)
图1: burnFrom()函数
图1中burnFrom函数受到ownerOnly修饰词限制，只允许项目管理者执行该函数。该函数内部逻辑实现允许通过设置account, balance和subtractValue的值，间接对_totalSupply和给定账户的_balances值进行任意修改。
PowerPool.Finance (CVP)
图2: powerpoolttl合约中回退函数
图2中为powerpoolttl合约的回退函数。当外部用户对该智能合约进行调用，如果该调用中没有调用合约中的任何一个函数，或者仅仅转移了代币到该合约中，则回退函数会被调用。70行的逻辑显示，当回退函数被调用时，调用中被转移到合同中的代币会被直接转移到teamAddress的地址中。
omphalos.co (OMPL)
该项目中可以通过执行transferFrom()函数进行对代币转移，根据图3中transferFrom()函数定义，211行需要执行getFee函数决定每次代币转移需要扣除的费用。从图3中getFee()函数的定义可以看到，决定费用高低的逻辑是取决与241行调用的Management.getFee()函数的定义。当前Management.getFee()函数的逻辑定义是根据manager变量中存储的地址值的不同而进行改变。当前manager变量中存储的地址值如图6所示。
然而manager变量中存储的地址值所指向的智能合约并未在etherscan上被认证，因此无法得知该智能合约的源代码，继而无从得知Management.getFee()函数的定义。
由于Management.getFee()函数背后的逻辑无法得知，因此项目拥有者有可能通过操作Management.getFee()函数返回值的方式，调整每次代币转移的费用，进行恶意操作等。
图3：transferFrom()函数
图4：StandardToken合约中的getFee()函数
图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，从预警到实时评测到保险计划，可以全方位为项目方提供安全保障。
