Vitalik: Take the RAI system as an example to explore the possibility of co-staking oracle machines

Original author:Vitalik Buterin

Compilation of the original text: The Way of DeFi

Original author:

Compilation of the original text: The Way of DeFi

One of the main challenges for RAI is that it is difficult to find ETH holders willing to act as LPs, especially when interest rates are higher than 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.

Some are exploring multi-collateral RAI as a solution to this problem. My personal take on this is that DAI already fills a niche market as an arbitrary (including "real world asset") multi-collateral algorithmic stablecoin, so it makes no sense for the RAI ecosystem to compete in this space. So, in my opinion, making RAI (or forking) multi-collateral only makes sense if by "multi-collateral" you mean an extremely narrow form of multi-collateral (ETH and pledged ETH).

This article explores a few different ways to do this.

image description

EigenlayerImage credit: Generated by Maze AI tool

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

is a set of tools that allows stakers to reuse their stake in other applications by setting withdrawal addresses to contracts that only return funds if certain conditions are met. One could conceivably make a version of RAI that uses Eigenlayer: users deposit their pledged ETH into a CDP by setting the withdrawal address to a contract that will only be returned after they repay their RAI debt. If the user is liquidated, the contract's logic will transfer ownership of the ETH to the liquidator (which also triggers a withdrawal immediately when possible in the protocol).

The main challenge with this approach is that while it works well under normal circumstances with very rare and very low penalties, in extreme cases it can significantly reduce the security of the system. In particular, if an attacker intends to conduct a 51% attack (or even a milder attack involving slashing some proposers), then they put all validators used to attack the system into the RAI-CDP, and as many as possible Taking out the RAI makes sense.

If an attacker does this, they are effectively "stealing" RAI from the system, causing it to incur a RAI-denominated debt. The system could try to rebalance quickly by auctioning off to use FLX or ETH reserves to buy back RAI, but it still runs the risk of going bankrupt.

Can RAI use only Lido's stETH?

This is an approach that RAI may require the least amount of work while addressing the issues above. However, I would be concerned about this approach, as further consolidation of a staking system like stETH would lead to Ethereum-level systemic risk. If it gains greater market dominance, then that would bring a lot of trust to the system that governs stETH, introducing new attack vectors to Ethereum staking as a whole. This is far less true for stETH than for centralized staking derivatives, but it is still a risk.

For this reason, I'm strongly inclined to try and find ways to use staked ETH as collateral to avoid network effects around a single dominant liquid staking derivative. And since RAI does not require fungibility of collateralized assets (since CDPs are not fungible), RAI can actually be part of the solution.

Idea 1: Oracles as stakersAnyone with a RAI CDP (or RAI) has a high degree of confidence 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 would probably be the biggest of them all) will be able to come in and buy CDPs and get the ETH in them for very cheap.For this reason, trust in oracle systems should be taken extremely seriously. In particular, it is impossible for 51% of the protocol speculative token (here FLX) to vote to change the oracle provider immediately without a long delay (otherwise, the system would not be stable in an environment where the total amount of funds at risk exceeds the market cap of FLX run). My own opinion of the best model is roughly

so

of.

Anyway, a key observation is that since RAI holders already trust the oracle not to screw them up in this way, it doesn't seem to increase the vulnerability of the system if we also trust the oracle in other, less risky ways sex.

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

The level of trust here is not as high as it seems: bad RAI oracles can cause funds to be compromised, either slashed or inactivity-leaked, but they cannot steal funds, with very few exceptions , such as a special MEV attack where the attacker is slashed for double proposals.

But it’s still not perfect: this rare and special attack is possible, and it’s not clear that oracles are willing to be stakers. The legal risks of staking appear to be higher than the legal risks of being an oracle provider, which falls into the clear free speech “information only” category in many jurisdictions. This also creates a greater incentive to attack them.DVT 。

Idea 2: Oracles as 2-of-2 stakers

• This is an alternative that allows users to retain more control and trust less in oracles. Instead of the pledge key belonging to the oracle, the pledge 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 characteristics of BLS signatures, the oracle machine can sign with Q, the CDP holder can sign with P itself, and add the two signatures together to create a signature that verifies P + Q. This is basically 2-of-2

• This enforces the trust property as follows:

• The oracle alone cannot confiscate CDP holders;

• The oracle itself cannot carry out proposer attacks, because the block proposal requires the signature of the CDP holder;

• CDP holders cannot be slashed or attacked, so cannot compromise the system's collateral in this way;

The oracle or CDP holder can go offline; in this case, the other party will trigger an exit and exit the CDP with little loss;

The extreme case is when an oracle or CDP holder goes offline during an inactivity leak. In this case, either party may cause the other party to suffer losses.

• implement

• This design is a special case of DVT:

• This is 2-of-2, so it's the simplest case from a networking perspective;

1 of 2 (Oracle) is serving thousands of partners. However, it can simply sign the same data and publish it for download to all CDPs it works with;

To keep block production autonomous, in this specific case it can use a system where proposers choose what to sign and send it to oracles for co-signing. Oracles should not sign two different pieces of data in the same slot in the same domain at the same time, as this may combine with blinding tricks to slash the CDP.

This is new technology that needs to be implemented, so it may take the cooperation of the DVT team to actually make it happen. Once built, it shouldn't be too difficult to operate.

Weaknesses of idea 2

The biggest vulnerability of this system is inactivity leaks, as these may only be triggered by the oracle offline. However, I think it's okay to accept that risk. If the balance falls below 16 ETH, the validator will automatically exit and withdraw ETH. Therefore, instead of offering 1.5x regular ETH, we could simply accept ETH staked with a 2x collateral requirement.PufferThere is an edge case where if many validators leak at the same time, only a few can exit at a time, so some validators are further punished for leaks below 16 ETH, but this is a possible change in the ethereum staking protocol if there is demand . Even without a fix, it would take a very extreme attack (more than 50% offline), with a massive validator leak well below 16 ETH before the proportion of balances controlled by honest validators returns to more than 2/3.

Another major drawback is that it doesn't work well in a world where the main concern is not malicious oracle slashing, but malicious or inadvertent oracles going offline. This could be because we either (i) expect oracles to be low-quality stakers because we optimize for honesty rather than technical proficiency, or (ii) oracles use trusted hardware and users accept that this is a (partial) trust assumptions (see

). To address these weaknesses, we propose Idea 3 below.

Idea 3: Semi-trusted oracles for hierarchical security

In cases where you can guarantee that the majority of oracles are honest, the other approach removes the remaining trust issues.
We define three constants:
N: total number of oracles in the oracle system;

k 1 : Number of oracles that can sign messages with the CDP holder (e.g. k 1 ~= 0.2 * N)

• k 2 : Number of oracles that can work together to sign messages without a CDP holder (e.g. k 2 ~= 0.8 * N)

• We require the oracle to maintain two secret shared keys:

Q1, in k 1-of-N secret sharing

P + Q2, in k 2-of-N secret sharing (the latter one for each CDP holder)

• For Q1, the oracle can co-sign with the CDP holder, and for Q2, they can independently sign.

• In the case k 1 + k 2 = N (e.g. k 1 = N/5 and k 2 = 4 N/5 ), this ensures that no slashing and inactivity leaks occur in either case:

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

at least k 1 oracles are honest, and the CDP holders are honest (since the two groups can sign messages together, while the rest of the oracles cannot sign nor block them);

This style is similar to Rollup's Phase 1 training wheels, creating a linear mix between the two security models as a way to partially trust both but not overly trust one.

• Note that this design can be seen as a generalization of ideas 1 and 2 (or even the "CDP holders can sign themselves" proposal): k 1 and k 2 can be tuned as needed to explore the whole space of tradeoffs in who to trust .

• General benefits of these approaches (idea 1 of 2 or 3)

• Credible and neutral, and does not introduce external dependencies: it only trusts participants, and it has been given a higher degree of trust;

Realize the benefits that users can pledge and hold CDP at the same time;

• Avoid unnecessarily facilitating the network effects of existing liquid collateralized derivatives. Instead, the stablecoins maintained by the program are (stable) liquid collateralized derivatives.

• Compare Idea 1, Idea 2, and Idea 3

• Ranked by ease of implementation, idea 1 > idea 2 > idea 3

• Ranked by preventing bad oracles, idea 3 > idea 2 > idea 1

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