Rewards and Penalties on Ethereum 2.0 [Phase 0] | ConsenSys Codefi
Introduction
ConsenSys Codefi is building the blockchain operating system for commerce and finance to help global markets move towards “Finance 2.0.” A critical part of this effort is enabling the creation and use of natively digital assets that incentivize maximally decentralized networks to reliably serve as backbones for new financial products and markets. Enabling “Ethereum 2.0” and the transition to proof-of-stake is front and center for us, and we are happy to start sharing our experience, expertise, and much more on these topics, including, here, the token economics.
The huge demand on Ethereum 1.0 has sometimes resulted in undesirable user experiences such as lengthy waits for transactions to be included in the chain, and volatile transaction fee (gas) prices. Massive scalability — the ability to process thousands of transactions per second rather than the current 15-or-so transactions per second — has long been part of the plan for Ethereum.
We are now in the first phase — Phase 0 — of the Ethereum 2.0 launch. Once all phases of 2.0 are fully implemented, the volume of transactions will improve dramatically. Two major upgrades in the Ethereum code would make this possible: sharding and Proof-of-stake. This upgrade will result in a network with redesigned economics, consensus, and mechanism of operation, which we will explain in more detail below.
Motivation
Ethereum 1.0 is a Proof-of-work blockchain: To mint a block, miners solve a puzzle with a probability proportional to the hashrate they have available, and inversely proportional to the difficulty in the chain. If the miner succeeds, it gets a reward of 2 ETH plus transaction fees. That’s all. By examining the difficulty of the last block, you can estimate the network hashrate, which in turn will let you know what are your odds to get the next block, enabling you to predict your payouts.
Ethereum 2.0 is a little bit more technical in this department.
If you arrived here, and just want to have a back of the envelope reference, please, skip to the section ‘A useful estimate of the network issuance’.
The purpose of this document is to give the reader an overview of the Proof-of-stake implementation of Ethereum 2.0, as well as its system of rewards and penalties. We will break down the incentives into a summary, with a quick assessment of what could be the ROI of a stake, given certain assumptions. We finalize with a teaser of a simulation the Codefi Staking-as-a-Service team is building, to get a more fine grained understanding of this subject.
The Honest Validator
If you make one or several payments to the deposit contract deployed in the Eth1 chain, accruing to an amount equal or larger than 32 ETH, you can qualify to be a validator of the Eth2 Beacon chain.
There are no limits on how much ETH you can add to a validator’s stake. There is, however, an upper limit — namely the effective balance, set at 32 ETH — on what is the actual amount that counts for its interactions within the Beacon chain. In other words, your balance could be as high as 1000 ETH, but your rewards and penalties are a function of your effective balance capped at 32 ETH.
On the other hand, if your validator is affected by penalties and its balance drops to or below 16 ETH, it triggers what is called a forceful (or involuntary) exit.
The so called honest validators will be running well designed clients, complying with the Beacon chain specifications, avoiding penalties for incorrect voting. Or what could be worse, slashing for protocol misbehaviour.
It is important to mention that receiving a penalty is not the same as being slashed: The former represents only a decrease in balance on the validator due to, for example, a miscast vote (within certain parameters) or being offline. A validator that is caught incurring a slashable attestation is forcefully withdrawn from the Beacon chain, with its balance penalized in each epoch during the period it is on the leaving queue.
On Block Minting and Consensus in Ethereum 2.0
The flow of the Beacon chain is built on a unit of time called the slot. Like a heartbeat — every 12 seconds — a validator gets chosen to be the block proposer. Once the block is minted and propagated, an attester committee of validators vote for this block to be part of the canonical chain.
The purpose of committees in the Beacon chain is to distribute the validators, such that each one is able to vote once per epoch (every 32 slots). Validators within committees gossip among each other, enabling the aggregation of attestations.
If during a slot there is not a block proposed, it is identified as a skipped slot. In this situation, further proposals or attestations are built on the last block available from a former slot.
The proposer chooses over which block it will perform the state transition to the new canonical head of the chain. This election is made by the algorithm LMD GHOST fork choice: The procedure picks the fork over which there is recursively the biggest weight in received votes. When validators attest this block, they are in fact, voting in favour of this fork choice.
In order to provide finality to the blockchain, that is, the assurance that the state cannot be reversed, honest validators leverage the Eth2 implementation of Casper the Finality Gadget (FFG), providing in their attestations two additional votes: One for the latest justified epoch (source), and one for the latest epoch boundary (target).
At the beginning of each epoch, attestations are counted. If there exists a supermajority (two thirds), the latest justified epoch checkpoint will be moved forward in time, and, under certain rules, finalization will be achieved either for the prior epoch, or for its antecessor.
If the system has not achieved finality in a number of epochs (4 by the current specification), all the validators in the beacon chain are hit with an inactivity penalty.
There is a lot to unpack here! If you want to explore further on the details, the best references are the Gasper (as in GHOST + Casper) paper (Buterin et al), the actual specifications of the chain at phase 0 (Ethereum Foundation), Phase 0 for humans (Danny Ryan), and the beacon chain ethereum explainer you need to read first (Joseph Chow).
Rewards and penalties
SLASHING
Being slashed means that the validator is forced to exit the beacon chain at a point in the future, receiving a number of penalties until it leaves.
There are three ways a validator can gain the slashed condition:
- By being a proposer and sign two different beacon blocks for the same slot.
- By being an attester and sign an attestation that “surrounds” another one.
- By being an attester and sign two different attestations having the same target.
In all these cases, the offender needs to be caught in order for the slashing process to be triggered. The whistleblowing validator will create and propagate a specific message containing the offense, for a proposer to include it in a block. Both the proposer and the whistleblower will be entitled to a reward.
It is not totally obvious in the specification, but in Phase 0 only the proposer gets the whistleblower reward — that is, the proposer gets the whole slashing reward (8/8 of it).
Assumptions
- Constant MIN_SLASHING_PENALTY_QUOTIENT = 32
- Constant WHISTLEBLOWER_REWARD_QUOTIENT = 512
- Constant PROPOSER_REWARD_QUOTIENT = 8
The offender becomes a slashed validator, and is assigned a withdrawable epoch set 36 days (8,192 epochs) in the future.
Moreover, the slashed validator receives
- A minimum penalty at the moment the proposer includes the whistleblowing message in a block
- A penalty at the beginning of every epoch, for missing the head/FFG votes, until the validator leaves the exit queue
- A special penalty is applied midway between the time when the whistleblowing message is included in a block, and the time when the slashed offender can withdraw.
This special penalty is proportional to how many other validators have also been slashed over the period. The maximum applied can be as high as the whole offender’s effective balance.
Assumptions
- Constant MIN_SLASHING_PENALTY_QUOTIENT = 32
- Constant BASE_REWARD_FACTOR = 64
- Constant BASE_REWARDS_PER_EPOCH = 4
- Constant EFFECTIVE_BALANCE_INCREMENT = 1
EPOCH PROCESSING
At the beginning of each epoch (every 32 slots, except GENESIS), several things happen, including
- Justification and finalization of the chain
- Assignment of rewards and penalties to attesters
- Update of the validator registry
- The special slashing penalty (see above), and
- Some final updates (computing effective balances, resets, etc)
A validator needs to have had the active status on the previous epoch to receive rewards and/or penalties. Until their exit, slashed validators enter in this process as well, where they will be only penalized in the FFG matching categories.
If a validator has been active in the previous epoch, but did not vote, it will get penalized for not matching the FFG votes. Validators are not slashed for being offline.
Assumptions
- Finality Delay = Previous epoch — Finalized epoch
- Attesting Balance = Sum of unslashed attester balance
- Constant BASE_REWARD_FACTOR = 64
- Constant BASE_REWARDS_PER_EPOCH = 4
- Constant PROPOSER_REWARD_QUOTIENT = 8
- Constant MIN_EPOCHS_TO_INACTIVITY_PENALTY = 4
- Constant INACTIVITY_PENALTY_QUOTIENT = 2**25
A useful estimate of the network issuance
Let’s make use of our newly acquired knowledge to produce a back of the envelope estimation of the rewards and penalties for one arbitrary epoch. We want to make it simple, and start with only two parameters.
The former is self explanatory, while the latter can be seen as the probability a randomly chosen validator is able to participate in the beacon chain (its host machine is turned on), having a working internet connection, or other factors.
If we make the assumption that all validators in the beacon chain have both their balance and effective balance equal to 32 ETH, and we use the online probability above, we have
Now we are in conditions to compute the following rewards and penalties for each validator
It is necessary to work a little bit for the last two incentives: The block attesters are assumed to be the online validators in a slot, evenly distributed across the epoch; For the attester incentive, we shall converge the geometric series that we get after defining the probability tree of the expected value, since this reward is inversely proportional to the difference of slots it is included from the attestation.
We see that the proposer incentive exceeds in large quantity the other amounts. Recall that one proposer among all the validators in the beacon chain is chosen at each slot, making the odds of becoming one smaller as the total stake grows. In other words, within an epoch, only 32 of N validators become proposers.
Observe, as well, that we won’t make any assumption or computations about slashed validators and their whistleblowers, nor the inactivity delay.
If we multiply the individual values obtained by the respective amount of online or offline validators, and we add them, we arrive at an estimate of the amount generated from the initial conditions given.
That is, around 1.25 ETH per epoch (6.4 minutes) from a total stake of 500,000 ETH and assuming an online probability of 95%.
It is tempting to go, compute, and chart — at a 95% online probability — the amount of ETH created during an epoch at different stakes.
Wrapping Up
Should we just then go ahead and multiply this amount we obtained per epoch, to give an annual estimate?
Before answering yes, let’s consider the following factors:
BALANCE
There are many different ways in which balances affect the creation of ETH at each epoch. For instance, if a validator gets rewards on top of the effective balance cap (that is 32 ETH), all these exceeding funds will not be influencing the computations in the next epoch. Also, due to the hysteresis applied to effective balances, there is in fact a portion of ETH “lost” on each validator.
Consider as well what happens when validators are ejected due to failing to maintain the minimum amount (16 ETH), when validators are activated as new deposits will be paid to the Eth1 deposit contract, or when stakers trigger voluntary exits.
SLASHING
Slashing operations will be for a good amount of time non-trivial to model. To begin with, Eth2 client developers and staking services need to learn how to avoid the conditions to being slashed. On the other hand, we can only guess what will be the proportion of honest players in the system; Or whether their offenses will be discovered, broadcasted, and included in blocks.
PROBABILITIES
We already touched the subject of the proportion of honest players, and odds of publishing for a whistleblower. Let’s think, also, on the different ways we can measure and estimate that a node will be online, well connected, and working properly. That its attestations will be aggregated and included on time, or getting the view of the slot the majority are seeing.
The beacon chain is a complex adaptive system. Even if we accomplish a perfect understanding of each of its individual parts, it is not guaranteed that we would gain a perfect understanding of the whole.
Mastery on any subject starts by choosing methodologies and tools up for the task. By modelling and simulating aspects of the validator and its interactions within the chain — under a number of initial conditions, assumptions, and constraints — we should be able to build insight into the intricacies of this Proof-of-stake implementation.
Acknowledgements
Written by Herman Junge, an Architect and Technical Lead for the Staking-as-a-Service platform of ConsenSys Codefi.
We thank Joseph Chow, Ben Edgington, Sylvain Laurent, Diederik Protolambda Loerakker, Tim Lowe, Danny Ryan, Alex Stokes, and Kuhan Tharmananthar for comments on the manuscript.
Want to learn more about staking as a service? Get in touch with ConsenSys Codefi here.
Originally published at https://codefi.consensys.net on March 2, 2020.
