DeFi应用如何抵挡黑客攻击？

第一步，快速定位威胁情况和攻击细节，这样可以快速给出最正确的漏洞原因，比如这次事件中，本质问题是 Lendf.Me 的核心代码中存在重入攻击漏洞，而这个漏洞又需要结合基于 ERC777 代币的组合才能发生。知道漏洞本质及攻击手法后，在链上是很容易知道攻击者具体盗走多少资产。

第二步，思考如何追回。在4月19日下午，dForce、星火与 imToken 安全团队在线下集结，并与慢雾安全团队远程连线成立“临时安全团队”，开始进行资产追回。因为信息量巨大且杂乱，集中讨论可以快速的信息对称，加快速度imtoken钱包官网。

4月20日，基于黑客在攻击前后留下的痕迹，“临时安全团队”成功确定了准确的黑客画像，并开始与国内外各方资源进行交叉对比，获得突破性线索，离黑客越来越近。4 月 21 日下午，在黄金48小时内，黑客在重重压力下，与 dForce 主动沟通，并开始归还部分资产。继续沟通后，所有资产被成功找回，这是攻击发生后的第三天。这个过程不仅是“临时安全团队”发挥了关键作用，还得到了非常多加密社区朋友直接与间接的帮助。

刘锋：对于这次 Lendf.me 被攻击事件，大家应该吸取什么教训？

余弦：任何新事物在进化过程中都会有安全风险，这是进化法则，越早期这种风险越大，最终要么死亡，要么就会趋于某种比较稳定的平衡。

基于这种心理准备，我们来看 DeFi，有几个比较重要的风险：技术安全风险、业务安全风险、合规安全风险，我们简单展开（以以太坊为例）：

1. 技术安全

首先看公链本身是否久经考验，足够安全，以太坊基本满足这点；然后看智能合约的设计是否足够安全，Solidity 并不太满足；再看相关的标准（如 ERC20, 223, 721, 777 等等）实现是否足够安全，这里最大的问题在于很多时候一个“特性”会变成一种“缺陷”；再看基于标准的成熟框架是否安全，如 OpenZeppelin 就很优秀；最后看项目方开发出来的是否真的严格安全实践，这个就非常不好说了，很明显，开发的质量是参差不齐的。

2. 业务安全

业务决定于 DeFi 的设计，比如抵押借贷、闪贷、交易等等。业务需要特别考虑的是安全风控，比如暴跌暴涨怎么办？突然出现的大额转币如何处理？如何解决第三方安全风险（如：接入第三方代币、和第三方联动等）？

3. 合规安全

如果是一个灰色或黑色边界的 DeFi，一不小心被一些国家的执法机构打掉或自己跑路了，怎么办？

另外特别补充一些和用户角度有关的判断：

1. 项目方内部有实力不错的安全团队或有丰富安全经验的核心人物把关

2. 项目方近半年内被第三方专业安全机构安全审计并公开安全审计结果

3. 项目方有长期持续紧密合作的第三方专业安全机构

4. 项目方核心成员对待安全的态度坦然开放，勇于认错并把安全放在第一位

5. 项目方对安全工作充满敬畏与尊重

基于上面这5点可以延伸出一些事实，比如：口碑、真实用户数、数据透明度、安全透明度等等。