最近，随着DeFi火热，以太坊智能合约安全漏洞频发。究竟是什么原因造成的，以及如何更好地防范这些漏洞？
概述
相比于比特币而言，以太坊更易发生安全事故。这主要是因为以太坊虚拟机是图灵完备的，以太坊可实现函数间相互调用、嵌套调用，智能合约间相互调用等各种复杂逻辑。而比特币只实现了基于栈的非图灵完备的虚拟机，并只能通过操作码进行入栈和出栈操作。另外比特币也没有复杂的DApp应用，所以逻辑上简单，故而没有太多空间引发安全漏洞。
以太坊上各种DApp复杂的智能合约逻辑是引发安全漏洞的主因。以太坊智能合约的安全漏洞主要可以分为逻辑问题和合约代码问题两种。
逻辑问题?
最近频繁的“闪电贷”攻击是一个典型的逻辑问题引起的安全漏洞。在各种闪电贷攻击中你可以看到清晰的逻辑问题。攻击者只要制造出两个系统之间的价格差，便能通过闪电贷攻击获利。
以太坊L2网络总锁仓量为48.2亿美元:金色财经消息，L2BEAT数据显示，截至5月22日，以太坊Layer2上总锁仓量为49.5亿美元。其中锁仓量最高的为扩容方案Arbitrum，约20.68亿美元，占比55.69%。其次是dYdX，锁仓量9.51亿美元，占比19.71%。Optimism占据第三，锁仓量4.8亿美元，占比9.97%。[2022/5/22 3:33:35]
闪电贷攻击的逻辑细节大家可以阅读之前一篇专门讲闪电贷的文章：“造富神器”闪电贷。本文主要阐述合约代码问题。
合约代码问题?
我们知道，几乎稍微复杂一点的代码都或多或少地存在问题。了解出现问题的原因，并且归纳问题类别可以帮助我们更好地防范它们。下面是Ownbit钱包团队整理的关于以太坊智能合约安全最容易出现问题的点。
1.重入
这是排名第一的问题。所谓“重入”就是一个方法被多次循环调用。而这通常是合约开发者所意想不到的。例如一个取款合约：
Tether在以太坊网络增发2亿枚USDT（已授权未发行）:金色财经报道，据Whale Alert数据，北京时间11月25日01:25，Tether在以太坊网络增发2亿枚USDT。对此，Tether首席技术官Paolo Ardoino表示，以太坊网络补充了2亿枚USDT的库存。这是一笔已授权但未发行的交易，意味着该金额将用作下一次发行请求的库存。[2020/11/25 22:01:00]
function?withdrawEther()?public?{uint?amount?=?userBalances;bool?success,?)?=?msg
这是一段很简单的取款合约，让用户取走他的ETH余额。开发者并没有意识到这段代码可能会被重入。方法是：只要调用者是一个合约账户，那么msg.sender.call将默认调用该合约账户的fallback函数。攻击者只需要在其fallback函数再次调用withdrawEther就可以源源不断地取走ETH。
数据：以太坊排名前10000的地址拥有9170万枚ETH:Metacartel Ventures合伙人Adam Cochran最近在推特发布其研究结果，涉及对以太坊排名前10000位的地址进行人工审计。前10000个地址拥有9170万枚ETH，前1000个地址拥有约7070万枚ETH，前100个地址拥有3780万枚ETH。前10个地址拥有1660万ETH（约占总供应量的17%）。如果将智能合约持有的代币数量去掉，前10000个地址拥有5720万ETH（约占总供应量的56.7%），前1000个地址拥有4250万ETH，前100个地址拥有2640万ETH。
结果显示，比特币和以太坊分布广泛，真正实现了去中心化，这在某种程度上是其他加密资产无法企及的。例如，比特币前10000名持有者控制57.44%的供应量；以太坊前10000名持有者控制56.7%的供应。相比之下，XRP前16名持有者控制55.2%的供应量，BCH前1100名持有者控制56.8%的供应量，LTC前300名持有者控制54.3%的供应量，TRX前1031名持有者控制51.1%的供应量。（Cryptoticker）[2020/5/31]
发生在2016年6月，著名的TheDAO攻击，从而导致了ETC分叉的事件，就是通过同样的方法实施攻击的。从事后看来，这只是一个小小的程序问题。要修复这个问题也非常容易，只需要将两行代码调换顺序即可：
Pantera Capital创始合伙人：最大遗憾是没有投资以太坊ICO:Pantera Capital创始合伙人Steven Waterhouse近日表示，作为一名风险投资人，他最大的遗憾是没有投资以太坊的ICO。目前，他是去中心化V/PN服务公司Orchid（兰花协议）的首席执行官。当被问及作为风险投资家最大的错误是什么时，Waterhouse的回答是错过了以太坊ICO。他曾有机会投资以太坊的ICO，但他当时与比特币核心团队的密切关系影响了他的判断。（Cointelegraph）[2020/5/14]
????userBalances?=?0;????(bool?success,?)?=?msg.sender.call.value(amount)("");
2.让你的交易不打包
以太坊区块的打包机制是按照给予的矿工费进行优先打包，并且每个区块有总GasLimit的限制。所以攻击者可以制造出若干使用GasLimit非常大，并且GasPrice给得非常高的交易，让它们优先占满区块，从而让目标交易无法被打包。
以太坊微信指数日环比下降16.50%:金色财经报道，微信指数显示，4月4日，区块链搜索指数为676920，日环比下降15.42%；比特币搜索指数为400844，日环比下降5.13%；以太坊搜索指数为27938，日环比下降16.50%。[2020/4/5]
所以，在编写合约逻辑时，不能假设你的交易会在有限时间内被打包，否则就容易受到此类攻击。著名的“Fomo3D”事件就是用了这样的攻击方法。
Fomo3D游戏规则是奖励最后一个购得某个商品的人。每次商品被买入将重置该商品的定时器，如果在定时器达到0之前没有其他购买者，则你将获得系统的奖励。攻击者在Fomo3D中买入商品，然后同时发送大量占用区块的攻击交易，以至于在接下来的13个区块内，其他购买者的交易无法被打包。这时定时器达到0，并认为无其他购买者。攻击者便获得了奖励，完成了攻击。
3.错误使用tx.origin
如果你发现一个合约使用了tx.origin，那么可以留心一下此处可能存在的漏洞。在大部分情况下，我们应该使用msg.sender来替代tx.origin，因为使用tx.origin容易引发安全漏洞。
很多时候，合约开发人员会假定msg.sender和tx.origin是相等的，但其实不是。例如：用户A?调用?合约B，而合约B进一步调用?合约C，那么在合约B和C中tx.origin都将是A，而msg.sender则一个是A，一个是B。
一般攻击者会引诱A调用一个诱导合约B，而B再去调用由A部署的目标合约C，因为合约C错误地使用了tx.origin，合约B可以通过传递过来的tx.origin获得对合约C的控制权，从而完成攻击。
4.溢出攻击
智能合约里的数据是可能溢出的，例如：uint256，你觉得很大：2^256。它的确很大，但依然可以溢出。例如一个合约允许对一个数据进行加减，攻击可以通过对这个数据进行精心策划的调用，让其通过溢出达到允许执行某些逻辑的目的，从而实现攻击。
5.fallback?可以revert
fallback是可以revert的，就是说，你如果向对方转移ether，对方可以让你总是不成功。
例如你编写一段合约，并且依赖于你成功向某个地址转移ether，那么攻击可以部署一个合约，将其fallback写成revert来让你来的调用总是失败：
function?()?public?payable?{???revert?()?;?}
6.?selfdestruct可以定义任意受益者，而不会调用fallback
当你以为可以通过revert进行阻止所有人向你付款ether时，你可能又错了。攻击者通过创建一个合约，并且然后销毁这个合约。销毁合约以太坊将退还一部分ether作为鼓励，而这个退还可以指定任意受益者，而对方的fallback函数不会被调用。
这就是说，开发者要意识到你没有办法完全阻止别人向你的合约账户转移ether。
7.?未正确使用delegatecall
在使用delegatecall时，要注意上下文的变化。用call进行合约调用时，上下文被切换至被调用合约。而用delegatecall进行合约调用时，上下文依然在本合约。
delegatecall和call不同的调用上下文也是合约安全漏洞较常出现的地方。
8.不同方法传气不一样
当我们进行ether转移时，不同的方法传气不一样。使用send()和transfer()?传递气仅为2300，而使用call.value()()?则将剩余的气全部传递。因此，最新的安全规范是建议使用call而不是?send或者transfer进行ether转移。
如果你发现一个合约还是使用send或者transfer，那么你可以制造出目标合约，让其转移OutofGas。
结语
以上这些点是合约代码最常出现问题的点。每个错误的原因都比较原子化，理解相应的原理可以帮助我们有效地避免这些问题。当合约逻辑复杂时，一定会有更加复杂、隐藏得更深的逻辑问题，这时，这些原子点的检查依然可以帮助我们找到它们。
以太坊智能合约的安全问题主要是因为其“过于灵活”引起的。灵活性和安全性如同天平的两端。以太坊选择了灵活性，某种程度上便把安全性的潜在风险留给了市场。
一个DeFi项目能否安全稳定地运行，或是会被黑客攻击，取决于合约开发人员对原理的理解、对细节的把控，以及严肃认真的态度。线上合约犯错的代价是巨大的，这就对合约开发人员提出了更高的要求！
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。