EIP-2982: Serenity Phase 0

EIPS/eip-X.md

@@ -0,0 +1,198 @@
+---
+eip: 2982
+title: Serenity Phase 0
+author: Danny Ryan (@djrtwo), Vitalik Buterin (@vbuterin)
+discussions-to: https://ethereum-magicians.org/t/serenity-phase-0-eip/4621
+status: Draft
+type: Standards Track
+category: Core
+created: 2020-09-15
+---
+
+## Simple Summary
+
+Serenity, aka eth2, is the [long-planned](https://blog.ethereum.org/2015/03/03/ethereum-launch-process) 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.
+
+Although early phases of eth2 are to be executed without any breaking consensus changes on current Ethereum mainnet, this EIP serves to formalize the upgrade as a component of the Ethereum protocol and to tie eth2 into the core EIP process.
+
+## 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](https://github.com/ethereum/eth2.0-specs) from this EIP, and safety and liveness proofs can be found in the [Combining GHOST and Casper](https://arxiv.org/abs/2003.03052) paper. To avoid duplication, this EIP just references relevant spec files and releases.
+
+## Motivation
+
+Eth2 aims to fulfill the [original vision](https://blog.ethereum.org/2015/03/03/ethereum-launch-process/) of Ethereum to support an efficient, global-scale, general-purpose transactional platform while retaining high cryptoeconomic security and decentralization.
+
+### 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 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](https://eth.wiki/sharding/Sharding-FAQs) for an excellent introduction and discussion of scaling through sharding.
+
+### Decentralization and economic finality through proof-of-stake
+
+Since the [early days](https://blog.ethereum.org/2015/12/28/understanding-serenity-part-2-casper/) of Ethereum, proof-of-stake has been a long-awaited promise of 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"](https://eth.wiki/sharding/Sharding-FAQs#how-do-you-actually-do-this-sampling-in-proof-of-work-and-in-proof-of-stake) than PoW and thus allows for a more direct sharded protocol construction.
+
+See the [Ethereum wiki proof-of-stake FAQ](https://eth.wiki/en/concepts/proof-of-stake-faqs) for an excellent introduction and discussion of proof-of-stake consensus.
+
+## Parameters
+
+| Parameter | Value |
+| - | - |
+| `SPEC_RELEASE_VERSION` | TBD |
+| `SPEC_RELEASE_COMMIT` | TBD |
+| `DEPOSIT_CONTRACT_ADDRESS` | TBD |
+| `MIN_GENESIS_TIME` | TBD |
+| `BASE_REWARD_FACTOR` | `2**6` (64) |
+| `INACTIVITY_PENALTY_QUOTIENT` | `2**26` (67,108,864) |
+| `PROPORTIONAL_SLASHING_MULTIPLIER` | `1` |
+| `MIN_SLASHING_PENALTY_QUOTIENT` | `2**5` (128) | 
+
+_Note:_ Eth2 has many more [Phase 0 configuration parameters](https://github.com/ethereum/eth2.0-specs/blob/dev/configs/mainnet/phase0.yaml) but the majority are left out of this EIP for brevity.
+
+## Specification
+
+Phase 0 is designed to require _no breaking consensus changes_ to existing Ethereum mainnet. Instead, this is an extension of Ethereum mainnet to bootstrap the new PoS consensus.
+
+Phase 0 specifications are maintained in a [repository](https://github.com/ethereum/eth2.0-specs) 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](https://github.com/ethereum/eth2.0-specs).
+
+### Validator deposit contract
+
+In Phase 0, eth2 uses a contract deployed on Ethereum mainnet -- the [Deposit Contract](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/deposit-contract.md) -- 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:
+* [Deposit Contract](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/deposit-contract.md)
+* [Beacon Chain -- `Deposit` processing](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#deposits)
+* [Validator -- Becoming a validator](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/validator.md#becoming-a-validator)
+
+### Beacon chain and validator mechanics
+
+Users who chose to participate in eth2 consensus as a validator(s) deposit ETH collateral into the [deposit contract](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/deposit-contract.md) and are inducted in the beacon chain. From there, these validators (consensus participants in PoS akin to miners in PoW) are responsible for constructing the **beacon chain**.
+
+The beacon chain is a pure PoS chain that in Phase 0 is primarily concerned with manintaining 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 are added to the beacon chain to manage the consensus of a number of parallel shard chains ("Phase 1"), integrate the existing Ethereum system ("Phase 1.5") and add full support for sharded smart contract execution ("Phase 2").
+
+More on the beacon chain and validator mechanics:
+* [Beacon Chain -- State transition function](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#beacon-chain-state-transition-function)
+* [Beacon chain -- Operations](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#operations)
+* [Beacon chain -- Rewards and Penalties](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties-1)
+* [Validator -- Beacon chain responsibilities](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/validator.md#beacon-chain-responsibilities)
+
+### Issuance
+
+To incentivize validators to deposit ether collateral and participate in the eth2 consensus, rewards (in the form of Ethereum's native asset, ether) are 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 in proportion to the square root of the total ether deposited. This issuance curve has been chosen as a more stable and sustainable curve to the two obvious alternatives -- fixed total issuance and fixed issuance per ether staked. See more technical discussion on this choice [here](https://github.com/ethereum/research/blob/master/papers/discouragement/discouragement.pdf).
+
+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.
+
+![](https://storage.googleapis.com/ethereum-hackmd/upload_953c502d09928c0b306cc078268945c1.png)
+
+| 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](https://docs.google.com/spreadsheets/d/15tmPOvOgi3wKxJw7KQJKoUe-uonbYR6HF7u83LR5Mj4/edit#gid=842896204) 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"](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)). Small offline penalties incentivize validator liveness, whereas (potentially) much larger penalties provide protocol security in tail-risk scenarios.
+
+Specifically, the following significant penalties exist:
+* **Inactivity Leak**: an offline penalty that increases each epoch is applied to validators during extending times of no finality (e.g. one-third 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 four times its final value_. This results in a slower inactivity leak during times of non-finality and thus less responsiveness of the chain to such an event. If there is an extended time of non-finality during early months of eth2, it is far more likely to be technical issues with client software rather than some sort of global catastrophic event. 
+
+_`PROPORTIONAL_SLASHING_MULTIPLIER` is 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 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`_ is 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 your system secure. As with `PROPORTIONAL_SLASHING_MULTIPLIER`, slashings during early months of eth2 are far more likely to be the result of 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
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+Ethereum blocks are bursting at the seams 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 is two-fold -- scale from both Layer 1 upgrades as well as Layer 2 adoption. 
+
+For details regarding specification design rationale and decisions, see the following:
+* [Serenity Design Rationale](https://notes.ethereum.org/@vbuterin/rkhCgQteN)
+* [Ben Edgington's Eth2 Annotated Spec](https://benjaminion.xyz/eth2-annotated-spec/)
+* [Vitalik Buterin's Eth2 Annotated Spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md)
+
+## Backwards Compatibility
+This EIP does not introduce any layer 1 changes to Ethereum mainnet and is thus entirely forwards/backwards compatible.
+
+Instead, 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 as being canonical and directly informing the future and roadmap of Ethereum mainnet.
+
+## Implementation
+
+The following implementations of eth2 Phase 0 exist and at the time of writing at least five are near production-ready and in testnet/audit phase:
+
+* [Cortex](https://github.com/NethermindEth/cortex) (.net)
+* [Lighthouse](https://github.com/NethermindEth/cortex) (rust)
+* [Lodestar](https://github.com/ChainSafe/lodestar) (javascript)
+* [Nimbus](https://github.com/status-im/nim-beacon-chain) (nim)
+* [Prysm](https://github.com/prysmaticlabs/prysm/) (go)
+* [Teku](https://github.com/pegasyseng/teku) (java)
+* [Trinity](https://github.com/ethereum/trinity/) (python)
+
+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 a deep canon of research literature analyzing security and trade-offs. _The following only represents a high level selection of the resources available._
+
+* [Casper FFG](https://arxiv.org/abs/1710.09437)
+* [Combining GHOST and Casper](https://arxiv.org/abs/2003.03052)
+* [Sharding FAQ](https://eth.wiki/sharding/Sharding-FAQs)
+* [PoS FAQ](https://eth.wiki/en/concepts/proof-of-stake-faqs)
+* [Eth2 research compendium](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view)
+
+
+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._
+
+* [Eth2 Phase 0 Spec audit by Least Authority](https://leastauthority.com/blog/ethereum-2-0-specifications/)
+* [Gossipsub v1.1 audit by Least Authority](https://leastauthority.com/blog/audit-of-gossipsub-v1-1-protocol-design-implementation-for-protocol-labs/)
+* [Discv5 audit by Least Authority](https://leastauthority.com/blog/audit-of-gossipsub-v1-1-protocol-design-implementation-for-protocol-labs/)
+* [Formal Verification of Finality in eth2 by Runtime Verification](https://runtimeverification.com/blog/formally-verifying-finality-in-gasper-the-core-of-the-beacon-chain/)
+* [Formal Verification of Deposit Contract by Runtime Verification](https://github.com/runtimeverification/deposit-contract-verification/blob/master/deposit-contract-verification.pdf)
+* [Prysm client audit by Quantstamp](https://quantstamp.com/blog/ethereum-2-0-moves-closer-to-launch-with-quantstamp-audit-of-prysm)
+* [Lodestar utility libraries audit by Least Authority](https://leastauthority.com/blog/audit-of-chainsafe-utility-libraries/)
+
+And finally, the EF maintains eth2 spec, network, and client bug bounty programs
+
+* [Eth2 Phase 0 bug bounty program](https://notes.ethereum.org/@djrtwo/phase0-bounty)
+* [Eth2 public attacknets](https://github.com/ethresearch/public-attacknets)
+* _Eth2 Client Bounty Program to be released soon_
+
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).