Part 2: Technical Overview

The Incentive Layer

Issuance

  • 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.

Introduction

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".

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 bb 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.

The 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

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 an equilibrium will be reached between Ether issuance from proof of stake and Ether destruction due to EIP-1559, leading to a steady overall supply of Ether.

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.

Overall issuance

Under the ideal conditions we are assuming, the beacon chain is designed to issue a total of exactly TbTb Gwei in rewards per epoch. Here, TT 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 NN validators have the maximum 32 ETH effective balance, then this works out to be 32Nb32Nb Gwei per epoch in total.

With 365.25×225=82181.25365.25 \times 225 = 82181.25 epochs per year, and BASE_REWARD_FACTOR =64= 64,

Max issuance per year=82181.25×32×64×N32×109×NETH=940.87N\begin{aligned} \text{Max issuance per year} &= 82181.25 \times \frac{32 \times 64 \times N}{\sqrt{32 \times 10^9 \times N}} \text{ETH} \\ &= 940.87 \sqrt{N} \\ \end{aligned}

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.

A graph of maximum annual protocol issuance on the beacon chain as a function of the number of active validators Maximum annual protocol issuance on the beacon chain as a function of the number of active validators.

Validator rewards

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 ii earns nibn_ib Gwei per epoch, where nin_i is the number of increments it possesses, equivalently its effective balance in Ether. In these terms T=i=0N1niT = \sum^{N-1}_{i=0}{n_i}.

Thus, a well-performing validator with a 32 ETH effective balance can expect to earn a long-term average of 32b32b Gwei per epoch. Of course, bb 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:

APR=100×82181.25×6432×109×N%=2940.21N%\begin{aligned} \text{APR} &= 100 \times 82181.25 \times \frac{64}{\sqrt{32 \times 10^9 \times N}} \% \\ &= \frac{2940.21}{\sqrt{N}} \% \\ \end{aligned}

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.

A graph of the expected annual percentage rewards for stakers as a function of the number of active validators The expected annual percentage rewards for stakers as a function of the number of active validators.

Inverse square root scaling

The choice to scale the per-validator expected reward with 1N\frac{1}{\sqrt{N}} is not obvious, and we can imagine different scenarios.

If we model the per-validator reward as rNpr \propto N^{-p}, then some options are as follows.

  1. p=0p = 0: each validator earns a constant return regardless of the total number of validators. Issuance is proportional to NN.
  2. p=12p = \frac{1}{2}: issuance scales like N\sqrt{N}, the formula we are using.
  3. p=1p = 1: 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, p=0p=0, option. The risk with p=0p = 0 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 p=12p = \frac{1}{2} over p=1p = 1 are quite subtle and relate to discouragement attacks. With p0p \ne 0, 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 p12p \le \frac{1}{2} 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 pp closer to 11, and much of this reasoning will become moot. Discouragement attacks in that regime are an unsolved problem.

See also

For more background to the 1N\frac{1}{\sqrt{N}} reward curve, see


  1. You can see Ethereum's current issuance and play with various scenarios at ultrasound.money.

Created by Ben Edgington. Licensed under CC BY-SA 4.0. Published 2022-05-12 12:26 UTC. Commit 0cc9f0b.