Vitalik’s latest research How to resolve the risks brought by a large number of double staking in Ethereum?

Original Title: “Protocol and staking pool changes that could improve decentralization and reduce consensus overhead”

Author: Vitalik Buterin

Translation: bayemon.eth, ChainCatcher

Special thanks to Mike Neuder, Justin Drake, and others for their feedback and review. Please also refer to the articles previously published by Mike Neuder, Dankrad Feist, and arixon.eth on similar topics.

• In-depth Analysis of STARK’s Complete Security
• Ordinals gameplay upgraded again, both speculation and artistry flourish.
• Bitcoin Inscriptions and Serial Numbers Important Data, Impact on Bitcoin, and Latest Developments

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

1. Node Operator: Operates nodes and stakes a certain amount of own capital as collateral
2. Delegator: Delegates a certain amount of Ethereum without a minimum requirement and has no additional restrictions on participation other than staking

This emerging two-tiered staking is generated by a large number of liquidity staking token (LST) pools. (Rocket Pool and Lido both operate in this manner).

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

1. Centralization risk of node operators: The current selection mechanism for node operators in all staking pools is still overly centralized
2. Unnecessary consensus burden: Ethereum L1 needs to verify about 800,000 signatures per epoch, which is a significant load for individual slots. In addition, since liquidity staking pools require a significant amount of funds, the network itself does not fully benefit from this load. Therefore, if the Ethereum network can achieve reasonable decentralization and security without each staker signing per period, the community can 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 not willing to personally manage staking nodes in the current form, sign information on each slot, lock deposits, and redistribute them to those whose funds are reduced, what roles can these people still play to make meaningful contributions to the decentralization and security of the network?

How does the current two-tiered staking work?

The two most popular staking pools currently are Lido and RocketPool. For Lido, the two parties involved are:

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

For Rocket Pool, the roles are as follows:

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

Agent Role

In these systems (or in new systems enabled by potential protocol changes in the future), a key question to consider is: From a protocol perspective, what is the purpose of establishing an agent?

To understand the profound significance of this question, let’s first consider the protocol change mentioned in the post, which reduces the penalty limit to 2 ETH. Rocket Pool will also reduce the stake amount for node operators to 2 ETH, and Rocket Pool’s market share will increase to 100% (with rETH becoming risk-free, almost all ETH holders will become rETH holders or node operators).

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

The calculation results are as follows. To avoid compounding calculations, we will calculate the returns on a daily basis:

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

Considering the cost of attacks in these two scenarios, in the first scenario, attackers will not register as agents because agents essentially have no withdrawal rights, so it makes no sense. Therefore, they would use all of their ETH to stake and become node operators. To reach one-third of the total stake, they would need to invest 2.08 million Ether (fairly large, to be honest). In the second scenario, attackers only need to invest funds and would still need to invest 2.08 million Ether to reach one-third of the total stake pool.

From the perspective of staking economics and attack cost, the final results of the two scenarios are exactly the same. The share of ETH held by node operators increases by 0.00256% per day, and the share of ETH held by non-node operators decreases by 0.00017% per day. The attack cost is 2.08 million ETH. Therefore, in this model, agents seem to become a meaningless Rube Goldberg machine, and the rational community even tends to remove intermediaries, significantly reduce staking rewards, and limit the total amount of staked ETH to 6.25 million.

Of course, this article does not advocate reducing the staking rewards by 4 times and fixing the staking cap at 6.25 million. On the contrary, the viewpoint of this article is that a well-functioning staking system should have a key attribute, which is that validators should bear significant responsibilities in the entire system. In addition, if validators are largely motivated by community pressure and altruism to take the right actions, that’s also fine; after all, this is the main driving force behind the promotion of decentralized and highly secure staking solutions today.

The Role of Validators

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

I think there are two types of answers:

• Validator selection: Validators can choose which node operators to delegate their interests to. The “weight” of node operators in the consensus mechanism is proportional to the total staking delegated to them. Currently, the validator selection mechanism is still limited, that is, rETH or stETH holders can withdraw their ETH and switch to different pools, but the actual availability of validator selection can be greatly improved.
• Participation in the consensus mechanism: Delegators can choose to play a certain role in the consensus mechanism, with less responsibility than full subscription and without long withdrawal periods and reduced risks, but still able to balance the role of node operators.

Enhancing Validator Selection Power

There are three ways to enhance validator selection power:

1. Improving voting tools in the pools
2. Increasing competition between pools
3. Fixing the representation right

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

Cross-pool competition already exists today, but it is relatively weak. The main challenge is that staked tokens in smaller staking pools 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 amount to a smaller quantity, such as 2 or 4 ETH. Then, the remaining ETH can be safely deposited and withdrawn immediately, allowing two-way exchange to still be viable for smaller staking pools. We can improve the third issue by creating a master issuance contract, similar to ERC-4337 and ERC-6900 contracts for wallets, so that we can ensure that any staked tokens issued through this contract are secure.

Currently, there is no solidified representation of power in the protocol, but such a scenario seems possible in the future. It would involve implementing similar logic to the above ideas at the protocol level. For the advantages and disadvantages of solidified things, please refer to this article.

These ideas are all improvements to the current situation, but the advantages they can provide are limited. Token voting governance has its issues, and ultimately any form of non-incentivized delegate selection is simply 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 more powerful forms of consensus participation.

Consensus Participation

Even without considering the current issues with liquid staking, there are limitations to the current independent staking approach. Assuming the use of 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 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 would not be sufficient: the 16 MB in each slot can only support around 64 million stakers.

From this perspective, it is valuable to divide staking into higher complexity withdrawal layers and lower complexity layers, with the higher complexity layer being effective for each slot, but possibly only involving 10,000 participants, while the lower complexity layer is only occasionally called upon to participate. The lower complexity layer can be completely exempt from withdrawal, or participants can be randomly given the opportunity to deposit and become a withdrawal object 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 complexity or lower complexity layer.

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

1. Each slot, 10,000 small stakeholders are randomly selected who can sign what they believe to be representative of that slot’s content. Use small stakeholders as input to run the LMD GHOST fork selection rules. If there are certain discrepancies between fork selection driven by small stakeholders and fork selection driven by node operators, the user’s client will not accept any block as final confirmation and display an error. This forces the community to intervene to resolve the situation.
2. Delegates can send transactions to announce their online presence and willingness to serve as small stakeholders in the next hour. The message (block or proof) sent by the node for calculation requires both the node’s confirmation and the confirmation of a randomly selected delegate to sign.
3. Delegates can send transactions to announce their online presence and willingness to serve as small stakeholders in the next hour. Each period, 10 random delegates are selected as inclusion list providers, and 10,000 more delegates are selected as voters. These are selected before the k-slot and given a k-slot window to publish messages confirming their online presence on the chain. Each confirmed inclusion list provider can publish an inclusion list, and unless for each inclusion list either the transactions included in that inclusion list or the general 1-vote of the selected voters are included, showing that the inclusion list is not available, the block will be considered invalid.

These small staking nodes have one thing in common: they do not need to actively participate in every slot, and they can even complete all the work with just a light node. Therefore, node deployment only needs to verify the consensus layer, and node operators can achieve this through applications or browser plugins. These applications or browser plugins are mostly passive and have low requirements for computational overhead, hardware, or technical tricks, and they don’t even require advanced technologies like ZK-EVM.

These “small roles” all have a common goal: to prevent 51% of majority node operators from conducting transaction censorship. The first and second types also prevent the majority from participating in finality reversion. The third type more directly focuses on censorship, but it is more susceptible to the influence of majority node operators’ choices.

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

1. From the protocol perspective, each validator can set two staking keys: a continuous staking key P, which is bound to a callable Ethereum address, and an output quick staking key Q. The node tracks the signed information for fork selection with P and the signed information with Q. If the PQ storage results are inconsistent, no block will be accepted as the final determination, and the liquidity pool will be responsible for randomly selecting representatives.
2. The protocol can remain largely unchanged, but the public key of the validator for that period will be set as P+Q. Note that for unstaking, two unstakeable messages may have different Q keys, but they will have the same P key; the unstaking 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 a block. In this case, Q can be a smart contract instead of a single key, so the staking pool can use it to implement more complex voting logic, accepting the inclusion list from randomly selected providers or votes when enough representatives of the inclusion list are unavailable.

Conclusion

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

1. It provides an opportunity for those who do not have the resources or ability to independently stake today to participate in staking and thus retain more power in their hands, including the power to (i) choose which nodes to support and (ii) actively participate in consensus in a way that is more lightweight but still meaningful than fully operating a proof-of-stake node. Not all participants will choose one or both options, but any participant who chooses one or both options will have a significant improvement compared to the current situation.
2. Reduce the number of signatures that the Ethereum consensus layer needs to process in each slot, even under a single-slot finality regime, to a smaller number like around 10,000. This will also help decentralization and make it easier for everyone to run validation nodes.

For these solutions, methods to solve the problem can be found at different abstraction levels: granting permissions to users within the Proof of Stake protocol, user selection between Proof of Stake protocols, and establishment within the protocol. This choice should be carefully considered, and it is usually best to choose the minimum viable establishment to minimize the complexity of the protocol and the degree of change to the protocol’s economics, while still achieving the desired goals.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.