- Issuance is the amount of new Ether created by the protocol in order to incentivise its participants.
- An ideally running beacon chain issues a set amount of Ether per epoch, which is a multiple of the base reward per increment.
- Total issuance is proportional to the square root of the number of validators. This is not a completely arbitrary choice.
There are three views we can take of the rewards given to validators to incentivise their correct participation in the protocol.
First, there is "issuance", which is the overall amount of new Ether generated by the protocol to pay rewards. Second there is the expected reward a validator might earn over the long run. And, third, there is the actual reward that any particular validator earns.
In this section we will look at issuance, and in the next we'll look at rewards. There is a strong relationship between these, though, so the separation is not totally clean.
First we must define the fundamental unit of reward, which is the "base reward per increment".
All rewards are calculated in terms of a "base reward per increment". This is in turn calculated as
Gwei(EFFECTIVE_BALANCE_INCREMENT * BASE_REWARD_FACTOR // integer_squareroot(get_total_active_balance(state)))
We will call the base reward per increment for brevity. An increment is one unit of effective balance, which is 1 ETH (
EFFECTIVE_BALANCE_INCREMENT), so active validators have up to 32 increments.
BASE_REWARD_FACTOR is the big knob that we could turn if we wished to change the issuance rate of Ether on the beacon chain. So far it's always been set at 64 which results in the issuance graph we see below. This seems to be working very well and there are no plans to change it.
Issuance is the amount of new Ether created by the protocol in order to incentivise its participants. The net issuance, after accounting for penalties, burned transaction fees and so forth is sometimes referred to as inflation, or supply growth.
The Eth1 chain issues new Ether in the form of block and uncle rewards. Since the London upgrade this issuance has been offset in part, or even at times exceeded by the burning of transaction base fees due to EIP-1559.
During the current Altair period, issuance on the beacon chain is additional to that on the Eth1 chain, but is much smaller (around 10% as much). After The Merge, there will no longer be any block or uncle rewards on the Eth1 chain. But the base fee burn will remain, and it is very likely that the net issuance will become negative – more Ether will be destroyed than created1 – at least in the short to medium term. In the longer term, Anders Elowsson argues that there will be a circulating supply equilibrium arising from Ether issuance by proof of stake and Ether destruction due to EIP-1559.
In the following we will be assuming that the beacon chain is running optimally, that is, with all validators performing their duties perfectly. In reality this is impossible to achieve on a permissionless, globally distributed, peer-to-peer network, although the beacon chain has been performing within a few percent of optimally for most of its history. In any case, actual validator rewards and net issuance will certainly be a little or a lot lower, depending on participation rates in the network.
Under the ideal conditions we are assuming, the beacon chain is designed to issue a total of exactly Gwei in rewards per epoch. Here, is the total number of increments held by active validators, or in other words the total of all their effective balances in Ether. This is the maximum issuance – the maximum amount of new Ether – that the beacon chain can generate. If all validators have the maximum 32 ETH effective balance, then this works out to be Gwei per epoch in total.
With epochs per year, and
With 300,000 validators this equates to 515,333 ETH per year, plus change. For comparison, the Eth1 block and uncle rewards currently amount to almost five million ETH per year.
We can graph the maximum issuance as a function of the number of validators. It's just a scaled square root curve.
Maximum annual protocol issuance on the beacon chain as a function of the number of active validators.
The goal is to distribute these rewards evenly among validators (continuing to assume that things are running optimally), so that, on a long term average, each validator earns Gwei per epoch, where is the number of increments it possesses, equivalently its effective balance in Ether. In these terms .
Thus, a well-performing validator with a 32 ETH effective balance can expect to earn a long-term average of Gwei per epoch. Of course, changes over time as the total active balance changes, but absent a mass slashing event that change will be slow.
Similarly to the issuance calculation, we can calculate the expected annual percentage reward for a validator due to participating in the beacon chain protocol:
For example, with 300,000 validators participating, this amounts to an expected return of 5.37% on a validator's effective balance.
Graphing this give us an inverse square root curve.
The expected annual percentage rewards for stakers as a function of the number of active validators.
The choice to scale the per-validator expected reward with is not obvious, and we can imagine different scenarios.
If we model the per-validator reward as , then some options are as follows.
- : each validator earns a constant return regardless of the total number of validators. Issuance is proportional to .
- : issuance scales like , the formula we are using.
- : each validator's expected reward is inversely proportional to the total number of validators. Issuance is independent of the total number of validators.
Adopting a concave function is attractive as it allows an equilibrium number of validators to be discovered without constantly fiddling with parameters. Ideally, if more validators join, we want the per-validator reward to decrease to disincentivise further joiners; if validators drop out we want the per-validator reward to increase to encourage new joiners. Eventually, an equilibrium number of validators will be found that balances the staking reward against the perceived risk and opportunity cost of staking. Assuming that the protocol is not overly sensitive to the total number of validators, this seems to be a nice feature to have.
That would rule out the first, , option. The risk with is that, if the reward rate is set lower than the perceived risk, then all rational validators will exit. If we set it too high, then we end up paying for more security than we need (too many over-incentivised validators). Frequent manual tuning via hard-forks could be required to adjust the rate.
The arguments for selecting over are quite subtle and relate to discouragement attacks. With , a set of validators may act against other validators by censoring them, or performing other types of denial of service, in order to persuade them to exit the system, thus increasing the rewards for themselves. Subject to various assumptions and models, we find that we require for certain kinds of attack to be profitable. Essentially, we don't want to increase rewards too much for validators that succeed in making other validators exit the beacon chain.
Note that after the Merge, validators' income will include a significant component from transaction tips and MEV, which will have the effect of pushing closer to , and much of this reasoning will become moot. Discouragement attacks in that regime are an unsolved problem.
For more background to the reward curve, see
- Casper: The Fixed Income Approach,
- Vitalik's Serenity Design Rationale, and
- the Discouragement Attacks paper.
Anders Elowsson's work on Ethereum’s circulating supply equilibrium and minimum viable issuance takes a deeper look at the relationship between staking issuance and total Ether supply. See his post and comments on Ethresear.ch, and ETHconomics presentation at Devconnect 2022.