Understanding the Validator Lifecycle

Ethereum 2 uses proof of stake to secure its network, where computer processes known as “validators” cast votes on the next block to be included (hereafter "attesting"), as well as proposing their own blocks to include. However, validators are not simply "on" or "off": they go through a number of transitions during their lifecycle. This article examines the validator lifecycle in depth, showing what happens in each state and transition, what triggers transitions, and how long each transition takes¹.

---

A Note on Times

Ethereum 2 times are usually measured in epochs with 1 epoch being 384 seconds or around 6 and a half minutes. For ease of understanding times based on these measurements have been translated roughly in to minutes, hours and days, with exact information available in an accompanying footnote.

---

Overview of the Lifecycle

Before diving in to the details here is an overview of the validator lifecycle and the terms used to describe its various states.

Figure 1: Overview of the validator lifecycle

The labeled states are as follows:

• Deposited - a deposit agreement has been accepted by the Ethereum 1 network
• Pending - the deposit agreement has been accepted by the Ethereum 2 network
• Active - the validator is attesting to and proposing blocks
• Exiting - the validator is in the process of halting attesting to and proposing blocks
• Slashing - the validator is in the process of halting attesting to and proposing blocks, having been caught cheating
• Exited - the validator is no longer attesting

A meta-state is also defined: attesting, which is all of the states (active, exiting, slashing) in which a validator is expected to attest to and propose blocks. This state is important, because it is while the validator is in these states that it needs access to the Ethereum 2 network to stay up-to-date with its duties and not be penalized.

Figure 2: The attesting meta-state

With the states defined it is time to examine each in detail, along with the transitions between them.

---

The Deposited State

The acceptance of a deposit agreement is the start of the validator's lifecycle. This acceptance happens on the Ethereum 1 chain, as that is where the funds for the validator originate. At this point in time the Ethereum 2 chain is unaware of the deposit.

The validator will remain in the deposited state for approximately 7 and a half hours², to ensure that there is no realistic chance of a chain reorganization affecting the Ethereum 1 transaction and potentially invalidating the deposit agreement. After this time the validator will move to the pending state³.

Figure 3: Transition from deposited to pending

---

The Pending State

Once the deposit has been on the Ethereum 1 chain for long enough it will be included in the Ethereum 2 chain. This marks the point that the validator is officially recognized by Ethereum 2. Assuming that at least 32Ξ has been deposited⁴, the validator now prepares to start attesting.

The pending validator is placed in a queue: Ethereum 2 only allows a small number of validators to start or stop validating at a time⁵, to maintain stability of the validator set. If the queue is empty the pending validator will become active after approximately 25 minutes⁶; if it is a very busy time it could be days or even weeks until the validator is activated. Once the validator has left the queue, however, it will become active.

Figure 4: Transition from pending to active

---

The Active State

It is expected that validators will spend the majority of their lifecycle in the active state. Active validators will attest at the rate of one attestation every six minutes with the occasional proposal⁷. The validator will stay in the active state until one of three things happens:

• the validator's funds drop below 16Ξ, due to penalties imposed by not attesting when required
• the user asks to stop validating, by means of sending an appropriate transaction (cannot be sent in the first 9 days after it has become active)
• the validator is proven to have cheated

In the first two situations the validator is added to the queue of validators that wish to stop validating (the number of validators leaving the active state is limited in the same way as those entering the active state to around 1 every couple of minutes).

Figure 5: Transition from active to exiting

In the third situation the validator is added to a list of validators that have been found to be cheating, where punishment can be applied.

Figure 6: Transition from active to slashing

Note it is possible to "top up" an active validator with additional Ether if required (always remembering that effective balance cannot rise above 32Ξ) by sending additional deposit agreements containing the same validator information. This can help avoid the situation where validator funds drop below 16Ξ and the validator is added to the exit queue.

---

The Exiting State

Whilst an exiting validator has signalled its intention to stop validating, whether voluntarily or otherwise, it does not do so immediately. Instead, whilst in the exiting state, it carries on much as before, attesting and proposing as it did when active. This ensures stability of the network, avoiding the situation where a validator decides to leave and immediately stops carrying out its duties.

Similarly to the pending state when a validator wants to become active, there is a queue for exiting validators that only allows a few through at a time. And again similar to joining, the time spent in the exiting state depends on the number of validators ahead of it in the queue.

Figure 7: Transition from exiting to exited

---

The Slashing State

A validator that is caught cheating will suffer an immediate punishment of 1Ξ, which will be removed from its balance. It then enters the slashing state, which appears to be similar to existing however it is also marked as requiring an additional penalty, which will be discussed in the "exited" state below.

Figure 8: Transition from slashing to exited

It is possible for a validator to be slashed while it is exiting and even after it has exited (but before the time its funds can be withdrawn). This stops validators from cheating and then avoiding punishment by exiting through the usual mechanism before their cheating is noticed. This results in a slightly more complicated state model:

Figure 9: Extended slashing conditions

---

The Exited State

When a validator moves to the exited state it has officially finished its work. It will no longer be expected to attest to or propose blocks, and no longer has a requirement to have information about the state of the Ethereum 2 chain.

After exit there is one final delay of approximately 1 day⁸ before funds can be transferred from the validator. However, if the validator is marked as having gone through the slashing state it will suffer two additional punishments.

First, the time spent in the exited state before funds can be transferred is much longer, at 36 days⁹. Secondly, half-way through that 36-day period it will suffer a further deduction based on the number of other validators that have been slashed in the 18 days before and the 18 days after this validator was caught. The overall percentage of a validator's effective balance lost¹⁰ is shown below:

Figure 10: Slashed effective balance against percentage of validators slashed in a similar time

Once the 36-day period is up the slashed validator's remaining funds are eligile for transfer.

As can be seen from the lifecycle diagrams, there is no mechanism for an exited validator to become active again. As such, once a validator has exited its funds remain dormant until transferred elsewhere. Note that there is no ability to transfer funds in Ethereum 2 phase 0 - any funds in exited validators will remain in their validator until a transfer operation is introduced. The lack of transfer operation is a result of the lack of user accounts to which Ether can be transferred.

---

The Extended Validator Lifecycle

Bringing all of the above information together provides a more complete picture of the validator lifecycle.

Figure 11: Extended validator lifecycle

Being aware of the conditions required for, and time taken in, transitions between states is vital for ensuring the successful operation of an Ethereum 2 staking infrastructure. From the initial deposit to the withdrawal of funds, the lifecycle maps out what is possible in each state and provides a clear explanation for validator behavior at all times.

Footnotes

1. It should be noted the Ethereum 2 specification does not have an explicit state machine; as such, the names of the states have been selected by the author for clarity. ↩

2. 1,024 Ethereum 1 blocks plus 32 Ethereum 2 epochs. ↩

3. This presumes that the deposit agreement is for a full 32Ξ. If the deposit agreement is for less than this the validator will stay in the deposited state until additional deposit agreements are made to bring the validator's balance up to at least 32Ξ. ↩

4. If not, another deposit can be sent that tops up the validator's balance to this amount. ↩

5. $\frac{active + exiting + slashing \ validators}{65536}$ per epoch, with a minimum of 4. ↩

6. 4 epochs. ↩

7. Each validator attests one slot per epoch, and each slot has a single designated validator act as proposer. ↩

8. 256 epochs. ↩

9. 8,192 epochs. ↩

10. Note that because the punishment is up to 100% of effective balance the maximum punishment for a validator is never more then 32Ξ, regardless of the validator's actual balance. ↩