Nov 7, 2024
Useful Links:
Introduction
At LlamaRisk, we believe the risks associated with staking are not always understood or seriously considered. To better this end, we decided to create an Ethereum Consensus Penalty Simulator (ECPS) that provides a graphical representation of a validator's balance through time when subjected to the different penalties it could suffer from — namely slashing and inactivity leak. With the rise of Liquid Staking Tokens (LST), and more recently Liquid Restaking Tokens (LRT), the risks associated with staking on Ethereum have now entered the DeFi sector. In this article, we explain in depth those penalties and the different network conditions that influence them. We go over different centralization vectors that solo stakers and LST/LRT holders are exposed to through them, and why not all LST/LRTs are equal in that regard.
The Staking Process
Ethereum is secured by validators, which are virtual entities that live on Ethereum and through which stakers participate in the Ethereum consensus. Stakers, directly or indirectly through node operators, use validator clients to hold and use the private key that each validator is associated with. Validators that behave correctly are rewarded, whereas cheating or inactive validators are penalized. Those penalties protect Ethereum against various kinds of attack vectors, and essentially render those attacks unprofitable: this is why stakers are required to provide a 32 ETH bond per validator.
The staking process is linear and can be simplified as a 3 step process:
the entry queue,
the active period, and
the exit queue.
The entry queue and exit queue are inactive periods made to prevent specific attacks on the protocol. Each has a specific rate: the entry queue rate is currently fixed at 8 validators per epoch, whereas the exit queue is variable (currently 16 validators per epoch) and depends on the total amount of active validators. The state of the entry and exit queue can be monitored on validatorqueue.com.
Upon entering the active period, a validator is expected to perform its duties every epoch. Failure to do so will result in a loss of rewards, and in some cases in penalties. Here are the duties expected from an active validator:
Attestations: Attesting to the correct state of the chain at each epoch. Validators are rewarded with a small but consistent reward for doing so.
Block Proposal: A random duty that a validator is expected to perform on average ~2.44 times per year under current conditions. It yields multiple rewards: A basic block proposal reward added to the consensus balance, all transaction tips included in the block on the execution layer, and a potential MEV reward if the validator uses an MEV-enabled third-party block builder.
Sync Committee: 514 validators randomly selected at every 256 epochs (~27 hours). During that time, validators must verify and sign proposed blocks. The probability of being part of a sync committee is very low but yields significant rewards on the consensus layer.
The Consensus Penalties
Now that we presented the validator's duties and their associated rewards, we can delve into our first interest: the consensus penalties. There are essentially two reasons for suffering from consensus penalties, each involving different types of penalties:
committing a slashing offense and
being inactive.
Slashing
Slashing is a condition imposed upon validators who are found to be cheating by other consensus participants. Several actions can result in slashing. Although they are difficult to explain without delving into technicalities, for an honest validator it essentially boils down to two things:
avoiding buggy consensus clients and
making sure not to run two validators with the same validator key.
Avoiding consensus client bugs is impossible. However, because the correlation penalty is proportional to the total share of the network that has been slashed in the 36-day window surrounding the slashing event, using a minority consensus client would result in a lower correlation penalty than using a majority consensus client. For instance, a buggy consensus client with a share greater than 1/3 of the network (like Prysm) would result in a 100% loss, whereas usage of a minority client like Lodestar (0.01% network share) would result in a minimum penalty of ~1 ETH only.
When slashed, a validator immediately stops participating in the Ethereum consensus and is in a suspended state with no reward accrual. A basic slashing penalty of 1 ETH is instantly inflicted upon the balance of the validator.
Source: ECPS slashing simulator at ~11% of active validators slashed, October 28th, 2024
18 days later, a second penalty comes into play: the correlation penalty. Its scale depends on the total share of validators slashed in a 36-day window surrounding the slashing event. It will reach a maximum of 31 ETH when more than 1/3 of all active validators are slashed during that period. Together with the basic slashing penalty of 1 ETH, this would result in a 100% loss for the staker.
Source: ECPS slashing simulator at ~30% of active validators slashed, October 28th, 2024
Finally, 36 days after the slashing event, the validator is ejected from the consensus layer and enters the exit queue where it will spend a variable amount of time depending on the exit queue length. From the time a validator is slashed until it leaves the exit queue, it will suffer from the habitual inactivity penalty, which is small but can add up to significant amounts if the exit queue is long enough.
Inactivity Leak
As previously mentioned, the penalty for being inactive is low and corresponds to what the validator would have gained if it had been online. However, the Ethereum consensus needs at least 2/3 of all active validators to attest to its state at each epoch. If not, the chain would fail to finalize. Finality is a concept introduced by Proof-of-Stake that happens at the end of each epoch. It guarantees that the blocks proposed during the previous epoch are final and won't change, ever. While the probability of a blockchain reorg exponentially decreases through time under Proof-of-Work consensus, it is now binary with Proof-of-Stake. This is an important condition for users of the network, bridges, and centralized services interfacing with Ethereum, as it gives the guarantee that the Ethereum state change can be relied upon. A non-finalizing chain will continue to hum along and blocks will be proposed, but the non-finalized blocks could potentially be dismissed, replaced, or reorganized, which is not desirable.
In a situation where inactive validators would amount to more than 1/3 of all validators, a specific penalty will be activated — the inactivity leak. The basic inactivity penalty that an inactive validator would normally suffer from is scaled by a factor called the inactivity score. If the chain is not finalizing, at each epoch, this score is increased by 4 if a validator is inactive. If the validator comes back online, this score decreases by 1 at each epoch. Notably, this penalty has inertia because a validator that comes back online with an inactivity score that is greater than 1 will continue to suffer from this penalty until this score decreases back to 1.
Source: ECPS inactivity simulator at 36.4% inactivity
Because validators with a balance lower than 16 ETH are automatically exited from the Ethereum consensus, a high enough percentage of inactive validators can trigger a massive exit of inactive validators from the consensus, which would result in a very long exit queue.
Source: ECPS inactivity simulator at 40% inactivity
The goal of this penalty is two-fold. First, it encourages offline validators to come back online as fast as possible, as the penalty grows quadratically. Second, it reduces the balance of offline validators until the stake of all active validators goes back above the 2/3 threshold, which allows for the chain to finalize again.
Centralization Vectors
Consensus Clients
As we have seen previously, both slashing and the inactivity leak penalties scale with the share of all validators that are at fault. Several centralization vectors can result in a cohort of validators being penalized at the same time. The most prevalent one is the consensus client diversity. The Ethereum community has made great progress in developing multiple consensus clients (and execution clients) and raising awareness regarding the danger of centralization. That being said, there are other centralization vectors at play.
Node Operators
Professional node operators offer to run validators in exchange for a small fee applied to the validators' rewards. They will manage the infrastructure and validator keys to maximize uptime and performance and, in the end, achieve economies of scale. Currently, a large share of the staked ETH is managed by professional node operators.
Source: rated.network, top 5 node operators, November 1st, 2024
As we can see on rated.network, Kiln has the highest network share at 4.38%, followed by Staked.us at 3.74% and P2P at 3.45%. None of them is above the critical 1/3 finality threshold, hence protecting validators from the inactivity leak. That being said, if one of those node operators incorrectly manipulates the validator keys they are responsible for, a significant slashing event could happen. For instance, according to our simulator, if Kiln with 4.38% of the network share were to commit such a mistake, it could result in a loss of ~5 ETH for each of their validators or approximately 16% of each validator's balance.
Geographic location
The geographic location of validators is also an important centralization vector. Although rare, DNS or internet backbone-related bugs can happen and cut off a whole geographical area from the rest of the internet. For instance, in 2020, a misconfiguration of a root server operated by CenturyLink caused widespread outages across North America and Europe.
Source: rated.network, November 1st, 2024
If we look at the geographical distribution of nodes, we can see that 38.19% of all validators operate from the United States of America. This is above the critical 1/3 finality threshold and could result in the inactivity leak being activated for all validators operated from there.
Implications for LST/LRT
Most LST/LRTs rely on several node operators to manage their validators. Each of those node operators rely on different consensus and execution node clients to power them. Therefore, typically a given LST or LRT will provide a decent amount of diversification and risk reduction when it comes to the different centralization vectors previously mentioned. That being said, it remains important to understand that not all LSTs or LRTs are equal when it comes to the consensus penalty risks. Not having a single LST/LRT with a network share greater than 1/3 remains important. At LlamaRisk, we plan to improve our Ethereum Consensus Penalty Simulator to calculate and display the extent to which a given LST or LRT is exposed to the different centralization vectors.
Another overlooked implication of the consensus layer on LSTs and LRTs is the effect the length of the exit queue can have on their soft-peg against ETH. When users want to redeem their staking derivative for ETH, they usually have two options: either through the secondary market using liquidity pools or using the underlying protocol — which will trigger the validator to exit on the consensus layer. Because the length of the exit queue is variable, the redemption process might not be instantaneous. It can even take months in a worst-case scenario. When that happens, and especially in case of market turmoil, holders might decide to sell their staking derivative on the secondary market regardless at a loss due to insufficient liquidity. This can lead to significant and prolonged depegs, which in turn could trigger liquidations on lending platforms.
Thanks to lending markets like Aave, it is possible to leverage-loop an LST/LRT position several times for extra yield. The process consists of depositing LST/LRT as collateral and borrowing WETH against it; then the WETH can be deposited back into the LST/LRT protocol, and so on. While double-digits APY can easily be achieved by doing so, the risk increases significantly. If a significant enough proportion of the LST/LRT is looped like this, a small depeg could trigger forced selling on secondary markets, even stronger depegs, and so on: what is known as cascading liquidations.
Conclusion
As we can see, participating in the Ethereum consensus is not risk-free. Without dramatizing, it is important to consider that those are uncommon tail-end risks: hard to predict, but potentially significant in scale. Whether a solo staker or a holder of liquid staking derivatives, one must carefully consider the different options available, and how to mitigate the risks we discussed. Stay tuned for additional features and capabilities offered by our Staking Dashboard.