Vitalik: Taking the RAI system as an example, exploring the possibility of oracle co-staking

Author: Vitalik Buterin

Compiled by: The Way of DeFi

One of the main challenges facing RAI is the difficulty in finding ETH holders willing to act as LPs, especially when interest rates are above the current level of about -5% to -10%. A major reason behind this issue is that currently, RAI CDPs compete with staking as a source of yield.

Today, ETH holders can put their ETH into a CDP, withdraw RAI, convert it to DAI at a 1% savings rate, and earn about a 10% spread, or about a 5% annual return (considering 2x collateralization). Alternatively, they can simply stake their ETH and earn the same 5% annual return with lower risk. If RAI rates were to even increase to -3%, the calculations would further favor staking.

Some are exploring multi-collateral RAI as a solution to this problem. My personal view is that DAI has already filled a niche market as an arbitrary (including "real-world assets") multi-collateral algorithmic stablecoin, making it meaningless for the RAI ecosystem to compete in this area. Therefore, in my opinion, it only makes sense to create RAI (or a fork) multi-collateral if "multi-collateral" refers to a very narrow form of collateral (ETH and staked ETH).

This article explores some different approaches to achieve this.

Can we allow any (solo) staker to double-use their staking rights as collateral for a CDP?

Eigenlayer is a set of tools that allows stakers to reuse their staking rights in other applications by setting the withdrawal address to a contract that only returns funds under certain conditions. One can imagine creating a version of RAI using Eigenlayer: users deposit their staked ETH into a CDP by setting the withdrawal address to a contract that only returns funds after they repay their RAI debt. If the user is liquidated, the contract's logic would transfer ownership of the ETH to the liquidator (and it would also trigger a withdrawal immediately when possible in the protocol).

The main challenge of this approach is that while it works well under normal circumstances, with penalties being very rare and very low, it significantly reduces the security of the system in extreme cases. In particular, if an attacker intends to perform a 51% attack (or even a milder attack involving the seizure of some proposers), it becomes reasonable for them to put all the validators used to attack the system into the RAI-CDP and withdraw as much RAI as possible.

If an attacker does this, they are effectively "stealing" RAI from the system, leading to debt denominated in RAI. The system could attempt to quickly rebalance by auctioning RAI using FLX or ETH reserves to buy back RAI, but it still faces the risk of bankruptcy.

Can RAI only use Lido's stETH?

This is a method that may require minimal work while addressing the above issues. However, I would be concerned about this approach, as further consolidating staking systems like stETH could lead to systemic risks at the Ethereum level. If it gains greater market dominance, it would place a lot of trust in the system managing stETH, introducing new attack vectors into the entire Ethereum staking ecosystem. For stETH, this is far less real than centralized staking derivatives, but it still poses a risk.

For this reason, I strongly lean towards trying to find ways to use staked ETH as collateral to avoid creating network effects around a single dominant liquid staking derivative. Moreover, since RAI does not require the fungibility of collateral assets (as CDPs are non-fungible), RAI could actually be part of the solution.

Idea 1: Oracles as Stakers

Anyone with a RAI CDP (or RAI) is very confident that RAI's oracle system will not steal their funds. If the RAI oracle starts reporting ETH/USD prices close to zero, all CDPs will be liquidated, leaving their holders with nothing. RAI holders (a hypothetical attacker could be one of the largest) would be able to come in and buy CDPs, acquiring ETH within at a very cheap price.

For this reason, trust in the oracle system should be of utmost importance. In particular, 51% of the protocol's speculative tokens (here FLX) cannot vote to immediately change the oracle provider without a long delay (otherwise, the system cannot operate stably in an environment where the total risk capital exceeds the FLX market cap). My own view of the optimal model is roughly like this.

In any case, a key observation is that since RAI holders already believe the oracle will not mess up in this way, trusting the oracle in other lower-risk ways does not seem to increase the system's vulnerability.

A natural choice is: RAI itself creates a Lido copy where users creating CDPs can stake these funds, setting the RAI oracle as the staking key (perhaps the RAI oracle could jointly run distributed validators), but setting the CDP as the withdrawal address.

The level of trust here is not as high as it seems: a bad RAI oracle could lead to funds being destroyed, either being seized or facing offline penalties (inactivity-leaked), but they cannot steal funds, with very few exceptions, such as conducting some special MEV attack where the attacker is penalized for double proposing.

But this is still not perfect: such rare special attacks are possible, and it is unclear whether oracles would be willing to become stakers. The legal risks of staking seem higher than those of being an oracle provider, the latter falling into the clear "freedom of speech" category of "providing information" in many jurisdictions. This would also create greater incentives to attack them.

Idea 2: Oracles as 2-of-2 Stakers

This is an alternative that allows users to maintain more control and reduce trust in oracles. Instead of a staking key belonging to the oracle, the staking key is P + Q, where Q is the key belonging to the oracle, and P is the key held by the CDP holder. Due to the algorithmic properties of BLS signatures, the oracle can sign with Q, the CDP holder can sign with P, and the two signatures can be combined to create a signature verifying P + Q. This is essentially 2-of-2 DVT‌.

This strengthens the trust properties as follows:

a. The oracle alone cannot seize the CDP holder;

b. The oracle itself cannot conduct proposer attacks since block proposals require the CDP holder's signature;

c. The CDP holder cannot be seized or attacked, thus cannot destroy the system's collateral in this way;

d. Either the oracle or the CDP holder can go offline; in this case, the other party will trigger an exit and leave the CDP, with minimal loss;

e. The extreme case is when the oracle or CDP holder goes offline during inactivity leaks. In this case, either party could cause the other to incur losses.

Execution

This design is a special case of DVT:

a. It is 2-of-2, so from a network perspective, this is the simplest case;

b. One of the two (the oracle) is serving thousands of partners. However, it can simply sign the same data and publish it for all CDPs it collaborates with to download;

c. To maintain autonomy in block production, in this specific case, it can use a system where the proposer selects what to sign and sends it to the oracle for co-signing. The oracle should not sign two different pieces of data in the same slot of the same domain simultaneously, as this could combine with blinding tricks to seize the CDP.

This requires new technology to be implemented, so it may need collaboration from the DVT team to truly realize it. Once built, it should not be too difficult to operate.

Weaknesses of Idea 2

The biggest vulnerability of this system is inactivity leaks, as these leaks may only be triggered by the oracle going offline. However, I think accepting this risk is acceptable. If the balance falls below 16 ETH, the validator will automatically exit and withdraw ETH. Therefore, we could simply accept staking ETH with a 2x collateral requirement instead of providing 1.5x of regular ETH.

There is an extreme case where if many validators leak simultaneously, only a few can exit at a time, so some validators may incur further leakage penalties below 16 ETH, but if there is demand, this could happen in the Ethereum staking protocol. Even without fixes, it would require very extreme attacks (over 50% of people going offline) before the proportion of balances controlled by honest validators returns to above 2/3, as a large number of validators leak far below 16 ETH.

Another major drawback is that in a world where the main concern is not the oracle maliciously seizing but rather the oracle going offline maliciously or accidentally, it does not work well. This could be because we either (i) expect the oracle to be a low-quality staker since we are optimizing for honesty rather than technical proficiency, or (ii) the oracle uses trusted hardware, and users accept this as a (partial) trust assumption (see Puffer‌). To address these weaknesses, we propose the following Idea 3.

Idea 3: Semi-Trusted Oracles for Layered Security

In a situation where you can guarantee that most oracles are honest, another approach eliminates the remaining trust issues.

We define three constants:

N: The total number of oracles in the oracle system;

k1: The number of oracles that can jointly sign messages with the CDP holder (e.g., k1 ~= 0.2 * N)

k2: The number of oracles that can collaboratively sign messages without the CDP holder (e.g., k2 ~= 0.8 * N)

We require the oracles to maintain two secret shared keys:

a. Q1, in a k1-of-N secret sharing

b. P + Q2, in a k2-of-N secret sharing (the latter being one for each CDP holder)

For Q1, the oracles can jointly sign with the CDP holder, while for Q2, they can sign independently.

In the case of k1 + k2 = N (e.g., k1 = N/5 and k2 = 4N/5), this ensures that neither forfeiture nor inactivity leaks occur in both cases:

a. More than k2 of the oracles are honest (since they can independently sign messages, malicious CDP holders cannot find a quorum of k1 to jointly sign);

b. At least k1 oracles are honest, and the CDP holder is honest (since these two groups can jointly sign messages, while the remaining oracles cannot sign or prevent them);

This style is similar to the first phase training rounds of Rollup, creating a linear mix between two security models as a way to partially trust both without over-trusting one.

Note that this design can be seen as a generalization of Ideas 1 and 2 (even the proposal "CDP holders can sign for themselves"): k1 and k2 can be adjusted as needed to explore the entire trade-off space of whom to trust.

The general benefits of these methods (Ideas 1 in 2 or 3)

a. Trusted neutrality, without introducing external dependencies: it only trusts participants, and it has already been given a higher degree of trust;

b. It enables users to simultaneously stake and hold CDPs;

c. It avoids unnecessarily promoting network effects of existing liquid staking derivatives. Instead, the stablecoin maintained by the plan is a (stable) liquid staking derivative.

Comparing Ideas 1, 2, and 3

a. Ranked by ease of implementation, Idea 1 > Idea 2 > Idea 3

b. Ranked by prevention of bad oracles, Idea 3 > Idea 2 > Idea 1

c. Ranked by protection against bad CDP holders, Idea 3 > Idea 2 > Idea 1

d. Ranked by avoiding oracle fear of running it, Idea 2 > Idea 3 > Idea 1

In summary, Idea 1 seems easier to implement in the short term and would be an interesting addition to the "earning other staking yields simultaneously" space. However, Ideas 2 and 3 seem to require less trust, are more durable, have lower trust in oracles, and better maintain staking decentralization, making them more appealing to me in the long run.