Deeper dive into Ethereum 2.0: Part 1 | by JK | stakefish | stakefish | Medium

So you have made it here after reading through the Beginner’s guide to Ethereum 2.0! Are you ready to learn more about Ethereum 2.0? The following advanced sections will go into detail on how exactly Proof of Stake works and how some of the staking numbers are calculated. There are plenty of links to the relevant source materials, so you can start your own journey down the rabbit hole!

Deep dive into Ethereum 2.0 Proof of Stake architecture

Epochs and slots

Time on Ethereum 2.0 Proof of Stake is divided into slots and epochs. One slot is 12 seconds. One epoch is 6.4 minutes, consisting of 32 slots. One block can be created for each slot.

The first slot of every epoch is a checkpoint where prior blocks can become justified and finalized.¹ The exact mechanism on reaching finality will be discussed in the “Proposing and attestations” section.

Withdrawal and signing keys²

There are two sets of keys in Ethereum 2.0, a withdrawal key and a signing key. The signing key is responsible for signing the actions that your validator will need to perform on the network. Since validators will need to perform duties every epoch, your signing key will always need to be online. Being constantly online increases the probability of getting compromised. Therefore, in order to mitigate this risk, the power to control the funds on your validator is held in the withdrawal key. Your withdrawal key can be put in cold storage until you need to move your funds.

Validators and committees

You can start off as a validator on the Beacon Chain by locking up 32 ETH. This initial balance will not stay static and will change over time as your validator participates in the Proof of Stake process. Validators will have three primary jobs: proposing blocks, submitting attestations and monitoring other validators for any slashable offenses.

Validators are sorted into committees that are applicable for the following epoch through a pseudo random process called RANDAO. The current spec requires each committee to have at least 128 validators and for the entire network to have at least 128 committees.³ The committees serve to create efficiencies by aggregating attestations. We will get into what attestations are in the section below.

Proposing and attestations

One validator will be pseudo randomly selected for each slot to propose a block. In Phase 0, the main role of the proposing validator will be to collect all the attestation votes and any whistleblower activities into a block. If the selected validator fails to propose a block in time, then the network will progress without a block for that slot. Validators will only learn about which slot they can propose a block at the beginning of an epoch.⁴

At least 16 committees will be assigned the slot for which they need to submit an attestation vote 1 epoch in advance. Attestations are weighted by a validator’s effective balance with a maximum ceiling of 32 ETH. For example, if validators A, B and C have 16 ETH, 32 ETH and 48 ETH respectively, their attestation vote weights will be 20% (= 16/[16 + 32 + 32]), 40% (= 32/[16 + 32 + 32]) and 40% (= 32/[16 + 32 + 32]).

There are three types of attestation votes that a validator will submit.⁵

  • LMD-GHOST vote to determine the current height of the chainYour validator needs to vote on what the head of the chain is (the most recent block). This is referred to as the head vote.
  • Casper FFG votes to finalize blocksYour validator needs to vote on whether they agree with the most recent checkpoint. Once ⅔ of attesting validators agree, the blocks prior to that checkpoint becomes justified. This is referred to as the target vote.Your validator also needs to vote on whether they agree with the most recently justified checkpoint. Once ⅔ of attesting validators agree, the justified blocks prior to this checkpoint becomes finalized. This is referred to as the source vote.In summary, it will take at least one epoch, 6.4 minutes, for blocks to become justified and at least two epochs, 12.8 minutes, for blocks to become finalized.

If finalization does not happen for 4 consecutive epochs, a mechanism called the inactivity leak will kick in, penalizing validators that have stopped submitting Casper FFG votes. This penalization will persist until finalization can be achieved on the network.⁶ The magnitude of the penalization will be discussed in Part 2 of this series.

Slashing

In order to prevent malicious behaviors, specifically those that could fork the network, Ethereum 2.0 uses a mechanism called slashing. Your validator can be slashed for the following reasons.

  • Proposing two different blocks in a single slot⁷
  • Submitting two different Casper FFG attestations in a single epoch
  • Submitting a Casper FFG attestation that completely surrounds another Casper FFG attestation⁸

For posing a threat to the network, the offending validators will have their effective balance slashed. The magnitude of the decrease will be explained in Part 2 of this series. In addition to this balance reduction, the slashed validators will have a longer than average withdrawal delay. Typically, after exiting, validators would only need to wait 256 epochs (≈ 27 hours) to withdraw their ETH balance. For slashed validators, they will need to wait for 8,192 epochs (≈ 36 days) before the remaining ETH balance becomes withdrawable. In Phase 0, validators that have been ejected will no longer be able to join the active validator set.

Joining and exiting as a validator

Once you have 32 ETH on a validator node, you can signal your intention to start validating. After your intentions are relayed to the network, you are placed in the activation queue. Only 4 validators can be activated per epoch in order to prevent the validator set from changing too rapidly.⁹ Once it is your turn, your validator will get added to the active set in 4 epochs (≈ 25.6 minutes).¹⁰

Validators who have been active for at least 256 epochs (≈ 27 hours) can signal to the network to initiate a voluntary exit from the active validator set. Once the message has been relayed to the network, the validator will be put at the end of the exit queue. There is a limit to how many validators can exit per epoch, similar to the limit on activations per epoch.¹¹ If there are no validators in the exit queue, it will take at least 5 epochs (= 32 minutes) for the validator to exit. It will take another 256 epochs (≈ 27 hours) before any ETH balance becomes withdrawable. In Phase 0, validators that have exited from the active validator set will have no option to join again.

Forced ejection as a validator

There are two cases where a validator will be forced to exit from the active validator set. We have already discussed the first one in the Slashing section above, but we’ll cover another scenario where a validator could be forcefully ejected from the active set.

  • Getting slashedAs discussed previously in the Slashing section, validators getting slashed will be automatically put into the exit queue.
  • Validator balance falling to 16 ETH or belowIf a validator’s effective balance falls to 16 ETH or below for whatever reason, the network will automatically put the validator in the exit queue. The process will look a lot similar like a voluntary exit. Once the network observes a balance of 16 ETH and under, the validator will be put at the end of the exit queue. If there are no validators in the exit queue, it will take at least 5 epochs (= 32 minutes) for the validator to fully exit. It will take another 256 epochs (≈ 27 hours) before any ETH balance becomes withdrawable.

(To be continued)

Updates October 29, 2020

The following updates have been made after closely reviewing the erroneous statements on how the exit mechanism works. Thank you to

for bringing this to my attention:

  • Slashing: clarified to mention that slashed validators need to wait at least 8,192 epochs to withdraw their ETH balance after going through the exit queue.
  • Joining and exiting as a validator: corrected to reflect the fact that unless the exit queue is congested, exits can happen quickly.
  • Forced ejection as a validator: corrected to reflect the fact that unless the exit queue is congested, exits can happen quickly.