.png)
Big thanks to my colleagues at Chorus One for their contributions to this post, especially Umberto Natale for providing a lot of the data used, full report here.
Many different industries are using Ethereum to build new decentralized applications.
2021 was the year when this vision stopped being reserved for a small subset of the population with pre-existing capital (investors) or technical expertise (developers), as the popularity of Ethereum reached new heights.
Artists are disrupting traditional notions of value, with OpenSea (the largest NFT Marketplace) growing its transactions volume by “over 600x” in a year.
People are organizing self-sustainable communities, as DAO members take control over their own financial freedom and digital identity.
Builders are creating never-before-seen decentralized financial assets, where Ethereum-based Uniswap continues to dominate. But real fun also came to crypto gaming: many are playing Dark Forest, a game that experiments with cutting edge scaling technology.
Most recently, the whole crypto community has come together to aid Ukraine, at the same rate as well-established international organizations.
Bringing Ethereum into the sun and serving all of humanity, inevitably requires a scalable, secure, and resilient network.
This post aims to set the stage for Ethereum as it nears its greatest milestone, and to take a peek at the future for what this could mean in impact for both staking providers and delegators, after the Altair upgrade. To do this, we have delved into risks, rewards and the complex network that sits in between.
The big goals for the future of Ethereum are scattered across its official roadmap.
Understanding this design is key to comprehending the associated risks and rewards of PoS Ethereum. The process of upgrading started in December 2020, when the first piece of the puzzle fell into place: the Beacon Chain went live. This PoS system sets the basic consensus mechanism, by assigning the right to create a block through a deterministic lottery process. Staking nodes with a higher balance have more probability to be selected. The rewards for staking include block rewards and transaction fees, and we explore these further in the following section.
To stake in Ethereum and run a validator, 32 ETH needs to be sent to the Ethereum Deposit Contract, along with two key parameters: 1) the validator public key and 2) the withdrawal credentials for the deposit. Critically, the public key and withdrawal credentials do not need to be controlled by the same entity. This allows for two ways to participate in the protocol: as a validator or as a delegator (individuals who pass the responsibility of validation while still earning a portion of the rewards). Staking providers such as Chorus One offer ETH holders the opportunity to stake their tokens and participate in consensus through its platform.
Because chosen stakers are given exclusive rights to create a block, the protocol must consist of measures to counteract malicious attack vectors. The implementation of this consensus mechanism relies on three core elements: A fork-choice rule, a concept of finality, and slashing conditions. It is important to note that in PoS networks, slashing is not a necessary incentive for correct behavior by validators but rather an artifact of the particular block rewards and mechanism implemented. Because rewards are based on blocks processed or accepted, there’s an incentive for a validator to validate all forks in the chain, even conflicting ones (nothing at stake). Therefore, a slashing rule has to be implemented, as a matter of design.
The Altair hard fork of October 2021 introduced additional elements to consensus, namely sync committees. Validators that are part of this committee have the duty of continually signing the block header to allow a new set of light clients to easily sync up at very low computational and data cost. These concepts of head of the chain, target of attestation and source of attestation are critical to finalizing blocks and earning rewards. Checkpoints are set on-chain to achieve these goals: when a checkpoint is finalized, all previous slots are finalized. There is no limit to the number of blocks that can go through this system. A checkpoint can only be finalized after the process of consensus chooses another validator, and the infinite machine starts all over again.
It is likely that you’ve come across the prime assumption for PoS: “validators will be lazy, take bribes, and that they will try to attack the system unless they are otherwise incentivized not to” Hope for the best, but expect the worst.
You may have also seen floating around different figures for the “estimated APR” for running a validator, and wondered — where does this number even come from? All estimations for returns rest on a set of assumptions, and many published calculations were presented using outdated specs for the Beacon Chain.
So, let’s take a current look. Incentives in Altair come in the form of rewards, penalties, and slashings. Of these three, slashing is the most relevant to validator health. While crypto rewards have been around for years, their complexity and adoption have seen a significant rise in the recent past. Offerings do differ platform by platform, and all carry different kinds of risks.
One of the main conceptual reworks of Altair was in redesigning how validators are rewarded (and penalized). The idea was to make these incentives more systematic and simplify state management. But it also ups the ante on validator responsibilities.
At present, validators are rewarded/penalized if they fulfill determined duties:
A validator can propose one attestation and one block at a time. Depending on their properties, the reward varies. Participation in proposals and in the sync committee are a matter of luck but quite infrequent, however, attestations should be done once per epoch.
How we view rewards while considering risk in staking is a subject of research at Chorus One. This piece aims for other validators and interested parties to understand the “main-principles” they need to follow in order to minimize losses, and in turn, maximize profits in the process of validation. In our study, we found that currently the expected annualized reward for an ideal validator (perfect performance) is 5.44%. This amount decreases to 5.4% when we take into account a less idealized case.
After providing validators a feeling for how much they stand to earn, the following part will present a more practical example and explain how these figures may actually vary.
Slashing risk is a type of platform-dependent risk, as platforms that offer a similar service carry common risks. This section refers to the different types of penalties, and methods to calculate them at certain scenarios.
All formulas presented have been transformed in order to give a more general idea. The risk modeling was done using the actual definition from the Beacon Chain specs (Phase 0 and Altair) and the state of the chain at the time of writing. More on our methods can be found in our full study, linked previously.
Slashing includes all penalties that result in the partial or total loss of the staked assets of a validator, which range from 0% to 100% of the assets. Failing to perform the current validator duties properly (see last section) leads to being penalized and, in the case of slashable actions, being forcefully ejected from the Beacon Chain for suspected malicious activity. This is done to protect both the validator from further losses, and to help the chain finalize.
The main reasons from slashing that validators must be aware of are: proposing two different (conflicting) blocks, submitting two different (conflicting) attestations and submitting an attestation that completely surrounds or is surrounded by another attestation. If these events are not the result of a malicious action, then it follows that they must come from a bug or error. To account for this, the amount of staked destroyed is proportional to the number of validators slashed around the same time. If this number is small, then it is unlikely to be the result of a coordinated attack because that would require a high number of validators. These “honest mistakes” are punished lightly, at a minimum of 1ETH. If, on the other hand, there’s a high number of validators slashed at the same time, then it is assumed to be an attack, resulting in a higher amount of stake being destroyed, up to the full balance of the node.
There’s of course a certain pressure on validators to avoid going out at the same time as other validators. This expectation to decentralize touches on aspects of client diversity, but also on sources of truth or hosting for clients. This is a very critical point for everyone participating in the Ethereum ecosystem, and one that Chorus One has considered in our design. But back to the topic, these penalties hold true whether or not blocks are being finalized (meaning, 2/3 of validators weighted by stake are online and their votes are being counted). This is the state of normal operations for Ethereum. Anything under that, and we can no longer reach agreement and the inactivity leak mentioned previously comes in to restore balance.
With a clear understanding of the rewards system, estimating the source of possible penalties is much more simple, by calculating the attestation reward/penalty delta.
Indeed, if the reward is not finalized, the corresponding amount is removed from the attester’s balance (the minimum penalty). At that point, the validator’s unlock date for the stake is delayed about 36 days. This is to allow another, potentially much greater, slashing penalty to be applied later, once the chain knows how many validators have been slashed together around the same time (further penalty). If an inactivity leak is active, then the potential reward drops to 0, so by fulfilling the duties you are only able to avoid penalties.
Since getting the source vote wrong implies getting the target vote wrong, and getting the target vote wrong implies getting the head vote wrong, the possible slashing scenarios reduce to these:
To quantify the outcomes for performing validator duties, we would like to compare what could be considered a generic validator across a selection of edge scenarios. This example takes into consideration the following values:
Perfect Validator
To start off, let’s look at what this validator would earn if they, and all other validators, had an ideal participation record under the defined specs.
Attestations can be rewarded with a portion of the “base reward” for each of the correlated duties, weighted by the specific service provided. In the latest specs, the target vote receives the highest rewards, as it is the most important to reach consensus. The base reward is a constant across the network at all times.
BASE REWARD (in Gwei) = Effective balance * [Base reward factor / sqrt(staked ETH balance)]BASE REWARD = 32,000,000,000 * [64 / sqrt(10,000,000,000,000,000)] = 20,480 Gwei = 0.00002048 ETH
Following the upgrade, the block reward allocated is now ⅛ of total rewards as intended by the Ethereum researchers, rather than ⅛ of ¼ of rewards, as was the case pre-Altair. You may notice the delay reward is missing. Now, all attestations are given specific inclusion deadlines to claim their rewards in a gradual pattern, so prompt voting is logically accounted for.
Since all validators are supposed to attest at least one time during an epoch (for a perfectly working network), the number of attesting validators is equal to the total active validators divided by the number of slots per epoch.
ATTESTING VALIDATORS = ACTIVE VALIDATORS / SLOTS PER EPOCHATTESTING VALIDATORS = 300,000 / 32 = 9,375 validatorsTOTAL REWARD = BASE REWARD * ATTESTING VALIDATORSTOTAL REWARD = 20,480 * 9,375 = 192,000,000 GweiBLOCK REWARD = TOTAL REWARD / 8 = 24,000,000 Gwei = 0,024 ETHTARGET REWARD = 26 * TOTAL REWARD / 64 = 78,000,000 Gwei = 0,078 ETHSOURCE REWARD = 14 * TOTAL REWARD / 64 = 42,000,000 Gwei = 0,042 ETHHEAD REWARD = 14 * TOTAL REWARD / 64 = 42,000,000 Gwei = 0,042 ETH
Sync committees rotate rather slowly (every 256 epochs or every day), and validators selected can earn the sync committee reward for each slot in which they participate. A high number of validators will not be actually selected for this reward in a year’s time.
SYNC COMMITTEE REWARD = 2 * TOTAL REWARD / 64 = 6,000,000 Gwei = 0,06 ETH
Finally, we see the maximum possible reward in an epoch (this number also coincides with the minimum penalty for being offline or failing to fulfill the previous duties):
MAXIMUM REWARD = (BLOCK+TARGET+SOURCE+HEAD+SYNC COMMITTEE) REWARDMAXIMUM REWARD = 0,246 ETH
It is important to note that there’s still a potential variation to this reward of a few percent over the course of a year due to sheer luck (e.g. the probability of being chosen to propose, be in the sync committee, being offline exactly at the moment you are selected, etc. This applies even considering this ideal case, where the validator performs all their duties perfectly. The effect increases as the validator set grows, due to probability. Although not worrying in terms of an investment risk (marginal differences should even out over the course of a year), it still should be kept in mind as we delve into actual performance of validators in the network.
If we were to expand this timeline to a year, then the expected reward for this single validator per year sits at around 1.7428 ETH, which corresponds to the 5.44%% APY we mentioned in the previous section. A validator can optimally earn one base reward per epoch over a long time horizon.
Realistic Validator
However, to get a bit closer to model real-world rewards, we must consider the impact of a less-than-perfect validator performance.
As we learned previously, rewards are maximized for validators the better the network behaves. This helps disincentivize malicious behavior but also means that rewards can be reduced by external factors. A model that considers all the reasons why this validator might fail to produce attestations, produce blocks, or fail to propagate is an option, but here we wanted to observe: what would happen if we assume that 99.25% (a fair figure in reality) of active validators are actually attesting blocks? Also, we wanted to make a more conservative choice and assume that our validator was online 99.9% of the time.
As we can see, in this new realistic scenario, the total distribution shifts slightly. The expected annualized reward suffers a reduction of about 0.8% and the resulting expected APY reduces to 5.4%, as we had mentioned. The probability of certain events happening plays a huge part in this scenario, so this is just a starting point to analyze.
Slashed Validator
Next we wanted to estimate what would happen if our validator was caught committing a slashable offense, the ones that were previously outlined to result in substantial loss of stake. To do this, we will assume that we simultaneously sign two different blocks with 1000 validators. In this case, we suffer three types of slashing for each validator involved:
This corresponds to a total loss of -0.8282 ETH. It is worth noting that this slashed amount increases with the number of validators that are slashed at the same time, as was discussed in the slashing overview.
PoS Ethereum is a highly complex and elaborate system. It is thoughtfully designed, but can be difficult to fully grasp from a validator’s perspective, which can make staking seem like an uncertain and unpredictable endeavor. There is still a compelling amount of ETH that is yet to be staked, therefore we must all prioritize network participation and security in the future.
To make sense of the opportunities presented by staking, we wanted to explore the risks native to Ethereum and how said risks stack up versus the offered rewards after the Altair upgrade. Hopefully this article has helped to clarify why and how these rewards can vary from small changes in state or from bigger events, and also show how staking is a profitable business to take part in the long term. As we found in our analysis, the profit of a single validator is around 1.7428 ETH per year, or if we prefer to see in terms of percentage, this corresponds to a 5.44%% APY.
Based on the analysis performed, we find that the most realistic impact is low enough for self-cover to be a viable option, but not low enough to be completely trivial. We have identified the most relevant scenarios to come up with this conclusion. Additionally, we have found that risk can be significantly reduced by non-financial actions, such as promoting validator diversity and operator distribution, as well as putting in place mechanisms to maintain high validation quality standards. You can read our full report here.
Taking Ethereum from the individual to the masses will require a set of tools that accelerate the process of setting-up a validator whilst maintaining the same level of security and protection. At Chorus One we are working to make this a reality through our infrastructure services, and we are preparing to launch new services in the near future that take this to the next level. To learn more, please reach out to research@chorus.one.
