“我们不时会遇到麻烦和灾难，但我们不能期望逃离生命中的灰暗时期——因为以辉煌和金色为落日的生命不是常有的。—— 西奥多·罗斯福”
DeFi 变身“黑客提款机”
2020 年，整个世界都仿佛开启了 Hard 模式 ，不管身处何种行业，我们每个人都或多或少的受到了影响。本就树欲静而风不止的区块链行业更是可以用一波未平，一波又起来形容：
· 2 月 15 日，贷款协议 bZx 被黑客通过操纵预言机价格导致约 35 万美元的损失；
· 3 月 12 日，恶意的“零出价拍卖”导致 MakerDao 500 多万美元的不良债务;
· 4 月 18 日，Uniswap 遭受重入攻击导致 1278 枚 ETH 的损失；
· 4 月 19 日，中国最大的 DeFi 平台 Lendf.me 被黑客盗取价值超过 2500 万美元的资产……
此起彼伏的攻击事件，让很多人蒙受财产损失，以至于对 DeFi 甚至区块链都失去了信心。有人笑称现在的 DeFi 平台压根就是“黑客提款机”……
回顾 2020 年的“每月一殇”，初露锋芒的 DeFi 就像不停推巨石上山的西西弗斯，周而复始的无用功仿佛是去中心化和中心化博弈的轮回。每当巨石滚落，都会迎来阵阵哂笑。打着“Code is law” 旗号的去中心化，却始终无法保证“Code is safe”。一连串的事件中，我们既看到了雪中送炭，也看到了落井下石。面对嘈杂的声音依然“在路上”我们想对同路人说：“路漫漫其修远兮，同志们仍需努力。”
重入攻击是怎么回事儿？
4 月 18、19 日接连两天的黑客攻击都使用了同一种攻击方式——重入攻击。这个近期频频刷屏我们朋友圈的攻击到底是什么呢？
众所周知，以太坊上的智能合约之间是可以相互调用的，这种调用使得多个合约可以配合实现复杂的逻辑和丰富的功能。但在错误或恶意的操作下，在合约对其它合约调用的执行过程中回调原合约，则很可能会突破原本设计的业务逻辑，让合约执行一些“不正常”的操作。「合约回调原合约」，听上去很是拗口，但这正是重入攻击的核心——通过回调原合约上的某一个函数，在原合约没有预期的情况下，重新进入原合约代码并再次执行合约。因为设计时往往不会考虑这种骚操作，所以第二次进入原合约后修改的数据可能会逃过第一层合约逻辑的检查。对于支持交易和记账功能的合约来说，逃过检查的数据就可能绕过交易逻辑影响最终的结算。
具体到两次攻击事件，都是利用回调函数进行重入攻击，仅在具体实施方式上有所区别。在 Uniswap 事件中，攻击者通过改变余额变更顺序进而操纵交易汇率牟利。而在 Lendf.me 事件中，攻击者在合约缓存了第一次交易变更结果后又进行多次转账，致使合约后续的更改都被第一次交易缓存结果覆盖，实现了一次付款多次提现。
这个锅，ERC-777 不背
伴随着 Lendf.me 事件的持续发酵，“ERC-777”、“重入攻击”、“中国DeFi” 等关键词被推上风口浪尖。尤其是 4 月 18、19 日接连的两次黑客攻击，都是以使用 ERC-777 代币标准的 imBTC 为切入点，通过重入攻击实现的。那么这个锅是不是应该由 ERC-777 来背呢？重入攻击又是否可以避免呢？
众所周知，在 ERC-20 标准下，智能合约收到 ERC-20 代币时不会在链上得到任何通知，因此也无法即时响应。所以，如果用户需要和智能合约进行 ERC-20 代币转账等交互时（如使用 DeFi 产品借贷），通常要进行两笔交易：先授权（approve），调用代币合约的 approve 方法赋予目标合约转移用户部分资产的能力；再转币（transferFrom），由目标合约调用代币合约的 transferFrom 方法完成转账。
每次交互都进行「两步」操作的方式对用户很不友好，所以大部分 DeFi 都会为了用户体验而在用户授权时一次设置较大的资产额度（就像我们使用 DeFi 平台时只需授权一次，后续可直接进行借贷交易）。如果 DeFi 合约出现漏洞或合约管理员作恶的话，之前授权的资产额度越大则用户的损失也会越大。所以说，ERC-20 标准催生的“过度授权”的使用习惯增加了用户资产的安全风险。
ERC-777 是于 2017 年发布的以太坊链上代币标准协议，并且向后兼容 ERC-20 标准。ERC-777 对智能合约的转账交互逻辑做了大幅优化：通过 callback 回调函数，可使智能合约收到 ERC-777 代币转账时在链上立刻获得通知，并即时做出反应。这样，用户直接通过代币合约转账即可，无需提前授权给目标合约，降低了过度授权带来的隐患。同时 ERC-777 标准也减少了用户的操作步骤，把 ERC-20 标准下必须两步甚至多步才能完成的操作直接变成了一步，让用户体验变得更好。
与 ERC-20 相比，ERC-777 明显对用户更加友好。但是近期的攻击事件使很多人对 ERC-777 标准的安全性产生了质疑，甚至把锅全都甩给 ERC-777，觉得如果没有 ERC-777，就不会有类似的攻击事件。
但是，这个锅不该 ERC-777 背。
首先，以太坊上的重入攻击是没法完全避免的，而进行重入攻击的手段有很多种，ERC-777 并不是导致重入攻击的唯一原因。例如在 2016 年以太坊上 the DAO 事件中，黑客利用 payable fallback 回退函数进行重入攻击，导致了价值约 6 千万美元的以太币被盗。此事件促使以太坊硬分叉为以太坊 ETH 和以太经典 ETC 两条链。
其次，合约开发者应该有意识地做好重入攻击的保护。近期发生的攻击事件中，都是由于 DeFi 合约本身在支持 ERC-777 代币的同时，忽视了在使用 callback 回调函数的情况下添加“重入锁”的重要性。黑客是利用合约安全管理的漏洞而非 ERC-777 的漏洞实行攻击。而 callback 回调函数的设计有利于提升用户体验，对整个区块链的发展和进步利大于弊，不应成为 DeFi 合约出现漏洞并遭到攻击的借口。
如何把提款机变成保险箱？
关于智能合约调用的重入机制带来攻击风险的问题，Conflux 有自己的权衡：现阶段重入机制带来的安全风险要远远多于它带来的便利，可谓是弊大于利，因此 Conflux 将在虚拟机层面禁止“重入”行为。Conflux 上的合约将对重入攻击免疫，但也无法实现有关于“重入”的功能。此外，考虑到未来仍有可能重新开放重入机制，Conflux 建议所有开发者在重要业务的合约代码中都加入“重入锁”，确保在执行过程中禁止重入调用，从根本上避免重入攻击的可能性。
除了重入攻击，黑客攻击的方式还有很多种。Conflux 提倡 DeFi 产品的生态服务方在合约代码层加强风险管理的同时，都能加强在链下进行实时动态监督。通过完善监控程序，保证在恶意攻击行为发生时第一时间捕捉、通知并关停相关服务，做到尽可能减小用户的资产安全风险。
DeFi 产品的开发者无疑是保障 DeFi 合约安全的第一责任人。但是，依靠各自为战的开发者来维护 DeFi 生态的安全是不现实的。传统计算机软件领域已经有无数案例告诉我们绝对安全没有漏洞的程序有多罕见，而软件升级增加新功能的时候往往也是最容易引入新的漏洞的时候。DeFi 生态要发展就不可避免地会引入新的功能和新的标准，正如 ERC-20 到 ERC-777 一样。此时如果开发者不熟悉这些新功能和新特性，就很可能在代码中留下容易遭到黑客攻击的漏洞。
Conflux 将以 CIP 的方式征集提案
我们认为，建设和维护一个健康的 DeFi 生态除了需要吸引开发者和用户以外，还需要建立一个让大家讨论新功能和新标准的平台。这样才能让更多的人参与到生态发展的讨论中来，从不同的视角查漏补缺，达到“众人拾柴火焰高”的效果。例如在 2017 年制订 ERC-777 合约标准的时候，如果当时就有人发现 ERC-777 合约的 callback 回调可能导致重入攻击的风险并广而告之，想必后来的 Uniswap 和 Lendf.me 等 DeFi 产品也不会留下这个漏洞。
为了汇聚社区成员的智慧和技术力量，Conflux 将以 CIP（Conflux Improvement Proposal）的方式征集改进 Conflux 区块链系统的提案。改进提案可以是对于系统设计或者代码实现等方面的，也可以是新的 API/RPC 接口或者新的合约和钱包标准等。比如一个改进提案中可以提出一种比 ERC-777 更方便更安全的代币标准协议，或者讨论对于重入机制的现实需求和重新开放重入机制的意义等。我们希望通过这种方式让社区成员一起参与讨论，从各个角度全方位地评估将来 Conflux 上的每一项升级和改动，并帮助社区的开发者更深入地理解新功能的特性和使用不当时可能存在的风险，从源头上堵住产品的漏洞。
写在最后
最终，在 dForce 团队的努力和沟通下，攻击 Lendf.me 的黑客已经归还了所盗资产，整个事态也趋于平静。其实不管是旁观者，还是从业者，我们既不应该盲目乐观，但也大可不必过分悲观，更不应该去嘲笑失败者。十年前，电子商务刚刚兴起的时候，京东曾受到大规模攻击导致数据外泄，淘宝同期也因受到攻击导致近 2400 万用户资料泄露，但是它们不仅没有被击倒，反而成长得更加强大。
机遇永远与风险并存。沉溺于安全区固然不会有风险，但同时也会失去未来的可能性。就像吴晓波在《大败局》中提到的，在今天的商业世界中，企业失败率最高的地方是美国硅谷，而那里也正是全球商业创新的心脏。
诞生短短两年的 DeFi 仍脆弱如襁褓中的婴儿，需要精心呵护的同时也拥有着无限可能的未来。我们坚信，只要整个行业携手前行，即便 DeFi 成长的道路上荆棘遍布，我们亦可毫无惧色甘之如饴。道阻且长，行则将至；行而不辍，未来可期！
——————————
Vessenes, Peter (18 June 2016). “Deconstructing theDAO Attack: A Brief Code Tour”