Special thanks to Mike Neuder, Justin Drake and others for feedback and review. See also: earlier posts on similar themes by @mikeneuder/goldilocks">Mike Neuder, Dankrad Feist and arixon.eth.
The Ethereum status quo can be described as including a large share of emergent two-tiered staking. By two-tiered staking, I mean here a staking model where there are two classes of participants:
This emergent two-tiered staking arises through the actions of a large share of stakers who participate in staking pools which offer liquid staking tokens (LSTs), eg. Rocket Pool and Lido.
The status quo has two main flaws:
This post will describe possible solutions to both of these issues. It will particularly take the following angle: suppose that we take it as a given that most capital is held by people who are not willing to personally run staking nodes in their current form, signing messages every slot and locking their deposits and subjecting them to slashing. What other role can they have that meaningfully contributes to the decentralization and security of the network?
The two most popular decentralized staking pools today, Lido and RocketPool, are both creating emergent two-tiered staking ecosystems. In Lido’s case, the tiers are:
In Rocket Pool’s case, the tiers are:
In these systems (or new systems enabled by potential future protocol changes), one key question to ask is: from the protocol’s perspective, what is the point of having delegators at all?
To see why the question is meaningful, let us consider the following world. The protocol change proposed in this recent post, of limiting slashing penalties to 2 ETH, is implemented. Rocket Pool reduces the node operator deposit to 2 ETH in response. The market share of Rocket Pool increases to 100% (not just among stakers, but also among ETH holders: as rETH becomes risk-free, almost all ETH holders become rETH holders or node operators).
Let’s suppose that rETH holders get a return of 3% (including both in-protocol rewards and priority fees + MEV) and node operators get a return of 4%. Let’s also suppose that the total supply of ETH is 100 million.
Here’s how the math works out. To avoid dealing with compounding, we’ll look at daily returns instead of yearly, so that second-order terms become small enough to be ignorable:
Now, let us consider a different world. Rocket Pool does not exist. Each staker’s minimum deposit is reduced to 2 ETH, and the total quantity of staked ETH is capped at 6.25M. Also, the node operator’s return is decreased to 1%. Let’s do the math:
Now, let us consider the two situations from a cost-of-attack perspective. In the first case, attackers would not sign up as delegators: delegators have no power, so there is no point. Hence, they would put all of their ETH toward signing up as node operators. To get to 1/3 of all the stake, they would need to put in 2.08M ETH (which, to be fair, is still quite a lot! eg. see @vbuterin/single_slot_finality#Idea-1-super-committees">this discussion on super-committees, a staking scaling proposal which would have also decreased the cost of attack to a similar value). In the second case, attackers would just stake, and to get to 1/3 of all the stake, they would need to put in… 2.08M ETH.
From both a staking economics perspective, and a cost-of-attack perspective, the final outcome in both cases is exactly the same. The share of the total ETH supply held by a node operator increases by 0.00256% per day, and the share of the total ETH supply held by a non-node-operator decreases by 0.00017% per day. The cost of attack is 2.08 million ETH. Hence, it feels like in this model delegation becomes a pointless Rube Goldberg machine: we might as well cut out the middleman, and drastically reduce staking rewards and cap total ETH staked to 6.25M.
The purpose of this argument is not to advocate reducing staking rewards by 4x and capping total staked ETH to 6.25m. Rather, it is to point out a key property that a well-functioning staking system should have: namely, delegators should be doing something that actually matters. Furthermore, it’s okay if delegators are motivated to act correctly to a large degree by community pressure and altruism; after all, that’s the main force that is motivating people to stake in decentralized security-increasing (but higher-effort) ways rather than centralized security-threatening (but lower-effort) ways today.
I see two classes of answers:
There are three ways to expand delegate selection powers:
Voting within pools does not really exist today: in Rocket Pool, anyone can become a node operator, and in Lido, it’s LDO holders that vote, not ETH holders. Lido has a proposal for LDO + stETH dual governance, which would give stETH holders a say in the sense that they could activate a gadget that blocks new votes and hence blocks node operators from being added or removed. That said, this is limited, and could be much stronger.
Cross-pool competition exists today, but is weak. The main challenge is that smaller staking pools’ staking tokens are (i) less liquid, (ii) harder to trust, and (iii) less supported by applications.
We can improve on the first two issues by capping slashing penalties to a smaller amount, eg. 2 or 4 ETH. The remaining (unslashable) ETH could then be safely deposited and withdrawn instantly, making an LST based on that ETH two-way convertible with ETH even for the smallest pools. We could improve on the third issue by creating a central issuing contract for LSTs - somewhat similar to ERC-4337 and ERC-6900 for wallets, such that we can guarantee that any staking token issued through that contract is safe. Applications (eg. a version of RAI that supports staked ETH) could be strongly encouraged to support all staking tokens issued through this registry.
Enshrined delegation currently does not exist in-protocol, but could potentially be introduced. It would involve similar logic to the ideas above, but implemented at protocol level. See this post for pros and cons of enshrining things.
All of these ideas are an improvement over the status quo, but there is a limit to how much benefit they can provide. Token voting governance sucks, and ultimately any form of unincentivized delegate selection is just a type of token voting; this has been my main source of discomfort with delegated proof of stake since the beginning. Hence, it seems valuable to also think about enabling stronger forms of consensus participation.
There are limits to the current approach to solo staking, even without taking the current issues around liquid staking into account. Assuming single-slot finality, our best estimates suggest a limit of ~100k - 1M BLS signatures that could be processed per slot, and that’s assuming a significant increase in slot time. Even if we use recursive SNARKs to aggregate signatures, signing accountability (for slashing purposes) requires a bitfield of who participated to be available for each signature. If Ethereum becomes a global-scale network, then even somehow using full danksharding to store the bitfields would not be enough: 16 MB per slot would only support ~64 million stakers.
Here, from that perspective as well, there is value in splitting up staking into a higher-complexity slashable tier, which acts every slot but perhaps only has 10,000 participants, and a lower-complexity tier that only gets called up to participate occasionally. The lower-complexity tier could be exempt from slashing entirely, or it could randomly give its participants opportunities to temporarily (ie. for a few slots) deposit and become subject to slashing.
In practice, this could be implemented by @mikeneuder/eip-7251-faq">raising the validator balance cap, and later implementing a balance threshold (eg. 2048 ETH) to determine which existing validators enter the higher vs lower complexity tier.
Here are a few ideas for how these small-staking roles could work:
These small-staking roles all have in common that they do not involve actively participating in each slot, are not slashable (and so have very low key management risk), and are very “light” in the sense that they do not even require a full node to run. Verifying the consensus layer only would be sufficient. Hence, they could be implemented through apps or browser plugins that are mostly passive and have very low computational overhead, hardware requirements or technical know-how requirements, all without even assuming technical advances like ZK-EVMs.
These small-staking roles also all have a common goal: they prevent a 51% majority of node operators from engaging in transaction censorship. The first and second also prevent a majority from engaging in finality reversion. The third focuses more directly on censorship, though it’s more vulnerable to the possibility that a node operator majority will also choose to censor inclusion list provider confirmation messages.
These ideas were written from the perspective of an enshrined two-tiered staking solution implemented in protocol, but they could also be implemented as staking pool features. Here are some concrete implementation ideas:
If done right, tweaks to the staking design could solve two birds with one stone:
For a lot of these solutions, there are different layers of abstraction where the solution to the problem could live: powers granted to users within a staking pool protocol, user choice between staking pool protocols, and in-protocol enshrinement. This choice should be considered carefully, and minimal viable enshrinement, minimizing both protocol complexity and level of change to protocol economics while still achieving the desired goal, is generally best.
Special thanks to Mike Neuder, Justin Drake and others for feedback and review. See also: earlier posts on similar themes by @mikeneuder/goldilocks">Mike Neuder, Dankrad Feist and arixon.eth.
The Ethereum status quo can be described as including a large share of emergent two-tiered staking. By two-tiered staking, I mean here a staking model where there are two classes of participants:
This emergent two-tiered staking arises through the actions of a large share of stakers who participate in staking pools which offer liquid staking tokens (LSTs), eg. Rocket Pool and Lido.
The status quo has two main flaws:
This post will describe possible solutions to both of these issues. It will particularly take the following angle: suppose that we take it as a given that most capital is held by people who are not willing to personally run staking nodes in their current form, signing messages every slot and locking their deposits and subjecting them to slashing. What other role can they have that meaningfully contributes to the decentralization and security of the network?
The two most popular decentralized staking pools today, Lido and RocketPool, are both creating emergent two-tiered staking ecosystems. In Lido’s case, the tiers are:
In Rocket Pool’s case, the tiers are:
In these systems (or new systems enabled by potential future protocol changes), one key question to ask is: from the protocol’s perspective, what is the point of having delegators at all?
To see why the question is meaningful, let us consider the following world. The protocol change proposed in this recent post, of limiting slashing penalties to 2 ETH, is implemented. Rocket Pool reduces the node operator deposit to 2 ETH in response. The market share of Rocket Pool increases to 100% (not just among stakers, but also among ETH holders: as rETH becomes risk-free, almost all ETH holders become rETH holders or node operators).
Let’s suppose that rETH holders get a return of 3% (including both in-protocol rewards and priority fees + MEV) and node operators get a return of 4%. Let’s also suppose that the total supply of ETH is 100 million.
Here’s how the math works out. To avoid dealing with compounding, we’ll look at daily returns instead of yearly, so that second-order terms become small enough to be ignorable:
Now, let us consider a different world. Rocket Pool does not exist. Each staker’s minimum deposit is reduced to 2 ETH, and the total quantity of staked ETH is capped at 6.25M. Also, the node operator’s return is decreased to 1%. Let’s do the math:
Now, let us consider the two situations from a cost-of-attack perspective. In the first case, attackers would not sign up as delegators: delegators have no power, so there is no point. Hence, they would put all of their ETH toward signing up as node operators. To get to 1/3 of all the stake, they would need to put in 2.08M ETH (which, to be fair, is still quite a lot! eg. see @vbuterin/single_slot_finality#Idea-1-super-committees">this discussion on super-committees, a staking scaling proposal which would have also decreased the cost of attack to a similar value). In the second case, attackers would just stake, and to get to 1/3 of all the stake, they would need to put in… 2.08M ETH.
From both a staking economics perspective, and a cost-of-attack perspective, the final outcome in both cases is exactly the same. The share of the total ETH supply held by a node operator increases by 0.00256% per day, and the share of the total ETH supply held by a non-node-operator decreases by 0.00017% per day. The cost of attack is 2.08 million ETH. Hence, it feels like in this model delegation becomes a pointless Rube Goldberg machine: we might as well cut out the middleman, and drastically reduce staking rewards and cap total ETH staked to 6.25M.
The purpose of this argument is not to advocate reducing staking rewards by 4x and capping total staked ETH to 6.25m. Rather, it is to point out a key property that a well-functioning staking system should have: namely, delegators should be doing something that actually matters. Furthermore, it’s okay if delegators are motivated to act correctly to a large degree by community pressure and altruism; after all, that’s the main force that is motivating people to stake in decentralized security-increasing (but higher-effort) ways rather than centralized security-threatening (but lower-effort) ways today.
I see two classes of answers:
There are three ways to expand delegate selection powers:
Voting within pools does not really exist today: in Rocket Pool, anyone can become a node operator, and in Lido, it’s LDO holders that vote, not ETH holders. Lido has a proposal for LDO + stETH dual governance, which would give stETH holders a say in the sense that they could activate a gadget that blocks new votes and hence blocks node operators from being added or removed. That said, this is limited, and could be much stronger.
Cross-pool competition exists today, but is weak. The main challenge is that smaller staking pools’ staking tokens are (i) less liquid, (ii) harder to trust, and (iii) less supported by applications.
We can improve on the first two issues by capping slashing penalties to a smaller amount, eg. 2 or 4 ETH. The remaining (unslashable) ETH could then be safely deposited and withdrawn instantly, making an LST based on that ETH two-way convertible with ETH even for the smallest pools. We could improve on the third issue by creating a central issuing contract for LSTs - somewhat similar to ERC-4337 and ERC-6900 for wallets, such that we can guarantee that any staking token issued through that contract is safe. Applications (eg. a version of RAI that supports staked ETH) could be strongly encouraged to support all staking tokens issued through this registry.
Enshrined delegation currently does not exist in-protocol, but could potentially be introduced. It would involve similar logic to the ideas above, but implemented at protocol level. See this post for pros and cons of enshrining things.
All of these ideas are an improvement over the status quo, but there is a limit to how much benefit they can provide. Token voting governance sucks, and ultimately any form of unincentivized delegate selection is just a type of token voting; this has been my main source of discomfort with delegated proof of stake since the beginning. Hence, it seems valuable to also think about enabling stronger forms of consensus participation.
There are limits to the current approach to solo staking, even without taking the current issues around liquid staking into account. Assuming single-slot finality, our best estimates suggest a limit of ~100k - 1M BLS signatures that could be processed per slot, and that’s assuming a significant increase in slot time. Even if we use recursive SNARKs to aggregate signatures, signing accountability (for slashing purposes) requires a bitfield of who participated to be available for each signature. If Ethereum becomes a global-scale network, then even somehow using full danksharding to store the bitfields would not be enough: 16 MB per slot would only support ~64 million stakers.
Here, from that perspective as well, there is value in splitting up staking into a higher-complexity slashable tier, which acts every slot but perhaps only has 10,000 participants, and a lower-complexity tier that only gets called up to participate occasionally. The lower-complexity tier could be exempt from slashing entirely, or it could randomly give its participants opportunities to temporarily (ie. for a few slots) deposit and become subject to slashing.
In practice, this could be implemented by @mikeneuder/eip-7251-faq">raising the validator balance cap, and later implementing a balance threshold (eg. 2048 ETH) to determine which existing validators enter the higher vs lower complexity tier.
Here are a few ideas for how these small-staking roles could work:
These small-staking roles all have in common that they do not involve actively participating in each slot, are not slashable (and so have very low key management risk), and are very “light” in the sense that they do not even require a full node to run. Verifying the consensus layer only would be sufficient. Hence, they could be implemented through apps or browser plugins that are mostly passive and have very low computational overhead, hardware requirements or technical know-how requirements, all without even assuming technical advances like ZK-EVMs.
These small-staking roles also all have a common goal: they prevent a 51% majority of node operators from engaging in transaction censorship. The first and second also prevent a majority from engaging in finality reversion. The third focuses more directly on censorship, though it’s more vulnerable to the possibility that a node operator majority will also choose to censor inclusion list provider confirmation messages.
These ideas were written from the perspective of an enshrined two-tiered staking solution implemented in protocol, but they could also be implemented as staking pool features. Here are some concrete implementation ideas:
If done right, tweaks to the staking design could solve two birds with one stone:
For a lot of these solutions, there are different layers of abstraction where the solution to the problem could live: powers granted to users within a staking pool protocol, user choice between staking pool protocols, and in-protocol enshrinement. This choice should be considered carefully, and minimal viable enshrinement, minimizing both protocol complexity and level of change to protocol economics while still achieving the desired goal, is generally best.