Vitalik's latest research: How must LSDFi protocols and liquidity change to enhance decentralization and reduce consensus overload?

This article will mainly focus on two major challenges currently faced by LSDFi protocols and liquidity pools: the centralization risk of node operators and unnecessary consensus overhead.

Written by:Vitalik Buterin

Translated by: bayemon.eth, ChainCatcher

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

• Node Operator: Operates nodes and stakes a certain amount of their own capital with their reputation as collateral
• Delegator: Delegators stake a certain amount of Ethereum, with no minimum threshold, and there are no additional restrictions on participation methods other than collateral

This emerging two-tiered staking is generated by staking pools that provide liquid staking tokens (LST) through mass participation. (Rocket Pool and Lido both use this model.)

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

• Centralization risk of node operators: The selection mechanism for node operators in all current staking pools remains overly centralized
• Unnecessary consensus overhead: Ethereum L1 needs to verify about 800,000 signatures per epoch, which is a huge load for a single slot. In addition, since liquidity staking pools require more capital, the network itself does not fully benefit from this overhead. Therefore, if the Ethereum network can achieve reasonable decentralization and security without requiring every staker to sign per slot, the community can adopt such solutions to effectively reduce the number of signatures per slot.

This article will describe solutions to the above two problems. First, suppose that most capital is held by those who are unwilling to personally manage staking nodes in the current form, sign messages on every slot, lock deposits, and redistribute to those whose funds are slashed. In this case, what role can these people play to still make meaningful contributions to the decentralization and security of the network?

How does current two-tiered staking work?

The two most popular staking pools at present are Lido and RocketPool. For Lido, the two participating parties are:

• Node Operator: Selected by Lido DAO voting, which means they are actually chosen by LDO holders. When someone deposits ETH into the Lido smart contract system, stETH is created, and node operators can stake it in the pool (but since the withdrawal credentials are bound to the smart contract address, operators cannot withdraw at will)
• Delegator: When someone deposits ETH into the Lido smart contract system, stETH is generated, and node operators can stake it (but since the withdrawal credentials are bound to the smart contract address, operators cannot withdraw at will)

For Rocket Pool, the participants are:

• Node Operator: Anyone can become a node operator by submitting 8 ETH and a certain amount of RPL tokens.
• Delegator: When someone deposits ETH into the Rocket Pool smart contract system, rETH is generated, and node operators can stake it (similarly, since the withdrawal credentials are bound to the smart contract address, operators cannot withdraw at will).

The Role of Delegators

In these systems (or new systems enabled by potential future protocol changes), a key question needs to be raised: from the protocol's perspective, what is the point of having delegators?

To understand the profound significance of this question, let's first consider the protocol change mentioned in the post, namely limiting slashing penalties to 2ETH. Rocket Pool would also reduce the node operator's staking amount to 2ETH, and Rocket Pool's market share would increase to 100% (for stakers and ETH holders, as rETH becomes risk-free, almost all ETH holders would become rETH holders or node operators).

Assume the return rate for rETH holders is 3% (including in-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 calculation is as follows. To avoid compounding, we calculate the returns on a daily basis:

Now, suppose Rocket Pool does not exist, the minimum deposit per staker drops to 2 ETH, the total liquidity cap is 6.25 million ETH, and the node operator return rate drops to 1%. Let's calculate again:

Consider the attack cost in both scenarios. In the first case, attackers would not register as delegators, since delegators essentially have no withdrawal rights, so it is meaningless. Therefore, they would use all their ETH to stake and become node operators. To reach 1/3 of the total staked amount, they would 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, and to reach 1/3 of the total staked pool, they still need to invest 2.08 million ETH.

From the perspective of staking economics and attack cost, the final result in both cases is exactly the same. The share of ETH held by node operators in the total supply increases by 0.00256% per day, while the share held by non-node operators decreases by 0.00017% per day. The attack cost is 2.08 million ETH. Therefore, in this model, delegators seem to be a meaningless Rube Goldberg machine, and a rational community would even tend to remove the middleman, greatly reduce staking rewards, and limit the total staked ETH to 6.25 million.

Of course, this article does not advocate reducing staking rewards by 4 times and capping the total staked amount at 6.25 million. On the contrary, the view here is that a well-functioning staking system should have a key attribute: delegators should bear important responsibilities in the entire system. Moreover, if delegators are largely motivated by community pressure and altruism to take the right actions, that's fine; after all, this is the main force driving the adoption of decentralized, high-security staking solutions today.

The Responsibilities of Delegators

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

I think there are two types of answers:

• Delegator choice: Delegators can choose which node operators to delegate their stake to. The "weight" of node operators in the consensus mechanism is proportional to the total stake delegated to them. Currently, the delegator choice mechanism is still limited, i.e., rETH or stETH holders can withdraw their ETH and switch to a different pool, but the practical availability of delegator choice can be greatly improved.
• Consensus participation: Delegators can choose to play a certain role in the consensus mechanism, with lighter responsibility than full staking, no long exit period or slashing risk, but still able to check and balance node operators.

Enhancing Delegator Choice

There are three ways to enhance delegator choice:

• Improving voting tools within pools
• Increasing competition between pools
• Solidifying delegation rights

Currently, voting within pools is not practical: in Rocket Pool, anyone can become a node operator; in Lido, voting is decided by LDO holders, not ETH holders. Lido has proposed a dual governance proposal for LDO + stETH, where a protection mechanism can be activated to block new votes, thus preventing node operators from being added or removed, which to some extent gives stETH holders a voice. Nevertheless, this power is still limited and could be stronger.

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

We can improve the first two issues by limiting the penalty amount to a smaller number, such as 2 or 4 ETH. Then, the remaining ETH can be safely deposited and withdrawn immediately, allowing two-way redemption to still work for smaller staking pools. We can improve the third issue by creating a total issuance contract to manage LSTs (similar to ERC-4337 and ERC-6900 for wallets), so that we can guarantee any staking token issued through this contract is safe.

Currently, there is no solidified delegation right in the protocol, but such a scenario seems possible in the future. It would involve logic similar to the above ideas but implemented at the protocol level. For the pros and cons of solidifying things, see this article.

These ideas are all improvements over the status quo, but the advantages they can provide are limited. Token voting governance has problems, 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, it is also valuable to consider implementing stronger forms of consensus participation.

Consensus Participation

Even without considering the current issues of liquid staking, there are limitations to the current solo staking approach. Suppose we use single-slot finality, ideally each slot could process about 100,000 to 1,000,000 BLS signatures. Even if we use recursive SNARKs to aggregate signatures, for traceability, each signature needs to be assigned a participant bitfield. If Ethereum becomes a global-scale network, fully decentralized storage of bitfields is still not enough: 16 MB per slot can only support about 64 million stakers.

From this perspective, it is valuable to divide staking into a higher-complexity slashable layer and a lower-complexity layer. The high-complexity layer is effective every slot but may only have 10,000 participants, while the lower-complexity layer is only occasionally called to participate. The lower-complexity layer can be completely slash-free, or participants can be randomly given the opportunity to deposit and become slashable within a few slots.

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

Here are some suggestions on how these small staker roles could work:

• Each slot, 10,000 small stakers are randomly selected, who can sign what they believe represents the slot. Use small stakers as input to run the LMD GHOST fork choice rule. If there is a certain divergence between the fork choice driven by small stakers and that driven by node operators, the user's client will not accept any block as finalized and will display an error. This forces the community to intervene and resolve the situation.
• Delegators can send transactions to the network to announce they are online and willing to serve as small stakers for the next hour. Messages (blocks or attestations) sent by nodes require both the node and a randomly selected delegator to sign the attestation.
• Delegators can send transactions to the network to announce they are online and willing to serve as small stakers for the next hour. Each epoch, 10 random delegators are selected as inclusion list providers, and 10,000 more as voters. These are selected before k slots and given a k-slot window to publish an on-chain message confirming they are online. Each confirmed inclusion list provider can publish an inclusion list, and for each inclusion list, unless the transactions in the list are included or there is a general vote from at least one selected voter indicating the list is unavailable, 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 a light client can do all the work. Therefore, node deployment only needs to verify the consensus layer, and node operators can implement this through applications or browser plugins, most of which are passive, with very low requirements for computational overhead, hardware, or technical know-how, and do not even require advanced technology like ZK-EVM.

These "small roles" also share a common goal: to prevent 51% of the majority node operators from censoring transactions. The first and second can also prevent the majority from participating in finality reversion. The third focuses more directly on censorship, but it is more susceptible to the influence of majority node operator selection.

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

1. From the protocol perspective, each validator can set two staking keys: a persistent staking key P, and a bound callable Ethereum address, outputting a fast staking key Q. The node's fork choice signing information is tracked with P, and the signed information is with Q. If the PQ storage results are inconsistent, no block is accepted as finalized, and the liquidity pool is responsible for randomly selecting representatives.
2. The protocol can largely remain unchanged, but the validator's public key for the period will be set to P+Q. Note that for slashing, two slashable messages may have different Q keys but the same P key; the slashing design needs to handle this situation.
3. The Q key can only be used in the protocol to sign and verify inclusion lists in blocks. In this case, Q can be a smart contract rather than a single key, so staking pools can use it to implement more complex voting logic, accepting inclusion lists from randomly selected providers or enough votes indicating the inclusion list is unavailable.

Conclusion

If implemented correctly, fine-tuning the proof-of-stake design can solve two problems at once:

• Provide an opportunity for those who do not have the resources or ability to independently run proof-of-stake today, allowing them to participate in proof-of-stake and retain 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 but still meaningful compared to fully running a proof-of-stake node. Not all participants will choose one or both options, but any participant who chooses one or both will see significant improvement over the status quo.
• Reduce the number of signatures the Ethereum consensus layer needs to process per slot, even under single-slot finality, down to a smaller number like about 10,000. This will also help decentralization, making it easier for everyone to run validator nodes.

For these solutions, ways to solve the problem can be found at different levels of abstraction: permissions granted to users within the proof-of-stake protocol, user choice between proof-of-stake protocols, and protocol-level setup. This choice should be considered carefully, and it is usually best to choose the minimum viable setup to minimize protocol complexity and changes to protocol economics, while still achieving the desired goals.

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