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