📢 This EIP is in the last call for review stage. The authors wish to finalize the EIP and appreciate feedback.

EIP-2982: Serenity Phase 0 Source

AuthorDanny Ryan, Vitalik Buterin
Discussions-Tohttps://ethereum-magicians.org/t/serenity-phase-0-eip/4621
StatusLast Call
Last Call Deadline2021-09-09
TypeInformational
Created2020-09-15

Table of Contents

Simple Summary

Serenity, aka eth2, is the long-planned upgrade of Ethereum to a scalable, proof-of-stake (PoS) consensus. Specifications, development, and releases are divided into phases to iteratively manage the complexity of the upgrade. This EIP addresses Phase 0 of the release schedule.

Early phases of eth2 are executed without any breaking consensus changes on current Ethereum mainnet. This EIP serves to document the bootstrapping of this consensus mechanism and note the path for eth2 to supplant Ethereum’s current proof-of-work (PoW) consensus.

Abstract

This EIP specifies Phase 0 of Serenity (eth2), a multi-phased upgrade to the consensus mechanism for Ethereum mainnet. In Phase 0, the existing PoW chain and mechanics are entirely unaffected, while a PoS chain – the beacon chain – is built in parallel to serve as the core of the upgraded consensus. In subsequent phases, the beacon chain is enhanced to support and secure the consensus of a number of parallel shard chains, ultimately incorporating current Ethereum mainnet as one of those shards.

At the core of the beacon chain is a proof of stake consensus mechanism called Casper the Friendly Finality Gadget (FFG) and a fork-choice rule called Latest Message Driven Greedy Heaviest Observed Sub-Tree (LMD-GHOST). Phase 0 is centered primarily around the mechanics and incentives of validators executing these algorithms. The detailed specifications for eth2 are contained in an independent repository from this EIP, and safety and liveness proofs can be found in the Combining GHOST and Casper paper. To avoid duplication, this EIP just references relevant spec files and releases.

Motivation

Eth2 aims to fulfill the original vision of Ethereum to support an efficient, global-scale, general-purpose transactional platform while retaining high cryptoeconomic security and decentralization.

Today, Ethereum blocks are consistently full due to increasingly high demand for decentralized applications. Ever since the first serious spikes in adoption in 2017 (cryptokitties), the Ethereum community has consistently and vocally demanded scaling solutions.

Since day 0 of Ethereum, the investigation and expectation in scaling solutions has been two-pronged – scale from both Layer 1 upgrades and Layer 2 adoption. This EIP represents the start to a multi-phased rollout of the former.

Scaling through sharding

As the Ethereum network and the applications built upon it have seen increasing usage over the past 5 years, blocks have become regularly full and the gas price market continues to climb. Simple increases to the block gas-limit of the current Ethereum chain are unable to account for the increase in demand of the system without inducing an unsustainably high resource burden (in the form of bandwidth, computational, and disk resources) on consumer nodes. To retain decentralization while scaling up the Ethereum network, another path must be taken.

To provide more scale to Ethereum, while not inducing a restrictively high burden on both consumer and consensus nodes, eth2 introduces a “sharded” solution in which a number of blockchain shards – each of similar capacity to Ethereum mainnet today – run in parallel under a unified consensus mechanism. The core consensus (the beacon chain) and a small number of these shards can be processed via a single consumer machine, while the aggregate of the system provides much higher capacity.

See the Ethereum wiki sharding FAQ for an excellent introduction and discussion of scaling through sharding.

Decentralization and economic finality through proof-of-stake

Since the early days of Ethereum, proof-of-stake has been a long-awaited desideratum for the following:

  • Increased decentralization of the core consensus by lowering the barrier to entry and technical requirements of participation
  • Increased cryptoeconomic security via in-protocol penalties for misbehaviour and the addition of economic finality
  • Elimination of the energy hungry mining of the current PoW consensus mechanism

In addition to the above, PoS has synergies with the sharding scaling solution. Due to the random sampling requirement of sharding, PoS provides a more simple and direct access to the “active validator set” than PoW and thus allows for a more direct sharded protocol construction.

See the Ethereum wiki proof-of-stake FAQ for an excellent introduction and discussion of proof-of-stake consensus.

Specification

Phase 0 is designed to require no breaking consensus changes to existing Ethereum mainnet. Instead, this is the bootstraping a new PoS consensus that can, once stable, supplant the current PoW consensus.

Phase 0 specifications are maintained in a repository independent of this EIP. SPEC_RELEASE_VERSION release of the specs at SPEC_RELEASE_COMMIT are considered the canonical Phase 0 specs for this EIP.

This EIP provides a high level view on the Phase 0 mechanisms, especially those that are relevant to Ethereum mainnet (e.g. the deposit contract) and users (e.g. validator mechanics and eth2 issuance). The extended and low level details remain in the specs repository.

Parameters

Parameter Value
SPEC_RELEASE_VERSION v1.0.0
SPEC_RELEASE_COMMIT 579da6d2dc734b269dbf67aa1004b54bb9449784
DEPOSIT_CONTRACT_ADDRESS 0x00000000219ab540356cBB839Cbe05303d7705Fa
MIN_GENESIS_TIME 1606824000
BASE_REWARD_FACTOR 2**6 (64)
INACTIVITY_PENALTY_QUOTIENT 2**26 (67,108,864)
PROPORTIONAL_SLASHING_MULTIPLIER 1
MIN_SLASHING_PENALTY_QUOTIENT 2**7 (128)

Note: Eth2 has many more Phase 0 configuration parameters but the majority are left out of this EIP for brevity.

Validator deposit contract

In Phase 0, eth2 uses a contract deployed on Ethereum mainnet – the Deposit Contract – at DEPOSIT_CONTRACT_ADDRESS to onboard validators into the PoS consensus of the beacon chain.

To participate in the PoS consensus, users submit validator deposits to the deposit contract. The beacon chain comes to consensus on the state of this contract and processes new validator deposits. This uni-directional deposit mechanism is the only technical link between the two components of the system (Ethereum mainnet and beacon chain) in Phase 0.

More on this mechanism:

Beacon chain and validator mechanics

Users who choose to participate in eth2 consensus deposit ETH collateral into the deposit contract in order to be inducted into the beacon chain validator set. From there, these validators are responsible for constructing the beacon chain (note that these consensus participants in PoS are akin to miners in PoW).

The beacon chain is a pure PoS chain that in Phase 0 is primarily concerned with maintaining its own consensus and managing the registry of validators. The consensus rules define roles (e.g. block proposal, block attesting) that validators are expected to participate in; validators who perform their roles well are rewarded, and validators who perform their roles poorly or are offline are penalized. Phase 0 does not yet include any ETH transfer, sharding or smart contract / VM execution capabilities.

In subsequent phases, additional mechanisms and validator responsibilities will be added to the beacon chain to manage the consensus of a number of parallel shard chains (“Phase 1”), to integrate the existing Ethereum system (“Phase 1.5”) and to add full support for sharded smart contract execution (“Phase 2”).

More on the beacon chain and validator mechanics:

Issuance

To incentivize validators to deposit ether collateral and participate in the eth2 consensus, we propose that rewards (in the form of Ethereum’s native asset, ether) be regularly issued to consensus participants. Due to the beacon chain operating in parallel to the existing PoW chain in early phases of eth2, this issuance is in addition to any PoW rewards until the existing chain is merged into eth2 as a shard.

The amount of ether issued to validators on the beacon chain is proportional to the square root of the total ether deposited. This issuance curve was chosen as a more stable and sustainable curve to the two obvious alternatives – fixed total issuance and fixed issuance per ether staked. For a more technical discussion on this choice see here.

In eth2, this curve is parameterized by BASE_REWARD_FACTOR in the context of slot time and epoch length. Below is the issuance curve as a function of ether staked, along with a table of examples for illustration. Note, all figures shown are annualized.

Active Deposits Max Annual Validator Reward* Max Annual ETH Issued*
0.5M ETH 23.50% 117,527
1M ETH 16.60% 166,208
2M ETH 11.75% 235,052
4M ETH 8.31% 332,411
8M ETH 5.88% 470,104
16M ETH 4.16% 664,801
32M ETH 2.94% 940,167
64M ETH 2.08% 1,329,603
128M ETH 1.47% 1,880,334

*Assuming validators are online 100% of the time and behaving optimally. Suboptimal validator behavior will lead to reduced rewards and/or penalties that reduce total issuance.

For more details, see this eth2 calculator maintained by ConsenSys Activate.

Initial punitive parameters

For PoS protocols to be crypto-economically secure, in-protocol penalties are required (see discussion of “Nothing at Stake”). Small offline penalties incentivize validator liveness, whereas (potentially) much larger penalties provide protocol security in the event of tail-risk scenarios.

Specifically, the following significant penalties exist:

  • Inactivity Leak: an offline penalty that increases each epoch is applied to validators during extended times of no finality (e.g. if one-third or more are offline or not on the canonical chain). This ensures the chain can eventually regain finality even under catastrophic conditions.
  • Slashing: a penalty applied to validators that sign explicitly malicious messages that could lead to the construction and finalization of two conflicting chains (e.g. two blocks or attestations in the same slot). This penalty is designed to scale up in proportion to the number of slashable validators in the same time period such that if a critical number (wrt chain safety) of slashings have occurred, validators are maximally punished.

For the initial launch of Phase 0, the parameters defining the magnitude of these penalties – INACTIVITY_PENALTY_QUOTIENT, PROPORTIONAL_SLASHING_MULTIPLIER, and MIN_SLASHING_PENALTY_QUOTIENT – have been tuned to be less punitive than their final intended values. This provides a more forgiving environment for early validators and client software in an effort to encourage validation in this early, higher technical-risk stage.

INACTIVITY_PENALTY_QUOTIENT is configured initially to four times its final value. This results in a slower inactivity leak during times of non-finality, which means the chain is less responsive to such an event. If there is an extended time of non-finality during the early months of eth2, it is far more likely to be due to technical issues with client software rather than some sort of global catastrophic event.

PROPORTIONAL_SLASHING_MULTIPLIER is configured initially to one-third of its final value. This results in a lower accountable safety margin in the event of an attack. If any validators are slashed in the early months of eth2, it is far more likely to be the result of user mismanagement of keys and/or issues with client software than an organized attack.

MIN_SLASHING_PENALTY_QUOTIENT configured initially to four times its final value. This results in a lower guaranteed minimum penalty for a slashable offense and thus reduces the baseline punitive incentive to keep an individual validator’s system secure. As with PROPORTIONAL_SLASHING_MULTIPLIER, slashings during the early months of eth2 are far more likely to be due to user mismanagement, or issues with client software, than an organized attack.

A hard fork of the eth2 beacon chain is planned for 5 months after genesis. This hard fork will adjust INACTIVITY_PENALTY_QUOTIENT, PROPORTIONAL_SLASHING_MULTIPLIER, and MIN_SLASHING_PENALTY_QUOTIENT to their final, more secure values.

Rationale

For details regarding specification design rationale and decisions, see the following:

Backwards Compatibility

Although this EIP does not introduce any immediate changes to the current Ethereum mainnet, this EIP lays the groundwork for future backwards incompatibilities through the introduction of the new eth2 consensus mechanism in which Ethereum will be integrated in subsequent phases. To secure this mechanism, users move ether into the beacon chain and additional ether is issued. This EIP is a commitment to this path being canonical, as well as directly informing the future and roadmap of Ethereum mainnet.

Implementation

The following implementations of eth2 Phase 0 exist. At the time of writing at least five are near production-ready and in testnet/audit phase:

In addition to implementations of the spec, the deposit contract is implemented in Solidity, along with a formal verification of the bytecode.

Security Considerations

Eth2 is a major overhaul of the Ethereum’s core consensus from PoW to a sharded PoS. There are inherent risks in this migration but there is extensive research literature analyzing security and trade-offs. The following only represents a high level selection of the resources available:

In addition to the research supporting this path, a number of audits and formal verification of specs, cryptography, and client implementations have been performed. Many client and utility library audits are currently in progress and will be appended here upon completion.

Finally, the EF maintains bounty programs for the eth2 spec, attacknets, and clients.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Danny Ryan, Vitalik Buterin, "EIP-2982: Serenity Phase 0 [DRAFT]," Ethereum Improvement Proposals, no. 2982, September 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2982.