Guide to eth2

January 26, 2022

eth2 is a Proof of Stake blockchain that aims to be a more secure and scalable version of today’s Ethereum mainnet without sacrificing accessibility or decentralization.

An introduction to eth2

Today, Ethereum is a proof of work blockchain that enables developers to build and deploy decentralized applications. With eth2, the protocol is transitioning to proof of stake consensus and improving its scalability and decentralization without sacrificing security. The new protocol design allows Ethereum to remain accessible for regular users to run validators and secure the network. It is optimized for hundreds of thousands of validators with low startup costs and forgiving slashing and downtime penalties. 

The eth2 research team has planned a non-sequential transition that will allow all current users to shift to the new consensus mechanism without interruption. During the early phases of the transition, Ethereum 1.x and eth2 chains will run in parallel, with their own state and inflation; eventually, Ethereum 1.x will be merged into eth2.

BT Placeholder

How eth2 works

eth2 will have a Beacon Chain in Phase 0 and 64 shard chains in Phase 1. The Beacon Chain holds the shards together and enables consensus and cross-shard communication. It has a registry of validator addresses, the state and balance of each validator, attestations, and links to shards; it is the central controller of the eth2 system.

BT Placeholder

Source

eth2 has 12-second-long slots and epochs of 32 slots / 6.4 minutes. A slot is a chance for a block to be added to the Beacon Chain and shards. A block is not required for every slot. In optimal conditions, for every slot one Beacon Chain block and 64 shard blocks will be created.

Every slot, a validator is pseudorandomly chosen by RANDAO (a random beacon) as a block proposer. At least one committee is also chosen as attesters.

A committee is a group of validators with a target size of 128 validators. As attestors, the validators review the proposed beacon blocks and shard blocks, and vote on them. These votes, called attestations, are recorded on the Beacon Chain and determine the chain head of the Beacon Chain and each shard.

This process ensures a block was made correctly. The more attestors involved, the more confident there is that the block is well made. The process also provides assurance that the next validator selected will produce a block on the right chain.

BT placeholder

Source

As the number of validators increases, more committees are assigned to a slot. The maximum number of committees per slot is 64. When shards are added, committees will not just attest to a specific slot, but will also crosslink to a particular shard to keep the protocol in sync.

The block in the first slot of an epoch is the checkpoint. This is how the chain periodically agrees on finality. It is finalized in two epochs (12.8 minutes).

While validators are the entities participating in consensus, validator clients are the nodes that hold the validators. The validator clients connect to public-facing beacon nodes to enable the validators to participate on the chain. Beacon nodes follow and read the full Beacon Chain, similar to an Ethereum GETH node does today.

eth2's innovations

eth2 is a unique Proof of Stake protocol design with notable innovations.

  • Accessibility: PoW mining — while accessible in theory — is often not accessible in practice due to immense startup costs, difficult hardware acquisition, and a reliance on cheap electricity. By transitioning to PoS, eth2 lowers the barrier to entry for an individual to participate in consensus and secure the chain. Although startup costs remain (acquiring 32 ETH), these costs are significantly less than those associated with a mining operation. Projects working to create staking pools can help smaller token holders participate.

  • Decentralization: Because PoW miners are forced to sell a portion of their rewards to pay for their operating costs like electricity, PoW networks are more likely to be decentralized because most tokens are released into circulation. In contrast, on most PoS networks, larger-scale validators only need to sell a small portion of their rewards to pay for their costs. They are also incentivized to accumulate and compound their rewards.

  • Scalability: Although moving to PoS alone does not sufficiently increase scalability, it does allow for sharding without reducing security. Sharding partitions the eth2 blockchain into 64 shards. Each shard is capable of processing transactions and blocks simultaneously. The increased throughput capacity is at least 64x greater than what is currently possible on the PoW chain.

  • Account Abstraction: eth2 aims to move from two account types to just one feature-rich account type. This abstraction makes user accounts more versatile and enables them to contain complex logic and advanced functionality.

  • Execution Environments: Currently, all dApps must be designed to account for the Ethereum Virtual Machine, Ethereum’s decentralized ecosystem for building. In order to allow execution to be more open-ended, Execution Environments on eth2 enable any state transition to be built directly into the protocol using WASM.

  • EIP1559: A change to Ethereum’s gas management means a majority of transaction fees are burned instead of distributed to miners/validators. Not only will this shift make fee estimation easier and more accurate, it will make ETH scarcer and potentially more valuable. Over 1,229,000 ETH has been burned since EIP1559's implementation.

  • Stateless Client: As Ethereum 1.X gets larger, it experiences “state bloat,” an ever-growing storage of data that is never used. This increase in data requires Ethereum nodes to have more storage, or better hardware, as the network ages. This requirement can be a barrier for potential Ethereum node operators. With eth2, the goal is for some nodes to be stateless, allowing for light nodes to verify all transactions and parts of the state without actually holding much or any of the state. Validators, for example, are expected to be stateless, significantly reducing the minimum overhead to help secure the network.

How to participate on eth2

Eth2 allows participation on the network for a broader set of token holders than most PoS chains. 32 ETH represents a relatively low staking requirement and low entry point for running a validator that earns rewards. Please note: there is no delegation or stake pooling at the protocol level.

  1. Generate keys: To run an eth2 validator, two keys must be generated—the validator key and the withdrawal key. The withdrawal key is the custodial key where the ETH on the Beacon Chain will be withdrawn from in Phase 2. Please note: the withdrawal key should be secured and backed up as a cold key or stored in a hardware wallet or offline device.

  2. Deposit ETH: After keys are generated, a token holder can deposit ETH into a smart contract on the Ethereum 1.X mainnet. This contract is unidirectional: the deposited tokens are inaccessible on the Ethereum 1.X chain and they are unlocked on the Eth2 chain as Beacon ETH. Processing this deposit takes a minimum of 7 hours, 1,024 blocks Ethereum 1.X blocks (~4 hours) + Epochs per Eth2 Voting Period (~3.4 hours). This delay protects against chain reorganization and double spends on Ethereum 1.X.

  3. Index Assignment: An index is assigned once a validator is added to the list of validators on Eth2. The index is permanently tied to the validator entered into the deposit contract and cannot change from the time of the initial deposit until the validator exits and fully withdraws. The validator immediately joins the validator registry but is inactive.

  4. Validator Activation: The validator becomes active after a minimum of 4 epochs (25.6 minutes) to ensure the RANDAO is not able to be manipulated. The period may exceed 4 epochs if many validators join at the same time. The validator entrance queue and the corresponding exit queue ensure stability of the validator set and that there are no issues with finality due to a lot of validators going offline simultaneously. 

Only 900 validators can be activated a day (4 per epoch) until 327,680 active validators are in the network. Once that goal is achieved, 1125 validators a day (5 per epoch) can be activated in an epoch. 

The number of validators that can be activated every day increases by 225 (an additional 1 per epoch) with every additional 64k validators. The same pattern applies to validator exits. This could result in congestion — a wait of a few hours or days — if validators attempt to join or leave the network simultaneously.

Consensus

Proof of Stake consensus on eth2 functions using two key processes:

  • LMD GHOST (Last Message Driven Greediest Heaviest Observed SubTree) adds new blocks and decides the head of the chain. GHOST quickly and efficiently adds blocks to the chain.

  • Casper FFG (Casper, the Friendly Finality Gadget) makes the final decision on which blocks are part of the chain by finalizing epochs. FFG provides security by finalizing epochs.

When the network is functioning normally — when two-thirds of validators vote on new blocks — the blocks are added to the head of the chain by GHOST and are justified and finalized by FFG in approximately 12.8 minutes.

If there is an attack, or a large number of validators are offline, GHOST will continue to add new blocks to the chain while FFG stops finalizing blocks until the network is stable. GHOST may change the head of the chain during this period. If blocks continue to be produced but not finalized, eth2 uses a mechanism called an inactivity leak to slash the balances of offline validators until enough stake is online to achieve finality.

Staking on eth2

eth2 allows participation on the network for a broader set of token holders than most PoS chains. 32 ETH represents a relatively low staking requirement and low entry point for running a validator that earns rewards. Please note: there is no delegation or stake pooling at the protocol level.

  1. Generate keys: To run an eth2 validator, two keys must be generated — the validator key and the withdrawal key. The withdrawal key is the custodial key where the ETH on the Beacon Chain will be withdrawn from in a later phase. Please note: the withdrawal key should be secured and backed up as a cold key or stored in a hardware wallet or offline device.

  2. Deposit ETH: After keys are generated, a token holder can deposit ETH into a smart contract on the Ethereum 1.X mainnet. This contract is unidirectional: the deposited tokens are inaccessible on the Ethereum 1.X chain and they are unlocked on the eth2 chain as Beacon ETH. Processing this deposit takes a minimum of 7 hours, 1,024 blocks Ethereum 1.X blocks (~4 hours) + Epochs per eth2 Voting Period (~3.4 hours). This delay protects against chain reorganization and double spends on Ethereum 1.X.

  3. Index Assignment: An index is assigned once a validator is added to the list of validators on eth2. The index is permanently tied to the validator entered into the deposit contract and cannot change from the time of the initial deposit until the validator exits and fully withdraws. The validator immediately joins the validator registry but is inactive.

  4. Validator Activation: The validator becomes active after a minimum of 4 epochs (25.6 minutes) to ensure the RANDAO is not able to be manipulated. The period may exceed 4 epochs if many validators join at the same time. The validator entrance queue and the corresponding exit queue ensure stability of the validator set and that there are no issues with finality due to a lot of validators going offline simultaneously.

Only 900 validators can be activated a day (4 per epoch) until 327,680 active validators are in the network. Once that goal is achieved, 1125 validators a day (5 per epoch) can be activated in an epoch.

The number of validators that can be activated every day increases by 225 (an additional 1 per epoch) with every additional 64k validators. The same pattern applies to validator exits. This could result in congestion — a wait of a few hours or days — if validators attempt to join or leave the network simultaneously.

Rewards on eth2

Validators earn three types of rewards for participating in consensus.

  1. Proposer rewards are earned by validators when they are randomly selected as a proposer and perform the duty of producing a block on chain. The proposer’s efforts are rewarded if they include a proof from a whistleblower that results in a validator being slashed and they include attestations from other validators.

  2. Attester rewards are earned by the validators selected to vote and agree with a decision on eth2. Attestations (votes) are the basis of consensus and are rewarded in five ways: (1) getting an attestation on-chain, (2) agreeing with other validators on the history of the chain, (3) agreeing with others about the head of the chain, (4) getting their attestation on-chain quickly, and (5) pointing to the correct block in the assigned shard.

  3. Whistleblower rewards are earned by a validator that provides proof on-chain that another validator has committed a slashable offense.

The inflation rate on eth2 decreases as the staking rate increases. Because so much depends on how many people lock up ETH to support the transition to eth2, it is difficult to clearly identify a rate of inflation and reward rate. Given the risks and opportunities apparent with eth2, we assume that:

  • In the short-term, there will be about 1 million ETH staked resulting in an inflation rate of .17% and a reward rate of 18.10%

  • In the medium-term, there will be about 10 million ETH staked resulting in an inflation rate of .54% and a reward rate of 5.72%. 

Rewards are designed to incentivize early validators starting at a 23% rate of reward at network launch. Anyone considering participating on eth2 benefits from running their validator as early as possible.

Rewards do not compound on eth2. They are earned based on the effective balance on the validator, which is capped at 32 BETH. As long as the validator is earning rewards and not being penalized, the true balance will start at 32 BETH and increase while the effective balance will remain consistent at 32 BETH. After Phase 2 is live, validators will be able to withdraw all their rewards, combine them, and run additional validators.

Parameters

Token name

ETH

Initial token supply

524,288 ETH locked (needed to launch Phase 0)

Total planned inflation

Infinite *see EIP1559 information above

Maximium token supply

Infinite

Inflation

Variable, but expected to be: .17% in the short term .54% in the medium term

Target staking rate

N/A

Expected reward rate (pa)

Variable, but expected to be: 18.10% in the short term 5.72% in the medium term

Maximum stake

32 ETH per validator

Minimum stake

32 ETH per validator

Lock-up period

Variable depending on amount of simultaneous unbonding. Minimum of 27 hours.

Reward compounding

None, beyond an effective balance of 32 ETH

Rewards distribtuion

Rewards accrue on validator until withdrawn by the withdrawal key

Rewards frequency

All rewards and penalties are applied at the end of each epoch (6.4 minutes)

Risks of participation on eth2

On eth2, validators can experience penalties and slashing. Penalties are significantly less severe than slashing.

Penalties act like negative rewards. If a well-performing validator can make a 10% reward rate in a year, a poorly-performing validator could lose 10% in the most extreme circumstances, such as being offline regularly or voting on blocks that do not get finalized. In most circumstances, the penalty for being offline is simply not earning rewards. If a validator is online greater than 53.6% of the time, assuming no inactivity leak, it will break even.

Slashing carries a heavy punishment for validators that commit a significant offense, burning a minimum 1 BETH and a maximum of the entire stake. The validator is automatically ejected from the Beacon Chain active set.

The two slashing conditions for validators are:

  • Double voting (double signing): when a validator votes for two different blocks during the same epoch, signalling support for two different versions of reality

  • Surround voting (double attesting): when a validator attests one version of reality—i.e. chain state—and later attests to another version without reconciliation

Emitting a slashable vote is uncommon for validators that correctly follow the protocol: forming a slashable message without malicious intent only occurs as a result of some bug or accident. Because these errors are bound to happen, eth2 minimizes the slashing amount by destroying stake in proportion to the number of validators slashed around the same time.

However, if a large number of validators commit an offense at a similar time, a large amount of their stake is burnt (up to their full balance) because an attack is assumed. This is called correlated slashing. All slashed validators, whether due to a mistake or a malicious act, are forcibly exited from participating in the protocol and can not return until Phase 2. This prevents validators from further harming themselves by being slashed again and from harming the network in case of an attack.

Beyond penalties and slashing, there are two other forms of punishment on eth2: inactivity leak penalty and forced exit.

  • Inactivity leak penalty is rare, but due to the extreme danger a lack of finality poses to the network, is severe. The goal of this penalty is to return stability to the network if it stops finalizing blocks due to more than a third of validating stake going offline simultaneously. If more than four epochs pass since finality, balances are gradually reduced on offline validators until the ratio of online validators to total validators (weighted by stake) exceeds two-thirds. This ratio is necessary for the network to continue making decisions as a protocol. For example, if 50% of validators are offline, blocks will take 18 days to start finalizing again. During this period, attestation rewards are zero but validators earn proposer and whistleblower rewards.

  • Forced Exit is the deactivation of validators whose balance falls below 16 BETH due to penalties. The remaining balance can be withdrawn in Phase 2 but the validator can not reenter the active set even if it is topped up with additional ETH.

Governance on eth2

Ethereum operates using off-chain consensus building. You can learn more about Ethereum's governance in their documentation, as well as reading about the governance vision for eth2.

Why operate eth2 validators with Coinbase Cloud?

To support eth2, Coinbase Cloud offers a suite of enterprise products including:

  • Private, secure, and reliable read and write nodes to connect and interact with the Beacon Chain

  • A secure validator management API enabling the creation and management of validators and Beacon Chain nodes

  • A fully featured Participate Cluster product allowing our customers to manage their Beacon Chain and validators from within the Bison Trails platform

  • A fully indexed eth2 Beacon Chain reporting API to call information including staking rewards, validator information, and more

Because stake and rewards are locked up for several years on eth2, choosing an infrastructure provider you trust is an important consideration. It is risky to change providers because transfering a validator requires sharing the private key, risking slashing. Bison Trails has been running secure, reliable, and redundant Ethereum 1.X Geth nodes for 2 years. We were one of the early validators on the first eth2 client testnet and have been participating in various testnets for the past year.

Coinbase Cloud runs participate clusters across multiple availability zones and cloud providers. Your nodes have near-infinite resiliency and unmatched availability. We designed an intuitive user experience that is surprisingly simple given the complexity of the underlying technology. Our platform’s automatic node management workflow reduces the challenges of manually managing active network participation, while keeping our customers in full control of their infrastructure. We provide 24/7 monitoring and support to keep your infrastructure safe with best-in-class security architecture for key management using CloudHSM and YubiHSM hardware.

アプリをダウンロード