甲骨文可以兼任吗? 类似RAI的系统如何安全地支持已抵押的ETH

伏特林 · 2023年1月26日上午12:20

RAI的主要挑战之一是难以找到愿意担任LP的ETH持有人,特别是如果利率高于其当前水平(约-5%)时% 至-10%. 造成此问题的主要原因之一是,目前,RAI CDP与赌注竞争作为收益来源。

今天的ETH持有人可以将他们的ETH放入CDP中,取出RAI,将其以1%的DAI储蓄率转换为DAI,并获得~ 10%的利差, 或考虑到2倍的抵押品保证金,年收益~ 5。或者,他们可以放下自己的ETH并以较低的风险收集相同的5。如果RAI利率甚至提高到-3%,计算变得更加有利于赌注。

多抵押RAI 正在探索 43 作为此问题的解决方案。我对此的看法是,DAI已经填补了成为 任意地 (包括“现实世界资产” )多抵押算法稳定币,因此RAI生态系统在该空间竞争是没有意义的。因此, 在我看来,仅当(多抵押品)指的是一种非常狭窄的多边形式时,才使RAI “或叉子”多抵押品才有意义:ETH和抵押ETH。

本文探讨了一些不同的操作方法。

我们是否可以让任何( solo ) staker双重将其股份用作CDP抵押品?

乙炔层 25通过将提款地址设置为仅在满足某些条件的情况下才退还其资金的合同,是一组工具,可让交易者重新使用其在其他应用程序中的股份。可以想象,可以使用Eigenlayer制作RAI版本: 用户通过将提款地址设置为仅在偿还RAI债务后才退还的合同,将其抵押的ETH放入CDP。如果用户被清算,则合同的逻辑会在协议中可能的情况下将ETH的所有权转让给清算人(,这也将立即触发提款)。

这种方法的主要挑战是,尽管它在正常情况下可以正常工作,但处罚非常罕见且非常低,但在极端情况下,它会大大降低系统的安全性。特别是,如果攻击者要进行51%的攻击(,或者甚至是涉及削减一些提议者)的较轻的攻击, 对于他们来说,将所有用于攻击系统的验证器放入RAI CDP中,并尽可能多地取出RAI是合理的。

如果攻击者这样做,则他们实际上是从系统中窃取“ RAI,从而导致其产生以RAI计价的债务。该系统可以通过拍卖以回购具有FLX或ETH储备的RAI来尝试快速重新平衡,但仍有破产的风险。

RAI可以只使用Lido的摊位吗?

在解决上述问题的同时,这种方法可能需要RAI最少的工作。但是,我会担心这种方法,因为存在以太坊级别的系统性风险,以进一步巩固像stETH这样的赌注系统。如果它获得了更大的市场主导地位,那么这将对控制地位的系统产生很多信任,从而将新的攻击媒介引入以太坊的整体赌注中。对于stETH而言,这比集中的放样衍生产品要少得多,但仍然存在风险。

因此,我强烈希望尝试找到在抵押品中使用抵押ETH的方法,以避免在单个主导的液体股票衍生工具周围产生网络效应。而且由于RAI不需要抵押资产(的可替代性,因为CDP不可替代),因此RAI实际上可能是解决方案的一部分。

想法1:神谕作为发球者

拥有RAI CDP (或RAI )的任何人都严重信任RAI的Oracle系统,不要窃取其资金。如果RAI神谕开始报告ETH / USD价格接近零,则所有CDP都将清算,从而使持有人一无所有。假设的攻击者可能会成为(中最大的RAI持有人),将能够以非常便宜的价格购买CDP并获得其中的ETH。

因此,应该非常重视对甲骨文系统的信任。特别是,该协议的投机令牌(的51%不可能在这里,FLX )投票立即更改甲骨文提供者而不会长时间延迟(,否则, 在风险资金总额超过FLX )的市场上限的环境中,该系统无法稳定运行。我对最佳模型的看法大致是这样的东西 44。

无论如何,关键观察是由于RAI持有人已经信任甲骨文不要以这种方式将其拧紧,因此,如果我们也信任甲骨文,则似乎不会增加系统的脆弱性, 风险较小 方式。

一种自然的选择是:RAI本身创建了Lido的副本,创建CDP的用户可以放样这些资金,将RAI oracles设置为放样键(, RAI oracles可以集体运行分布式验证器),但是将CDP设置为退出地址。

raistaking2.drawio

这里的信任程度低于预期:不良的RAI甲骨文制造者可能会因削减或闲置而导致资金被销毁,但他们不能偷这些资金,除了极少数例外,例如进行某种特殊的MEV攻击,其中涉及由于双重提议而削减攻击者。

但这还不是完美的:这种罕见的特殊攻击是可能的,而且尚不清楚神谕会想要做个强者。股份制的法律风险似乎高于成为甲骨文提供者的法律风险,在许多司法管辖区中,甲骨文提供者属于明确的自由言论“,仅提供信息”类别。这也将为黑客入侵提供更大的动力。

想法2:甲骨文作为2个中的2个

这是一种替代方案,它使用户可以保持更多的控制权,而对Oracles的信任则更少。而不是属于甲骨文的放样键,放样键是 P + Q, 在哪里 Q 是甲骨文的钥匙 P 是CDP持有人持有的钥匙。由于BLS签名的算术属性,Oracle可以用 Q, CDP持有人可以自行签名 P, 并将两个签名加在一起以创建可验证的签名 P + Q。这基本上是2之2 DVT 19。

这增强了信任属性,如下所示:

仅甲骨文就无法削减CDP持有人
仅甲骨文就无法进行提议者攻击,因为集体提议将要求CDP持有人签字
CDP持有人不能被削减或进行攻击,因此无法以这种方式破坏系统的抵押品
甲骨文或CDP持有人可以下线;在这种情况下,另一方将触发撤回并退出CDP,而损失很小。
在闲置泄漏期间,甲骨文或CDP支架脱机的情况。在这种情况下,任何一方都可能使另一方感到悲伤。

实施

此设计是DVT的特例:

它是2的2,因此从网络角度来看,这是最简单的情况
2个(中的1个Oracle )正在为数千个合作伙伴提供服务。但是,它可以简单地签署相同的数据并将其发布给与之下载的所有CDP
为了保持块生产的自主权,在这种特定情况下,它可以使用一个系统,在该系统中,提议者选择要签名的内容,然后将其发送到oracle进行共同签名。甲骨文不应在同一域的同一插槽中共同签名两个不同的数据,因为这可以与盲法结合使用以削减CDP

这是一项需要实施的新技术,因此可能需要DVT团队的合作才能实际构建。一旦建成,操作起来应该不会太困难。

想法的弱点2

该系统的最大漏洞是活动泄漏, 因为这些可能只是由Oracle脱机触发的。但是,我认为可以接受这种风险。如果验证者的余额降至16 ETH以下,则自动退出并撤回。因此,我们可以简单地接受具有2倍抵押品要求的抵押ETH,而不是提供常规ETH的1.5倍。

在极端情况下,如果同时泄漏了许多验证器,则一次只能撤回少数验证器,因此有些验证器会进一步泄漏到16 ETH以下, 但这是如果有需求的话,可以在以太坊的赌注协议中进行更改。即使没有修复,也将遭受非常极端的攻击(离线)超过50, 在诚实验证者控制的余额分数返回2/3以上之前,大量验证者泄漏到远低于16 ETH的位置。

另一个主要弱点是,在一个主要担心不是恶意削减神谕,而是恶意或粗心地离线神谕的世界中,它运作不佳。这可能是因为我们要么( i )期望甲骨文是低质量的赌注者,是因为我们正在为诚实而不是技术水平进行优化,或者( ii )甲骨文使用受信任的硬件, 用户将其视为(部分)信任假设( cf。河豚 5)。为了解决这些弱点,我们在下面提出了想法3。

想法3:半可信的Oracles,用于分级安全性

在您可以保证大多数预言的诚实性的情况下,另一种方法可以消除剩余的信任问题, 如果您甚至无法保证至少有一些预言是诚实的,则以重新引入信任问题为代价。

我们定义三个常量:

N: the total number of oracles in the oracle system
k1: the number of oracles that can work together to sign a message together with the CDP holder (eg. k1 ~= 0.2 * N)
k2: the number of oracles that can work together to sign a message without the CDP holder (eg. k2 ~= 0.8 * N)

We ask the oracles to maintain two secret-shared keys:

Q1, in a k1-of-N secret share
P + Q2, in a k2-of-N secret share (one copy of the latter for each CDP holder)

With Q1, the oracles can co-sign with the CDP holder, and with Q2, they can sign independently.

In the case where k1 + k2 = N (eg. k1 = N/5 and k2 = 4N/5), this ensures that neither slashing nor inactivity leaks can happen in either of two cases:

More than k2 oracles are honest (as they can sign messages independently, and a malicious CDP holder cannot find a quorum of k1 to co-sign)
At least k1 oracles are honest, and the CDP holder is honest (as the two groups together can sign messages, and the remaining oracles cannot sign and cannot block them)

This style is similar to phase 1 training wheels for rollups 4, creating a linear hybrid between two security models as a way of partially trusting both but not putting too much trust on either one.

Note that this design can be viewed as a generalization of ideas 1 and 2 (and even the strawman “the CDP holder can sign by themselves” proposal): k1 and k2 can be adjusted as needed to explore the entire tradeoff space of whom to trust for what.

这些方法的一般好处(想法1之2或3 )

可靠的中立,不会引入外部依赖性:它只会相信参与者对已经拥有更高信任度
实现用户能够同时持有和持有CDP的收益
避免不必要地促进现有液体放样衍生物的网络效应。相反, 该计划维持的马stable 是 (稳定)液体放样衍生物。

比较想法1与2与3

排名实施简单, 想法1 >想法2 >想法3
排名防止不良神谕, 想法3 >想法2 >想法1
排名防止CDP不良持有人, 想法3 >想法2 >想法1
排名避免甲骨文害怕运行它, 想法2 >想法3 >想法1

总体而言,想法1在短期内似乎更可实施,并且将是“赌注的有趣补充,同时同时获得其他收益”空间。但是,想法2和3似乎更加可信赖,并且长期持久,对甲骨文的信任度降低,并且在保持权力下放方面做得更好, 因此从长远来看,它们似乎对我更具吸引力。

One of the main challenges with RAI is the difficulty of finding ETH holders who are willing to act as LPs, particularly if interest rates go higher than their current level of around -5% to -10%. One of the main reasons behind this problem is that currently, RAI CDPs compete with staking as a source of yield.

An ETH holder today could put their ETH into a CDP, take out RAI, convert it to DAI with its 1% DAI savings rate, and earn a ~10% spread, or a ~5% annual return taking into account a 2x collateral margin. Or, they could just stake their ETH and collect that same 5% with less risk. If RAI interest rates increase to even eg. -3%, the calculation becomes even more in favor of staking.

Multi-collateral RAI is being explored 43 as a solution to this issue. My own view on this is that DAI already fills the niche of being an arbitrarily (including “real-world assets”) multi-collateral algorithmic stablecoin, and so it does not make sense for the RAI ecosystem to compete in that space. Hence, in my view making RAI (or a fork) multi-collateral only makes sense if the “multi-collateral” refers to an extremely narrow form of multi-collateral: ETH and staked ETH.

This post explores some different ways of doing this.

Can we just let any (solo) staker dual-use their stake as CDP collateral?

Eigenlayer 25 is a set of tools that lets stakers re-use their stake in other applications, by setting their withdrawal address to a contract that only returns their funds if some condition is met. Conceivably, one could make a version of RAI that uses Eigenlayer: users put their staked ETH into a CDP by setting their withdrawal address to a contract that only returns it once they pay back their RAI debt. If a user gets liquidated, the contract’s logic transfers ownership of the ETH to the liquidator (when it becomes possible in the protocol, it would also immediately trigger a withdrawal).

The main challenge with this approach is that while it works fine in normal cases, where penalties are very rare and very low, in extreme cases it greatly degrades the system’s security. In particular, if an attacker is going to make a 51% attack (or even a milder attack that involves slashing a few proposers), it becomes rational for them to put all the validators they will use to attack the system into RAI CDPs, and take out as much RAI as they can.

If attackers do this, then they are effectively “stealing” RAI from the system, causing it to incur a RAI-denominated debt. The system could try to quickly rebalance by making auctions to buy back the RAI with FLX or ETH reserves, but it still risks going bankrupt.

Could RAI just use Lido’s stETH?

This is the approach that would probably require the least work on the part of RAI, while still solving the above problem. However, I would be concerned about such an approach, as there are Ethereum-level systemic risks to entrenching a staking system like stETH further. If it acquires much greater market dominance, then this puts a lot of trust into the system that governs stETH, introducing a new attack vector into Ethereum staking as a whole. This is much less true for stETH than for a centralized staking derivative, but it is nevertheless still a risk.

For this reason, it is my strong preference to try to find ways to use staked ETH in collateral that avoid entrenching network effects around a single dominant liquid staking derivative. And because RAI does not require fungibility of collateral assets (as CDPs are not fungible), RAI could actually be part of the solution.

Idea 1: Oracles as stakers

Anyone who has a RAI CDP (or, for that matter, RAI), is heavily trusting RAI’s oracle system not to steal their funds. If RAI oracles start reporting an ETH/USD price of near-zero, all CDPs would get liquidated, leaving their holders with nothing. RAI holders (which a hypothetical attacker would perhaps become the largest of) would be able to come in and buy up the CDPs and get the ETH inside of them very cheaply.

For this reason, trust in the oracle system should be taken extremely seriously. In particular, it should not be possible for 51% of the protocol’s speculative token (here, FLX) to vote to immediately change oracle providers without a long delay (otherwise, the system could not run stably in an environment where the total funds at stake exceed the market cap of FLX). My own view on what the best model is is roughly something like this 44.

In any case, a key observation is that since RAI holders already trust oracles not to screw them over in this one way, it plausibly does not increase the system’s vulnerability if we also trust oracles in other, less risky ways.

One natural option is: RAI itself creates a copy of Lido where users who create CDPs can stake those funds, setting the RAI oracles to be the staking key (perhaps, RAI oracles could collectively run a distributed validator), but setting the CDP as the withdrawal address.

raistaking2.drawio

The level of trust here is less than it seems: bad RAI oracle-stakers could cause the funds to be destroyed, by either getting slashed or getting inactivity-leaked, but they cannot steal the funds, with rare exceptions like making some kind of exceptional MEV attack that involves the attacker being slashed due to double-proposing.

But this is still not perfect: such rare exceptional attacks are possible, and furthermore it’s not clear that oracles would want to be stakers. The legal risks of staking are plausibly higher than the legal risks of being an oracle provider, which in many jurisdictions falls into an unambiguous free-speech “just providing information” category. It would also create a greater incentive to hack them.

Idea 2: Oracles as 2-of-2 stakers

Here is an alternative that lets users keep more control and trusts oracles less. Instead of the staking key belonging to the oracle, the staking key is P + Q, where Q is a key belonging to the oracle and P is a key held by the CDP holder. Because of the arithmetic properties of BLS signing, the oracle can sign with Q, the CDP holder can make their own signature with P, and add the two signatures together to create a signature that verifies against P + Q. This is basically 2-of-2 DVT 19.

This strengthens the trust properties as follows:

The oracle alone cannot slash the CDP holder
The oracle alone cannot conduct proposer attacks, as block proposals would require the CDP holder to sign off
The CDP holder cannot get slashed or conduct an attack, and so cannot destroy the system’s collateral that way
The oracle or the CDP holder can go offline; in this case, the other party would trigger a withdrawal and exit the CDP with only minor losses.
The extreme case if where the oracle or the CDP holder go offline during an inactivity leak. In this case, either party could grief the other.

Implementation

This design is a special case of DVT:

It’s 2-of-2, so it’s the simplest possible case from a networking perspective
1 of the 2 (the oracle) is serving thousands of partners. However, it could simply sign the same data and publish it for all of the CDPs that it works with to download
To preserve autonomy of block production, in that specific case it could use a system where the proposer chooses what to sign, and sends it to the oracle to co-sign. The oracle should not co-sign two different pieces of data in the same slot with the same domain, as that could be combined with blinding tricks to slash the CDPs

This is new tech that would need to be implemented, and so it would probably require cooperation from a DVT team to actually build this. Once built, it should be not too difficult to operate.

Weaknesses of idea 2

The largest vulnerability of this system is inactivity leaks, as these can be triggered just by the oracle going offline. However, I would argue that it is okay to accept this risk. Validators get automatically exited and withdrawn if their balances drop below 16 ETH. Hence, we can simply accept staked ETH with a 2x collateral requirement instead of the 1.5x that regular ETH is offered.

There is an extreme case, where if many validators are leaked at the same time, only a few can withdraw at a time, and so some will leak even further below 16 ETH, but this is something that could be changed in the Ethereum staking protocol if there is demand for it. Even without a fix, it would take a very extreme attack (much more than 50% going offline), for a significant number of validators to leak far below 16 ETH before the fraction of balances controlled by honest validators returns above 2/3.

Another major weakness is that it does not work well in a world where the primary worry is not oracles maliciously slashing, but rather oracles either maliciously or carelessly going offline. This could be because we either (i) expect oracles to be low-quality stakers, because we are optimizing for honesty and not technical proficiency, or (ii) the oracles use trusted hardware, and users accept this as a (partial) trust assumption (cf. Puffer 5). To address these weaknesses, we propose idea 3 below.

Idea 3: Semi-trusted oracles for graded security

Another approach removes the remaining trust issues in the case where you can guarantee honesty of most of the oracles, at the cost of reintroducing trust issues in the case where you cannot even guarantee that at least a few oracles are honest.

We define three constants:

N: the total number of oracles in the oracle system
k1: the number of oracles that can work together to sign a message together with the CDP holder (eg. k1 ~= 0.2 * N)
k2: the number of oracles that can work together to sign a message without the CDP holder (eg. k2 ~= 0.8 * N)