Collateral Risk Control Design Doc

[maxisacoder]

Related Solution

We went deep in tree projects previously, namely MakerDao, Dharma, dydx. They all have some design choice of Risk Management. The following Chapter will grasp some key desisn rationale of them.

Dharma

Dharma provides only seizable collateral if and only if the creditor fails to repay. 这种方式无疑只提供了最低程度的风险控制，对于真实的抵押借贷业务，没有基于抵押物价格波动的风控方案无疑是无法对接真实业务的。当然，社区现在也在探索风控方案，详见讨论 https://github.com/dharmaprotocol/DIPs/issues/2

dydx

dydx 的风控机制在于，将全部的风险给到creditor，creditor需要自己在链下实时监测币价，同时creditor可以在任何时间要求debtor加仓任何金额的抵押物，所以creditor需要一个reputation系统来保证其最大程度的自由带来的最大程度作恶的可能性。这种设计哲学无疑是粗放的且奇怪的，因为他极大程度的增加了creditor的操作成本，同时由于reputation系统的引入，并没有减小整个系统的复杂度。

makerdao

在上一篇MakerDao Deep Dive文章中，我们事无巨细的探讨了MakerDao的平仓系统，这套系统为我们提供了很多的参考，但同时也面临着很多的问题。在下面的讨论中，在预言机和平仓机制中，我们都阐释了其可取之处和局限性，并采用了十分不同于MakerDao方案的路径来考虑整个系统的设计。

Current Proposal

首先，我们进行拆分，按照不同的功能需求，这个问题可以拆分成以下几个问题：

• 实时币价的喂价：币价用来计算当前的抵押率，是抵押率不良的一个判断条件。
• debt servcing： 包括订单催收和加仓提醒（margin call），本文只探讨margin call，催收在另外的话题中另行讨论
• 强平机制：在抵押率达到强平线时，需要有一套平仓机制及时的将抵押物变成对principle稳定的币种或者principle本身的币种。强平机制中，时效性和流动性，是最关键的两个指标。

三者个系统之间有一定的调用关系，1. 喂价系统要被加仓提醒，和强平机制调用。喂价系统的主要指标是安全性，及时性，准确性。2.加仓提醒由加仓警戒线触发，强平机制由强制平仓线来触发。考虑到债务人的利益，在强平之前，一定要有充足的时间去提醒债务人加仓。这个问题非常关键，下面我们将分别讨论这三个系统的设计。

币价feed

币价feed是一个经典的oracle问题，oracle在很多系统中例如makerdao和oraclize已经有了基本的解决方案。但在设计这个oracle系统的时候，我们首先考的的问题是。链下的价格，何时，何地上链。

选项一：链下价格实时上链

该种方案，根据makerdao的经验，在满足条件1. 交易对币价波动超过某个百分比。2.一段时间内未更新币价的两种下，触发币价的上链。参考上一篇文档，在币价上链后，结合多个交易所最后更新的币价，取中位数得到某个交易对当前的币价。下面的图阐释了这种完全的链上喂价的基本流程：

这一种方案，在makerdao中已经安全的运行了半个多年头，可以说安全性，稳定性，去中心化程度都是非常不错的。但面临的最大问题是：随着交易对的增多，需要部署的合约和需要触发的交易手续费快速增加。假设每个交易对需要对接5个交易所，那么一共就是6个合约，平均每个合约至少6个小时调用一次，每次调用平均需要 0.001个以太坊。那么如果我们有n种支持的抵押物，就需要至少1个稳定币USDT和其的交易对的币价，至少需要6n个合约部署，和每天至少4*5*0.001*n = 0.02n ether的合约手续费。假设n=10， 那么每天花在预言机上面的手续费就是至少0.2个以太，一个月的成本至少在 15个以太。这样的成本是否对于一个节点来说是可控的，现在看起来是非常危险的。makerdao之所以可以这么玩儿，是因为其交易对偏少，同时对进入强平阶段的CDP惩罚较高，故可以用这种方式来实现。

这里面的一个关键问题在于，谁来call这个喂价合约，在makerdao中是DAO选取的server，和foundation运营的server在提供服务。因为maker只有4个交易对，估算其所有的server加起来一个月的开销可能就在十个以太以内。而我们如果这个费用让节点来出，在支持的抵押物越来越多的情况下，gas开销可能会非常的难以接受。 同时，我们研究了目前处在实验阶段的新的makerdao的喂价合约terra，其使用了签名消息来减少交易手续费的使用。调研后发现terra的代码还处在非常不成熟的阶段，基本上没有实际的实现。无法获得太多参考信息。

如果我们想规避手续费过高的问题，我们可以将喂价逻辑与平仓逻辑整合，也即在 liquadation 的 transaction call 中进行喂价。这是一个非常机智的idea，但是面临的最大question就是，caller即控制了喂价也控制了平仓的触发，如何保证合约caller喂价的准确性和客观性。可以强制要求caller在链上喂价时，也附带除自己之外的一定数量的喂价者签名的喂价值，换句话说，就是设计一个基于链下签名消息的喂价协议，不同的节点和喂价人(这些喂价者是注册在喂价合约白名单中的)之间可以交换其喂价值，在喂价时进行链上的真实喂价值计算(目前采取的算法是基于中位数)。这样做的好处是，在理论上保证了和链上喂价一样的安全性，甚至可以做到更加实时。（我们可以在平仓的时候直接链下请求喂价人暴露的接口，实时请求当前的价格）同时，这种方案节省下来的gas开销可以作为喂价者的激励返还给他一部分，激励大家去run一个喂价服务。同时，这个系统中可以设计一些惩罚去治理错误的喂价者。

预警系统（Margin Call）

margin call 的定义是在抵押率危险的时候，提前提醒用户加仓，以为强制平仓提供一定程度的缓冲时间。作为debt servicing 的一部分。这样的时间对于债务人是必要的，否则可能会发生一些纠纷。在Dharma的DIP-2 中提到了一种链上触发预警transaction，同时触发margin call事件以供dapp来监听的一种模式。我个人非常不欣赏这种方式的预警系统设计，原因有二：1. dapp一定不是永远在线，靠dapp去监听margin call 面临及时性的危险。 2. 在没有集成DID系统的情况下，dapp无法掌握用户的真实联系方式，这对提醒加仓是十分不利的。3. 同时，对于ETH为抵押物的债权人，由于不涉及催收，技术上可以不需要其kyc信息。

因此，基于上述的考虑，我认为Margin Call的系统可以完全做成一个链下的系统，因为margin call不会实际的引起抵押物的transfer，故其对交易对价格源的安全性有较高的容忍，节点可以自行决定是否对一笔订单发起margin call，如果错误的发起了margin call，只是某个节点的单独错误行为，受到的影响是可控的。同时因为签单的节点可以对用户进行链下的kyc，在做margin call的时候就有可能联系到真实用户，甚至可以线下去接触用户。这样无疑才是预警系统的意义之所在。

平仓系统

平仓系统可以拆分为3个步骤：

1. 平仓合约调用者触发合约，通过计算当前的价格来判断抵押率是否达到平仓线， 也即 (collateralUnitPrice * collateralAmount) / (principalUnitPrice * principalAmount) < minimumCollateralRatio
2. 抵押物的transfer：这个里面有两种设计。方案一为在步骤一时，由智能合约直接的将代币转到合约调用者的地址，由其进行平仓。第二种则将这两者解耦，在步骤一时触发时间，由其他全网所有白名单中的节点进行监听，监听到的节点可以申请抵押物的获得。在获得抵押物后，在链下对抵押物进行强制平仓处理。第一种方案较为简洁，第二种则更加灵活。有可能发生的情况是，某一节点认真的监听币价波动可以率先的发现某笔订单的抵押率问题，但自身无法获得该交易对的流动性。则可以由另外某个节点去做真正的平仓工作。在现阶段，我比较倾向于第一种方案，根据奥卡姆剃刀，我们一方面前期只会有一个节点，另外一方面后期也只希望暴露一份节点代码，如果某个节点的某个交易对流动性不足，可以让他自己想办法，去调用流动性充足的交易所。
3. 平仓后的repay：平仓后repay也分两种，链上或者链下。链上发生更加安全透明不可抵赖，链下交易则快捷灵活。在这里，我比较倾向于节点做了平仓处理后上链操作，因为考虑到未来的可扩展性，可能需要暴露相应的repay钩子函数，同时也方面链上合约状态的更新。

Rationale(Meeting Topic)

在上次讨论中，我们的提出了在以下几点上的优化空间或者需要跟进的点。

喂价中位数的计算，是否有可能可以放在链下。

按照上一次的讨论，每一个server对接了一家交易所，上链时仅代表某一家交易所的价格。但其实对于中心化的服务器资源，我们完全可以在每一个server都对接所有交易所，对所有交易所的币价取中位数后，再将该中位数作为自己的喂价，在平仓线判断和平仓出发时，都使用该喂价。在有效市场的前提下，多个交易所之间的价差应该不会太大，但实际去将抵押物平仓的平仓者，可能在交易所中平仓的价格与其喂价不同。这个价差导致的亏损或者盈利都应该由节点自己来承担。在市场不会剧烈波动的大部分情况下，节点应该都是有盈利空间的，因为我们再计算中使用的是价格的中位数，而真正liquadate抵押物时，可以使用价格最优的某个交易所的价格。

尝试探索在链下的喂价源上建立惩罚机制，以确保价格的准确性。

喂价源是一个非常重要的系统，不准确的喂价将导致不必要的平仓发生，使债务人蒙受损失。在vitalik 2014年就畅想过一篇trust-free的喂价源系统，使用了博弈论中的schelling point作为理论支持。这个理论强调，要无偏向性的选择喂价人，同时尽量保证在喂价人中间有不同的价格趋向性以应对micro-cheating。在我们的系统中，节点方由于有平仓激励，所有有将价格喂低来提早触发平仓的倾向。同时，债务人由于将抵押物抵押到了智能合约中，故有倾向将价格喂得偏高。在健康的喂价源选择中，两方的人都需要，同时要无偏见的选取这两方参与系统。

直接在链上设计价格的审查机制可能比较困难同时不够经济（类似casper这种智能合约，设计一定是非常复杂的且没有通用性），我们可以通过仲裁网络，对由喂价不准确的平仓发生的订单寓意仲裁。我们只要在链下喂价的系统中提交上链时，附带每一个提交价格者的价格数据结构的commitment，在发生纠纷时可以reveal这一部分信息，以为仲裁者提供仲裁依据。

在平仓中，是否可以通过什么机制的设计来增加vena的使用需求。

• 首先，喂价人需要抵押一部分vena做喂价的保证金，在喂价人喂价异常时，可以由仲裁网络来仲裁。扣除的的喂价人保证金用来分配给仲裁网络中的陪审员和受害的债务人或者债权人。
• 每当平仓触发时，可以要求触发者，支付一小部分的vena代币（比例不会太高），在币价大幅波动导致节点保证金无法支付债务人损失的情况下，可以有社区来共同决定是否可以使用这部分vena补偿利益受损的个体。
• 更多场景，可以探索，不过第二点个人认为已经有点过度设计了。在平仓这个环节中，由于涉及到的principle代币和colleteral代币都可能不是vena，所以设计模型时一定要小心不要给系统引入过多的复杂度和规则，否则极其容易画蛇添足。

Implantation 1.0

如果上面的章节关注的是各种设计的可能性，和不同可能性的优缺点。这一章更加关注在短时间比较容易落地的方案，所以简洁性，可拓展性是一个主要的trade-off因素。

对于三个不同的系统，我们分别采取以下路径

• 喂价系统：官方节点喂价，对链下的喂价数据格式保留拓展的空间，已实现喂价网络的可扩展。
• 预警系统：官方节点检测抵押率，结合用户的kyc信息，做中心化的Margin Call
• 平仓系统：分为两个步骤，
  - 官方节点调用合约完成触发，直接获得抵押物。
  - 在交易所链下liquadate后，将获得的代币通过合约提交上链。

这三个系统的优先级是 喂价 = 平仓 > 预警, 实现难度是 平仓>喂价>预警。同时，这三个系统都是可以完全开源的系统。

下面做出调用时序图，以阐释不同系统之间的关联和平仓整体的业务流程：

其中特别值得注意的有两点：

1. 我们需要在现有的抵押借贷合约中，添加加仓抵押物的接口，同时，当前抵押物的信息需要做到链上可查询，以便为节点做出触发平仓的依据。在我们现有实现中，抵押物的调整信息，需要在TermsContract中暴露特定的查询接口。
2. 在第五步return principle中，其return的币总量为扣除其本身佣金比例后剩余的principle，提交上链后，可能会有的剩余可以用来返还给debtor。

Known Limitations

在现有的设计中，我们的平仓机制仍然局限于ETH及ERC-20代币的抵押。对于BTC，目前我们走的方式还是多签地址用来抵押的模式，在产品设计中，对于BTC的抵押和ERC20的抵押，我们希望获得较为一致的产品体验和统一的dapp包装，对于BTC而言，可能面临一些技术挑战如下：

• BTC的平仓

Ref

• https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/
• Collateral Risk Control Design Doc #11