Vitalik's latest research: How should the LSDFi protocol and liquidity change to enhance decentralization and reduce consensus overload?

Original Title: 《Protocol and staking pool changes that could improve decentralization and reduce consensus overhead》

Author: Vitalik Buterin

Compiled by: bayemon.eth, ChainCatcher

Special thanks to Mike Neuder, Justin Drake, and others for their feedback and review. Also see: articles previously published by Mike Neuder, Dankrad Feist, and arixon.eth on similar topics.

The current state of Ethereum development can be described as containing a large amount of two-tiered staking, which refers to a staking model with two types of participants.

1. Node Operators: Operate nodes and stake a certain amount of their own capital as collateral based on their reputation.
2. Delegators: Delegators stake a certain amount of Ethereum, with no minimum amount required, and there are no additional restrictions on other forms of participation beyond the collateral.

This emerging two-tiered staking is generated through a large number of participants providing liquid staking tokens (LST) in staking pools (both Rocket Pool and Lido operate under this model).

However, the current two-tiered staking has two flaws:

1. Centralization Risk of Node Operators: The selection mechanism for node operators in all staking pools is still overly centralized.
2. Unnecessary Consensus Burden: Ethereum L1 must verify about 800,000 signatures per epoch, which is a significant load for a single slot. Additionally, since liquid staking pools require a large amount of capital, the network itself does not fully benefit from this load. Therefore, if the Ethereum network can achieve reasonable decentralization and security without requiring each staker to sign at each period, the community could adopt such solutions to effectively reduce the number of signatures per period.

This article will describe solutions to the above two problems, first assuming that most capital is held by those who are unwilling to personally manage staking nodes in their current form, sign information at each slot, lock deposits, and redistribute to capital-reduced participants. In this case, what roles can these individuals still play to meaningfully contribute to the network's decentralization and security?

How Does Current Two-Tiered Staking Work?

The two most popular staking pools are Lido and Rocket Pool. In the case of Lido, the two participating parties are:

1. Node Operators: Elected by Lido DAO voting, which means they are effectively chosen by LDO holders. When someone deposits ETH into the Lido smart contract system, stETH is created, which node operators can stake in the pool (but since the withdrawal credentials are bound to the smart contract address, operators cannot withdraw at will).
2. Delegators: When someone deposits ETH into the Lido smart contract system, stETH is generated, which node operators can use as collateral (again, due to the binding of withdrawal credentials to the smart contract address, operators cannot withdraw at will).

For Rocket Pool, the roles are:

1. Node Operators: Anyone can become a node operator by submitting 8 ETH and a certain amount of RPL tokens.
2. Delegators: When someone deposits ETH into the Rocket Pool smart contract system, rETH is generated, which node operators can use as collateral (similarly, due to the binding of withdrawal credentials to the smart contract address, operators cannot withdraw at will).

Role of Delegators

In these systems (or in new systems enabled by future potential protocol changes), a key question that needs to be raised is: What is the significance of establishing delegators from a protocol perspective?

To understand the profound implications of this question, we first consider the protocol changes mentioned in the post, which will reduce penalties to a limit of 2 ETH. Rocket Pool will also reduce the staking amount for node operators to 2 ETH, and Rocket Pool's market share will increase to 100% (for stakers and ETH holders, as rETH becomes risk-free, almost all ETH holders will become rETH holders or node operators).

Assuming the return rate for rETH holders is 3% (including protocol rewards and priority fees + MEV), and the return rate for node operators is 4%. We also assume the total supply of ETH is 100 million.

The calculations are as follows. To avoid compound interest calculations, we will calculate returns on a daily basis:

Now, assuming Rocket Pool does not exist, the minimum deposit amount for each staker is reduced to 2 ETH, with a total liquidity cap of 6.25 million ETH, while the return rate for node operators drops to 1%. Let's calculate again:

From the perspective of attack costs, consider these two scenarios. In the first case, attackers will not register as delegators because delegators essentially have no withdrawal rights, making it meaningless. Therefore, they will use all ETH to stake and become node operators. To reach 1/3 of the total staking amount, they need to invest 2.08 million ETH (to be fair, this is still a considerable number). In the second case, attackers only need to invest funds; to reach 1/3 of the total staking pool, they still need to invest 2.08 million ETH.

From the perspective of staking economics and attack costs, the final outcomes of the two scenarios are identical. The total supply share of ETH held by node operators increases by 0.00256% daily, while the total supply share of ETH held by non-node operators decreases by 0.00017%. The attack cost is 2.08 million ETH. Thus, in this model, delegators seem to have become a meaningless Rube Goldberg machine, and a rational community may even lean towards removing intermediaries, significantly reducing staking rewards, and capping the total amount of staked ETH at 6.25 million.

Of course, this article does not advocate for reducing staking rewards by four times while capping the total staking amount at 6.25 million. On the contrary, the argument here is that a well-functioning staking system should possess a key attribute, namely that delegators should bear significant responsibilities within the entire system. Furthermore, if delegators are largely motivated by community pressure and altruism to take the right actions, that is also acceptable; after all, this is the main force driving people to implement decentralized and highly secure staking solutions today.

Responsibilities of Delegators

If delegators can play a meaningful role in the staking system, what might that role be?

I believe there are two types of answers:

• Delegator Choice: Delegators can choose which node operators to delegate their interests to. The "weight" of node operators in the consensus mechanism is proportional to the total stake delegated to them. Currently, the delegator selection mechanism is still limited, as rETH or stETH holders can withdraw their ETH and switch to different pools, but the actual availability of delegator choices can be greatly improved.
• Participation in Consensus Mechanism: Delegators can choose to play a certain role in the consensus mechanism, with responsibilities lighter than full subscription, and without long exit periods and reduction risks, while still serving to check and balance node operators.

Enhancing Delegator Choice

There are three ways to enhance the power of delegator choice:

1. Improve voting tools within the pool.
2. Increase competition between pools.
3. Fix representation rights.

Currently, voting within the pool is not practical: in Rocket Pool, anyone can become a node operator, while in Lido, voting is determined by LDO holders, not ETH holders. Lido has proposed a dual governance proposal of LDO + stETH, which can activate a protection mechanism to prevent new votes, thereby preventing node operators from being added or removed, which somewhat gives stETH holders a voice. Nevertheless, this power is still limited and can be made stronger.

Cross-pool competition exists today but is relatively weak. The main challenge is that smaller staking pools' staking tokens have lower liquidity, are harder to gain trust, and receive less support from applications.

We can improve the first two issues by limiting the penalty amounts to smaller numbers, such as 2 or 4 ETH. Then, the remaining ETH can be safely deposited and immediately withdrawn, allowing for two-way exchanges to remain valid for smaller staking pools. We can improve the third issue by creating a total issuance contract to manage LST (similar to how ERC-4337 and ERC-6900 are used for wallets), ensuring that any staking tokens issued through that contract are secure.

Currently, there is no fixed representation power in the protocol, but such scenarios seem to have potential for the future. It would involve logic similar to the above ideas but implemented at the protocol level. For the pros and cons of fixing things, please see this article.

These ideas are improvements to the status quo, but the advantages they can provide are limited. Token voting governance has issues, and ultimately any form of non-incentivized delegator choice is just a form of token voting; this has always been my main dissatisfaction with delegated proof of stake. Therefore, considering the implementation of more robust consensus participation methods is also valuable.

Consensus Participation

Even without considering the current issues of liquid staking, there are limitations to the current independent staking methods. Assuming the use of single-slot finality, ideally, each slot could handle about 100,000 to 1,000,000 BLS signatures. Even if we use recursive SNARKs to aggregate signatures, to ensure the traceability of signatures, each signature needs to be assigned a participant's bit field. If Ethereum becomes a globally scaled network, fully decentralized storage of bit fields is also insufficient: the 16 MB in each slot can only support about 64 million stakers.

From this perspective, it is valuable to divide staking into higher complexity reducible layers and lower complexity layers, where the higher complexity layer is effective in each slot but may only have 10,000 participants, while the lower complexity layer is only called occasionally to participate. The lower complexity layer can be completely exempt from reduction or can randomly grant participants the opportunity to deposit and become reduction targets within several slots.

In practice, this can be determined by increasing the validator balance cap and then raising the balance threshold (e.g., 2048 ETH) to determine which existing validators enter the higher complexity or lower complexity layers.

Here are some suggestions on how these small staking roles could operate:

1. In each slot, randomly select 10,000 small stakers who can sign what they believe represents that slot. Use small stakers as inputs to run the LMD GHOST fork choice rules. If there is a divergence between the fork choice driven by small stakers and the fork choice driven by node operators, the user's client will not accept any block as final confirmation and will display an error. This forces the community to intervene to resolve the situation.
2. Delegators can send transactions to announce to the network that they are online and willing to serve as small stakers in the next hour. The messages sent by nodes (blocks or proofs) are computed, requiring both the node and a randomly selected delegator to sign the node's confirmation information.
3. Delegators can send transactions to announce to the network that they are online and willing to serve as small stakers in the next hour. In each period, 10 random delegators will be selected as inclusion list providers, and 10,000 more delegators will be selected as voters. These are chosen before the k-slot and given a k-slot window to publish messages on-chain confirming they are online. Each confirmed selection of inclusion list providers can publish an inclusion list, unless for each inclusion list, either the transactions in that inclusion list are included, or a general vote from 1 selected voter shows that the inclusion list is unavailable; otherwise, the block will be considered invalid.

The commonality of these small staking nodes is that they do not need to actively participate in every slot, and even light nodes can complete all the work. Therefore, node deployment only needs to verify the consensus layer, and node operators can achieve this through applications or browser plugins, most of which are passive and have low requirements for computational overhead, hardware, or technical know-how, and do not even require advanced technologies like ZK-EVM.

These "small roles" also share a common goal: to prevent 51% of majority node operators from conducting transaction censorship. The first and second types can also prevent the majority from participating in finality reversion. The third type focuses more directly on censorship but is more susceptible to the choices of majority node operators.

These ideas are written from the perspective of implementing dual staking solutions in the protocol, but they can also be implemented as functions of staking pools. Here are some specific implementation ideas:

1. From a protocol perspective, each validator can set two staking keys: a persistent staking key P, which is bound to an Ethereum address for calls, and outputs a quick staking key Q. The signing information for fork choice by nodes is tracked as P, and the signed information is represented as Q. If the PQ stored results are inconsistent, no block will be accepted as final confirmation, with the liquidity pool responsible for randomly selecting representatives.
2. The protocol can generally remain unchanged, but the public key of the validator during that period will be set to P+Q. Note that for reduction, the two reducible messages may have different Q keys, but they will have the same P key; the reduction design needs to handle this situation.
3. The Q key can only be used in the protocol to sign and verify the inclusion list in the block. In this case, Q can be a smart contract rather than a single key, allowing the staking pool to implement more complex voting logic, accepting inclusion lists from randomly selected providers or sufficient votes indicating that the inclusion list is unavailable.

Conclusion

If implemented correctly, fine-tuning the design of proof of stake can simultaneously address two issues:

1. It provides an opportunity for those who currently lack the resources or capability to engage in independent proof of stake to participate in proof of stake, thereby retaining more power in their hands: including (i) the power to choose which nodes to support and (ii) to actively participate in consensus in a way that is lighter than fully operating a proof of stake node but still meaningful. Not all participants will choose one or both options, but any participant who chooses one or both options will see significant improvements over the status quo.
2. Reduces the number of signatures that the Ethereum consensus layer needs to handle in each slot, even under a single-slot finality regime, to a smaller number like approximately 10,000. This will also help decentralization, making it easier for everyone to run validating nodes.

For these solutions, methods can be found at different levels of abstraction: granting users permissions within the proof of stake protocol, user choices between proof of stake protocols, and establishment within the protocol. Such choices should be considered carefully, and it is generally best to opt for the minimal viable establishment to minimize the complexity of the protocol and the extent of changes to the protocol economics while still achieving the desired goals.