Original author: Vitalik Buterin
Original compilation: bayemon.eth, ChainCatcher
Special thanks to Mike Neuder, Justin Drake, and others for their feedback and reviews. See also: Mike Neuder, Dankrad Feist, and arixon.eths earlier posts on similar topics.
The current development status of Ethereum can be said to include a large number of double-tiered staking. The double-tiered staking mentioned here refers to a staking model with two types of participants.
Node Operator: Operates a node and uses its own reputation or a certain amount of its own capital as collateral.
Agent Delegator: Agents pledge a certain amount of Ethereum, with no minimum amount and no additional restrictions on other participation methods other than collateral.
This emerging double staking is generated through heavy participation in staking pools that provide liquidity for staking tokens (LST). (Both Rocket Pool and Lido have this model).
However, the current double pledge has two flaws:
Centralization risk of node operators: The current selection mechanism of node operators in all staking pools is still overly centralized.
Unnecessary consensus burden: Ethereum L1 needs to verify approximately 800,000 signatures per Epoch, which is a huge load for a single slot. Additionally, since liquidity staking pools require more funds, 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 according to the period, then the community can adopt such a solution, effectively reducing the number of signatures per period.
This article will describe a solution to the above two problems. First, it is assumed that most of the capital is held by those who are unwilling to personally manage the staking nodes in their current form, sign the information on each slot, lock the deposits and redistribute them to those whose funds have been reduced. So in this case, what role can these people play to still make a meaningful contribution to the decentralization and security of the network?
How does double collateral work currently?
Currently, the two most popular staking pools are Lido and RocketPool. As far as Lido is concerned, the two participating parties are:
Node operator: Voted by Lido DAO, which means that it is actually elected by LDO holders. When someone deposits ETH into the Lido smart contract system, stETH will be created, and the node operator can It is put into the pledge pool (but because the withdrawal certificate is bound to the smart contract address, the operator cannot withdraw money at will)
Agent: When someone deposits ETH in the Lido smart contract system, stETH will be generated, and the node operator can use it as a pledge (but because the withdrawal certificate is bound to the smart contract address, the operator cannot withdraw money at will)
For Rocket Pool, they are:
Node Operator: Anyone can become a node operator by submitting 8 ETH and a certain number of RPL tokens.
Agent: When someone deposits ETH into the Rocket Pool smart contract system, rETH will be generated, and the node operator can use it as a pledge (also because the withdrawal certificate is bound to the smart contract address, the operator cannot withdraw money at will).
agency role
In these systems (or in new systems enabled by potential future protocol changes), a key question to ask is: what is the point of having an agent from a protocol perspective?
In order to understand the profound significance of this question, let us first think about the protocol changes mentioned in the post, which will limit the reduction penalty to 2 ETH. Rocket Pool will also reduce the stake amount of node operators to 2 ETH, and Rocket Pool’s market Shares 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 a 3% return for rETH holders (including in-protocol rewards and priority fees + MEV) and a 4% return for node operators. We also assume that the total supply of ETH is 100 million.
The calculation results 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 drops to 2 ETH per staker, total liquidity is capped at 6.25 million ETH, and node operator returns drop to 1%. Let’s calculate again:
Consider both scenarios from an attack cost perspective. In the first case, the attacker will not register as an agent because the agent essentially does not have any rights to withdraw money, so it is meaningless. Therefore, they will stake all their ETH and become node operators. To reach 1/3 of the total staked amount, they would need to stake 2.08 million Ethereum (which, to be fair, is still a pretty large number). In the second case, the attacker would only have to stake funds to reach the staking pool 1/3 of the total amount, they still need to invest 2.08 million Ethereum.
From a staking economics and attack cost perspective, the end result in both cases is exactly the same. The share of total ETH supply held by node operators increases by 0.00256% per day, and the share of total ETH supply held by non-node operators decreases by 0.00017% per day. The cost of the attack is 2.08 million ETH. Therefore, in this model, the agent seems to be a meaningless Rube Goldberg machine, and the rational community is even inclined to cut out the middleman, 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 reward by 4 times and limiting the total staking amount to 6.25 million. Rather, the point of this article is that a key attribute of a well-functioning staking system is that agents should have significant responsibilities throughout the system. Furthermore, it wouldn’t matter if agents were motivated in large part by community pressure and altruism to take the right actions; after all, that’s what incentivizes decentralized, high-security staking solutions today major force.
Agents responsibilities
If agents could play a meaningful role in the staking system, what might that role be?
I think there are two categories of answers:
Agent Selection: Agents can choose which node operators to entrust their stakes to. Node operators’ role in the consensus mechanism"Weights"Proportional to the total stake entrusted to them. Currently, the agent selection mechanism is still limited, i.e. rETH or stETH holders can withdraw their ETH and switch to a different pool, but the actual availability of agent selection could be greatly improved.
Consensus mechanism participation: Delegators can choose to play a certain role in the consensus mechanism. The responsibility is lighter than full subscription, and there will be no long exit period and risk reduction, but it can still act as a check and balance for node operators. effect.
Enhance agency options
There are three ways to increase your representative’s power to choose:
Improved voting tools in the pool
Increase competition between pools
Fix the right of representation
Currently, voting in the pool is not actually practical: in Rocket Pool, anyone can become a node operator, and in Lido, voting is decided by LDO holders, not ETH holders. Lido has put forward a proposal for dual governance of LDO + stETH. They can activate a protection mechanism to prevent new votes and thus prevent node operators from being added or removed. This gives stETH holders a say to some extent. . Still, this power is limited and can be more powerful.
Cross-pool competition already exists today, but is relatively weak. The main challenge is that the staking tokens of smaller staking pools are less liquid, harder to gain trust, and less supported by applications.
We can improve the first two problems by limiting the penalty amount to a smaller amount, such as 2 or 4 ETH. The remaining ETH can then be securely deposited and withdrawn immediately, allowing two-way conversions to still hold true for smaller staking pools. We can improve the third problem by creating a total issuance contract for managing LST (similar to the ERC-4337 and ERC-6900 contracts used for wallets) so that we can guarantee any staked tokens issued through this contract All are safe.
Currently, there are no solid representative powers in the agreement, but such a situation seems likely to exist in the future. It will involve similar logic to the above idea, but implemented at the protocol level. For more information on the pros and cons of solidifying things, pleaseSee this article。
These ideas are improvements over the status quo, but they offer limited advantages. There are issues with token voting governance, and ultimately any form of non-incentivized proxy selection is just a form of token voting; this has always been my main gripe with Delegated Proof of Stake. Therefore, it is also valuable to consider ways to achieve stronger consensus participation.
consensus participation
Even setting aside the current issues with liquidity staking, there are limitations to current independent staking methods. Assuming single-slot finality, each slot might ideally handle approximately 100,000 to 1,000,000 BLS signatures. Even if we use recursive SNARKs to aggregate signatures, for signature traceability we need to give each signature a participants bitfield. If Ethereum becomes a global-scale network, fully decentralizing the storage bitfield will also not be enough: 16 MB in each slot can only support about 64 million stakers.
From this perspective, there is value in dividing staking into higher complexity reducible tiers and lower complexity tiers, where each slot will be active but may only have 10,000 participants. or, lower complexity layers are only occasionally called to participate. Lower complexity layers could be completely exempt from reductions, or participants could be randomly given the opportunity to deposit within a few slots and become subject to reductions.
In practice, this can be achieved by increasing the validator balance cap and subsequently increasing the balance threshold (e.g., 2048 ETH) to determine which existing validators move into higher or lower complexity tiers.
Here are some suggestions on how these small staking roles might work:
For each slot, 10,000 small stakers are randomly selected and can sign what they believe represents that slot. Run the LMD GHOST fork selection rule using small stakers as input. If there is some disagreement between the fork selection driven by small stakers and the fork selection driven by node operators, the users client will not accept any block as final confirmation and display an error. This forces the community to step in to resolve the situation.
Agents can send transactions announcing to the network that they are online and willing to serve as small stakers for the next hour. The calculation of the message (block or proof) sent by the node requires both the node and a randomly selected agent to sign the nodes confirmation information.
Agents can send transactions announcing to the network that they are online and willing to serve as small stakers for the next hour. Each epoch, 10 random agents are selected as inclusion list providers, and 10,000 more agents are selected as voters. These are selected before k-slots and given a k-slot window to publish a message on-chain confirming their online presence. Each confirmed selected inclusion list provider may publish an inclusion list, except that for each inclusion list, either the transactions in that inclusion list are included, or a vote of a general 1 selected electorate indicates that the inclusion list is unavailable , otherwise the block will be considered invalid.
What these small staking nodes have in common is that they do not need to actively participate in every slot, or even just light nodes to do all the work. Therefore, node deployment only requires verification of the consensus layer, which node operators can achieve through applications or browser plug-ins, which are mostly passive and impose no computational overhead, hardware requirements, or technical know-how. Very low and does not even require advanced technology like ZK-EVM.
These “minor actors” also all share a common goal: preventing transaction censorship by the 51% majority of node operators. The first and second also prevent the majority from participating in the finality reduction. The third is more directly concerned with censorship, but it is more susceptible to the choices of majority node operators.
These ideas are written from the perspective of a double staking solution implemented into the protocol, but they can also be implemented as a feature of staking pools. Here are some specific implementation ideas:
From a protocol perspective, each validator can set two pledge keys: a continuous pledge key P, and a bound Ethereum address that can be called, and output a quick pledge key Q. The node’s signature information tracking for fork selection is represented by P, and the signed information is represented by Q. If the PQ storage results are inconsistent, the finalization of any block will not be accepted, and the liquidity pool will be responsible for randomly selecting a representative.
The protocol can remain largely unchanged, but the validators public key for that period will be set to P+Q. Note that for reductions, two reductionable messages may have different Q-keys, but they will have the same P-key; the reduction design needs to handle this case.
Q keys 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 the staking pool can use it to implement more complex voting logic, accepting an inclusive list from a randomly selected provider or enough Indicates that the containing list is unavailable for votes.
in conclusion
If implemented correctly, fine-tuning the proof-of-stake design can solve two problems in one fell swoop:
Provides those who do not have the resources or ability to do independent Proof of Stake today an opportunity 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) Actively participate in consensus in some way that is lighter but still meaningful than operating a full proof-of-stake node. Not all participants will choose one or both of these options, but any participant who chooses one or both of these options will experience a significant improvement over the status quo.
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 about 10,000. This will also help with decentralization, making it easier for everyone to run validating nodes.
For these solutions, solutions to the problem can be found at different levels of abstraction: permissions granted to users within proof-of-stake protocols, user selection between proof-of-stake protocols, and establishment within the protocols. This choice should be carefully considered, and it is often better to choose a minimum viable setup to minimize the complexity of the protocol and the extent of changes to the protocol economics, while still achieving the desired goals.
