Loading
Settings

A note on Ethereum 2.0 phase 0 validator lifecycle

tags: eth2 v0.10.1

By @hwwhww 20200115
Special thanks to @djrtwo for the review.

Changelog

1. Introduction

The validator status is defined in the beacon chain spec with “beacon state transition” functions. This document describes the concept of validator status epochs and the cases of validator lifecycle in the view of “validator status transition” in phase 0. We also recommend you to read Serenity Design Rationale - The validator lifecycle to understand the deep meaning of some constants configuration.

2. Validator status

2.1. Statuses in phase 0

The validator may be in the following statuses:

  1. Deposited: the validator has made a deposit and has registered in BeaconState.
  2. Eligible to be activated (Pending): the validator is eligible to be activated.
  3. Activated: the validator is activated

    Note that the validator may be “eligible to be activated, but has not been activated yet”.

  4. Slashed: the validator has been slashed
  5. Exited: the validator is exited
  6. Withdrawable: the validator is withdrawable

    Note that the validator will be able to withdraw to EEs in phase 2

Note that in some cases, a validator can be in multiple statuses at the same time, e.g., an active validator may be “activated and slashed”.

2.2. Validator status epoch

To determine the status of validator, we maintain the status epoch fields for each validator in BeaconState. The fields include activation eligibility, activation, exit, and withdrawable.

These fields define that a validator is in statusx status when v.status_epochxcurrent_status. The default value of the status epoch fields is FAR_FUTURE_EPOCH, where FAR_FUTURE_EPOCH:=2641 epochs.

For example, if a validator v1, where v1.activation_eligibility_epoch is 100 and
v1.activation_epoch is 200.


By updating these fields, we can determine the validator statuses. Basically, the status epoch setting should follow:

activation_eligibility_epochacitivation_epochexit_epochwithdrawable_epoch

2.3. validator.slashed boolean flag

We use a slashed flag field in Validator to describe if the validator has been slashed.

You can find more information on slashing from the validator guide doc. Note that a slashed validator will be forced to exit (we will discuss the details in Chapter 4).

3. Rate-limiting activation/exits queues

To (i) ensure the validator set is stable enough between two points and (ii) ensure that finality guarantees still remain between two chains as long as a validator logs on often enough (weak subjectivity), we limit the activation/exit queues dynamically.

Some rationale is described in Serenity Design Rationale - Exiting.

3.1. Churn limit function

The churn limit computation algorithm is describe in get_validator_churn_limit.

|S|:=the size of set SVactive:=the active validatorschurn_limit(state):=max(MIN_PER_EPOCH_CHURN_LIMIT, |Vactive|CHURN_LIMIT_QUOTIENT)

For example, if the churn_limit(state) is 10, that means at the current epoch, only the first 10 validators in the activation queue could be initiated activation.

In normal operation with sufficient validators, CHURN_LIMIT_QUOTIENT dictates the maximum fraction of validators that can churn in a given epoch.

To ensure that validators can always activate/exit even when a low total validator count, MIN_PER_EPOCH_CHURN_LIMIT is in place.

4. Validator lifecycle

This section, we will explain each validator status transition step-by-step. The following is the state transition diagram:

Diagram

💡 Hint: click the image to see the full-size diagram.

4.1. Step 1. Deposited

The validator has deposited the deposit contract, and the corresponding Deposit operation has been processed.

In epoch-processing, step 1.a checks if the validator is eligible for activation queue:

4.2. Step 2. Eligible to be activated (Pending)

In epoch-processing, step 2.a checks if the validator is eligible for activation and is within churn limit:

Note that since we process epoch transition right after processing the last slot of epoch n. That’s why we have to add +1 to the status epoch.

After MAX_SEED_LOOKAHEAD epochs (:=4 epochs, ~25.6 minutes), the validator will be 3. Activated.

4.3. Step 3. Activated

The active validator will now be assigned duties each epoch (perform attesting, proposing, etc.) and gain rewards. Normally, we expect most validators will stay at the activated status for a long time.

4.3.1. Step 3.a Get slashed

If a validator misbehaves (i.e., double voting or surround voting), the other validator can create a slashing operation to catch it on-chain, and the misbehaved validator will get slashed.

Once the validator gets slashed when processing slashing operations, they will be forced to initiate exit, plus extra ~36 days delay before being withdrawable.

4.3.1.1. Initiate exit

To initiate exit, first, we check if the validator has not initiated exit before, i.e., v.exit_epoch=FAR_FUTURE_EPOCH. If so, we compute the exit queue epoch (see below), and then set validator exit epoch and withdrawable epoch.

Like the activation queue, The exit queue dequeue process is also based on the current churn rate:

exit_epochs(state) :={v.exit_epoch vV | v.exit_epochFAR_FUTURE_EPOCH}exit_queue_epoch(state) :=max{exit_epochs(state){current_epoch+1+MAX_SEED_LOOKAHEAD}}v.exit_epoch:=exit_queue_epoch(state)v.withdrawable_epoch:=v.exit_epoch+MIN_VALIDATOR_WITHDRAWABILITY_DELAY

4.3.1.2. Extra penal delay

The slashed and exited validators suffer from a lock-in period of 213 epochs (~36 days) before they become withdrawable. We have to delay withdrawalability by setting:

v.withdrawable_epoch:=max(v.withdrawable_epoch,current_epoch+EPOCHS_PER_SLASHINGS_VECTOR)

The reason why we set the penal delay twice is simply to reuse the helper function in spec.

The validator’s exit_epoch and withdrawable_epoch are set, which will trigger the status transitions for exit and withdrawable.

4.3.2. Step 3.b Insufficient balance (ejection)

If a validator gets penalized, they lose portions of their balance. If the balance is too low, i.e., v.effective_balanceEJECTION_BALANCE, this validator is forcefully exited.

4.3.2.1. Initiate exit

As same as 4.3.1.1. Initiate exit.

The validator’s exit_epoch and withdrawable_epoch are set, which will trigger the status transitions for exit and withdrawable.

4.3.3. Step 3.c Voluntary exit path

The validator can initiate exit voluntarily by sending VoluntaryExit operation.

4.3.3.1. Minimum service time

For added validator set stability, the validator can only initiate exit if v.activation_epoch+PERSISTENT_COMMITTEE_PERIODcurrent_state, i.e., 211 epochs (~9 days) after activation.

4.3.3.2. Initiate exit

As same as 4.3.1.1. Initiate exit.

The validator’s exit_epoch and withdrawable_epoch are set, which will trigger the status transitions for exit and withdrawable.

4.4. Step 4. Slashed and Exited

The slashed and exited validators will suffer from a long lock-in period of 213 epochs (~36 days) before they become 6. Withdrawable.

4.5. Step 5. Unslashed and Exited

The unslashed and exited validators need to wait for 28 epochs (~27 hours) to become 6. Withdrawable.

This 27-hour waiting time is for:

  1. Ensuring that if a validator misbehaved, there is a period of time within which the error can be caught, and the validator can be slashed even if the exit queue is nearly empty. If so, their withdrawalability will be delayed as 4.3.1.2. Extra penal delay.
  2. Providing time for the last period of shard rewards to be included in phase 1.
  3. Providing time for proof of custody challenges to be made in phase 1.

4.6. Step 6. Withdrawable

The withdrawable status is the end status in phase 0. Validators will be able to perform withdrawal in phase 2.