作者：咕噜
编者注：原标题为《币乎咕噜踩雷记》
好像全网都知道了我最近踩了lendf.me的雷，既然都知道了，也是好久没写文章，今天跟大家来分享一些思考。
Lendf.me属于Defi范畴，是DeFi中非常流行的抵押借贷类产品，本文主要讲述DeFi类产品的风险识别和规避。
这个世界不存在“无风险收益”，不确定性是这个世界的本质属性，量子力学告诉我们。
巴菲特把10年期美国国债的利率作为无风险利率的近似，用到“未来现金流折现公式”里，这个大概是巴菲特能找到的最接近零风险的回报率了吧。巴菲特心里应该清楚，10年期美国国债的风险不是绝对零，只是风险很小，市场认为美国10年内国债违约的风险接近于零。注意，这里所说无风险，是指在美元本位的前提下的论述，别忘了，美元是在通胀和贬值的。
再举个例子，圈内熟悉的搬砖套利不是无风险的。搬砖通常在2个中心化交易平台之间进行，那么存放在交易平台上的资产承受着交易平台出事的风险。同时，搬砖本身也存在因时间差而被阻击的风险，另外还有中间链路出问题而导致第二笔无法成交或成交延迟的风险。这些风险都是真实存在的，市场上的每个人对这些风险的评估不同，在特定搬砖回报率的条件下，有的人选择参与，有的人不参与。
回到DeFi。不同的DeFi产品，风险各不相同。那就说说抵押借贷类DeFi，参与这类DeFi产品的风险我认为有这些：智能合约代码安全性引入的风险；智能合约AdminKey引入的运营风险；持有特定资产本身的风险；抵押借贷类DeFi本身的市场风险；包括抵押品迅速跌价导致无法及时平仓的风险、某一抵押品抵押数量过多导致市场流动性无法消化的风险，和是紧密关联的；智能合约平台的风险；用户自身私钥管理的风险。
下面一一分析：
智能合约代码安全性引入的风险。
这是目前DeFi应用最主要的风险，我个人认为占了总风险的大多数。智能合约作为管钱的“机器人”，是一段要求不能有Bug的代码。代码中引入Bug通常有2种途径：程序员对需求是理解正确的，但是在写代码的过程中引入bug，导致代码无法100%正确表达需求；程序员对需求的理解有误，或需求本身错了，导致根据此需求写出的代码是错的。严格意义上讲，最近出事的Lendf.me不属于以上任何一种，而是智能合约被超出范围地使用：出事的智能合约不应该纳入ERC777的代币，而imBTC作为ERC777的代币被错误地纳入到了抵押品里，导致智能合约被假币，在智能合约账本内部虚构大量的imBTC作为抵押品，借走智能合约里存放着的所有其它资产。
如何识别和规避风险？
首先，安全审计报告是规避智能合约风险的第一道关口，也是最重要的关口，也是目前唯一能前置规避智能合约风险的措施。我个人不会把资产存放在没有安全审计报告的智能合约里。
其次，时间是最好的检验。经过长时间有效实战检验的智能合约，风险显著降低。多长时间算长？我个人认为至少1年以上。
智能合约AdminKey引入的运营风险。
什么是智能合约的AdminKey？智能合约作为一个提供服务的“机器人”，很多时候运营方需要留有人工的权限去控制这个“机器人”，例如关停“机器人”，再例如冻结智能合约中某个账户的资产，等等。如果存在这样的Admin
Key人工权限，就会引入额外的风险。有的智能合约是没有AdminKey的，例如uniswap，也就是说，运营方没有权限对智能合约做任何干扰，“机器人”是完全自动运行的。
对于有AdminKey权限的智能合约，如何识别和规避风险？
智能合约通常都是代码开源的，但很少有人会去真的查看代码，一个负责任的运营方应该有义务主动披露AdminKey权限。
看AdminKey的权限范围。主要看AdminKey权限是否有权动用用户在智能合约中的资产，以及其它会影响用户资产的权限。例如，如果仅仅是关停智能合约的服务，关停之后用户仍然可以提币，像这种“刹车式”的AdminKey权限属于保护性质，而不是侵入性质。那些可以冻结、转移、没收用户资产的AdminKey权限，需要格外当心。
看是否对AdminKey权限设置了延时生效机制。延时生效机制是防范AdminKey的侵入式权限对用户造成伤害的有效防御手段，同时也是反应运营方态度的关键看点。例如，MYKEY作为一款智能钱包，其所依赖的KEYID协议目前设置了4天的延时生效机制，也就是说，运营方如果要修改协议，至少4天后才能生效，如果待生效的协议对用户不利，用户有4天时间可以选择退出并撤走所有资产。随着时间推移，KEYID协议的延时长度将逐渐从4天提高到30天以上。
看持有AdminKey权限的运营方本身是否信誉良好，其所处的司法管辖区是否能起到有效的保护作用。
持有特定资产本身的风险。
持有的资产本身具有价格波动的市场风险、资产被Token合约本身的AdminKey冻结/没收的风险，等等。
抵押借贷类DeFi本身的市场风险。
核心的市场风险：抵押品迅速跌价导致无法及时平仓的风险。某一抵押品抵押数量过多导致市场流动性无法消化的风险，会导致风险的发生和加剧。
如何识别和规避风险？
在抵押协作中规定针对特定单一抵押品的抵押数量上限，上限的设定须与该抵押品的市场真实流动性匹配，尤其是要考虑泛滥的刷成交量这类因素。
评估抵押协议中的平仓机制设计是否合理，平仓机制是否能有效利用市场中的流动性进行平仓。
评估被纳入的抵押品本身的风险。
智能合约平台的风险。
像以太坊这样的智能合约平台，自身是存在风险的，这个风险的规避与智能合约风险的规避类似：安全审计。例如，以太坊早期做了非常详实的安全审计。长时间的有效实战检验。例如以太坊这样的智能合约平台，上线已经接近5年，早期出过一次中等级别的漏洞，导致被DoS攻击造成交易拥堵，后来基本运行平稳。
用户自身私钥管理的风险。
用户的私钥存在丢失、被盗的风险。用户发生人身事故，导致用户私钥所管理的资产无法继承的风险。
如何识别和规避风险？
学习私钥保管的相关知识，建立一套完善的、适合自身的私钥管理体系，包括备份、保密机制、物理存放安全、发生人身事故后的预案。通过使用智能钱包规避私钥管理的风险。注意，智能钱包为私钥保管提供更多安全和便利的同时，同时也引入了智能合约风险和AdminKey风险，需充分了解相关风险后根据自身情况选择使用。
好了，大道理说了一堆，那么我是怎么掉进这次lendf.me事件的坑里的呢？
首先，作为在Mt.Gox丢过几十个BTC的人，我对中心化平台的风险认识应该说是充分的，一般不会将资产长时间地存放在中心化平台上，尤其是在当前缺乏监管的行业大背景下。这让我对DeFi有天然的好感。
参与lendf.me的过程中，我主要关注3类风险：智能合约的风险、智能合约AdminKey权限的风险、lendf.me抵押借贷的市场风险。
先说lendf.me抵押借贷的市场风险。在2020年3月12日的市场暴跌中，lendf.me平台较好地抵御了市场的暴跌，没有出现抵押品清算不利导致资不抵债的情况。所以3月12日之后，我对平台的信任度有所上升。
关于智能合约AdminKey权限的风险，我事先知道平台是留有该权限的。平台的创始人与我相识，平时有不少交流，欣赏创始人的学识。出于对创始人的信任，我对平台的AdminKey权限也有连带的信任。
对于最重要的智能合约风险，我主要是通过“长时间的有效实战检验”这一措施来规避，现在看来，有以下几方面今后可以改进：
对“长时间”的定义应更加保守，原来我的定义大约是6个月，现在看来至少是1年。参与的资产占个人整体资产的百分比的上限，应与智能合约经过实战检验的时间长度成正相关关系。
风险和收益应该成正比才对。我参与平台的主要方式是稳定币理财，刚开始的时候收益率是比较高的，印象中是5-10%，后来随着收益率的下降，其实风险和收益的对比已经不划算了，但是由于惰性和侥幸心理，我并没有及时去调整头寸，例如出事前USDT在平台上的年化收益率不到1%，显然是与风险不匹配的，理性的选择应该将资产从理财中取出。这是我在这次事件中，犯的最大的错误，今后引以为戒。
更加重视安全审计报告。平台关联的审计报告，我事先并没有去了解，虽然对于本次事件来说，是否去看了审计报告并不会影响事情的结果，但我确实没有事先去看审计报告，这是不对的。最后，说说展望。
DeFi作为一个新的范式，并没有因为这次事件被证伪。好好想一想，让一个透明规则的“机器人”来提供金融服务，这是一件多么意义重大的事情，是一种全新的范式转移。这一范式转移，依然令人激动。然而，如何打造更安全的“机器人”，是今后区块链从业者必须要解决的问题，不然，新的范式不会流行。我个人会继续参与DeFi的投资和建设，以调整之后的风险意识参与。
想要获得收益，必须接受风险。世界的本质是不确定的，哪里都是风险，没有绝对的安全。想一想这次疫情，好好家中坐，祸从天上来，去超市买菜都存在死亡的风险。接受它，正视它，坦然面对，与狼共舞。
从投资的角度，务必遵守“分散原则”。这次踩雷事件中，我一直笃信和践行的分散原则，起到了最大的保护作用。虽然损失的绝对金额不少，但占比不是太大，当然，调整风险评估体系后，占比应该要更小一些。虽然踩了雷，事后心情固然有短暂的不开心，但并没有强烈的负面情绪，并不沮丧，并不悲观，更谈不上绝望。不然，也不会有心思写此文，此文也就无缘与你相见。分散原则让你夜里可以安睡。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。