Detailed explanation of the life cycle of Ethereum validators: How to ensure the normal operation of the Ethereum network?

PANews · 2023-02-18T07:15:02.000Z
Original text: "Understanding The Validator Lifecycle" by Jim McDonald Compiler: John Understand the life cycle of a validator Ethereum 2.0 uses proof of stake to ensure the security of its network. Computer processes called "validators" will vote for the next block to be packaged (hereinafter referred to as "witnesses"), and they will also propose to make themselves blocks are packed in. However, validators are not just "on" and "off": they go through a series of transactions during their lifetime. This article will provide an in-depth analysis of the life cycle of a validator, showing what happens during each state and state transition, what triggers the state transition, and the time required for each state transition (Note 1).
原文：《Understanding The Validator Lifecycle》by Jim McDonald
Compiled by: John
Understanding the Validator Lifecycle
Ethereum 2.0 uses proof of stake to secure its network. Computer processes called “validators” vote on the next block to be packaged (hereinafter referred to as “witnesses”), and they also propose to have their blocks packaged. However, validators are not just in an “on” or “off” state: they go through a series of transactions during their life cycle. This article will deeply analyze the validator life cycle, showing what happens at each state and state transition, what triggers the state transition, and how long each state transition takes (Note 1).
A symbol of time
In Ethereum 2.0, time is usually measured in epochs, which consist of 384 seconds or about 6 and a half minutes. For ease of understanding, time measured in this way is roughly translated into minutes, hours, and days, with accurate information available in the corresponding footnotes.
Life cycle overview
Before we dive into the details, let’s take a look at an overview of the validator lifecycle and the terms used to describe its different states.
Figure 1: Overview of the validator lifecycle
The following are the status tags:
Deposited - The deposit agreement has been accepted by the Ethereum 1.0 network Pending - The deposit agreement has been accepted by the Ethereum 2.0 network Active - The validator is witnessing and proposing blocks Exiting - The validator is in the process of suspending witnessing and proposing blocks Slashing - The validator was found to be cheating and is in the process of suspending witnessing and proposing blocks Exited - The validator is no longer participating in witnessing
A meta-state is also defined: witness, which is the state of all validators that participate in witnessing and proposing blocks (active, exiting, slashing). This state is important because validators in these states need to access the Ethereum 2.0 network to stay in sync with their duties to avoid being slashed.
Figure 2: Meta-state of witness
After defining these states, it is time to analyze each state and the transactions between them in detail.
Deposit status
The acceptance of the deposit agreement is the beginning of the validator lifecycle. Acceptance happens on the Ethereum 1.0 chain, because that is where the validator’s funds come from. At this point the Ethereum 2.0 chain is not aware of the deposit.
The validator will remain in this deposit state for approximately 7.5 hours (Note 2) to ensure that there is no chain reorganization that affects Ethereum 1.0 transactions and potentially invalidates the deposit agreement. After this, the validator will move to the pending state (Note 3).
Figure 3: Transition from Deposited to Ready to Process
Once the deposit has been on the Ethereum 1.0 chain for a sufficient amount of time, it will be added to the Ethereum 2.0 chain. This marks the validator as officially recognized by Ethereum 2.0. If at least 32 ETH have been deposited (Note 4), the validator is now ready to start witnessing.
The validators in preparation are placed in a queue: Ethereum 2.0 only allows a small number of validators to start or stop validating at a time (Note 5) to ensure a stable set of validators. If the queue is empty, the validators in preparation will become active after about 25 minutes (Note 6): if this is a very busy period, it may take days or even weeks for the validator to be activated. But once the validator comes out of the waiting queue, it will become active.
Figure 4: Transition from Ready to Active State Active State
Validators are expected to spend the majority of their lifecycle in the active state. Active validators participate in current witnesses at a rate of about once every 6 minutes, and occasionally do work on proposing blockchains (Note 7). Validators remain in the active state until one of the following happens:
The validator is penalized for not attending when required, causing the funds to drop below 16 ETH. The user requests to stop validating by sending an appropriate transaction (this transaction cannot be sent during the first 9 days of the validator becoming active). The validator is proven to be cheating.
In the first two cases, the validator is added to a queue of validators who wish to stop validating (validators leaving the active state are limited to one validator every few minutes, just like validators entering the active state)
Figure 5: Transition from active to exiting state
In the third case, the validator is added to a queue of validators that were found to be cheating to receive punishment.
Figure 6: Transition from active to slashing state
Note that it is possible to deposit additional ETH to an active validator by sending additional deposit agreements with the same validator (always remember that the effective balance cannot exceed 32 ETH). This helps avoid the situation where a validator's funds drop below 16 ETH and are added to the exit queue.
Exiting status
When an existing validator on the network expresses his intention to stop validating, whether voluntarily or involuntarily, he will not do so immediately but will enter the exiting state, continuing to participate in the same amount of witnesses and proposals as in the previous active state. This ensures the stability of the network and avoids the situation where a validator decides to leave and immediately stops performing his duties.
Similar to when a validator wants to go from the Ready state to the Active state, the validator leaving enters a queue that only allows a few at a time. Also similar to joining, the time spent in the Exiting state depends on the number of validators in the queue.
Figure 7: Transition from Exiting to Exited State Slashing State
A validator who is found cheating will be punished immediately with 1 ETH, which will be deducted from the balance. Then he will enter a penalty queue, which is similar to an exit queue, but it will be marked as requiring additional penalties. We will discuss this issue in the next "exited" state.
Figure 8: Transition from Slashing to Exited
A validator can be slashed while exiting and even after exiting (but before he can get his funds back). This prevents a situation where a validator cheats and then escapes punishment by exiting through the regular exit mechanism before his cheating is discovered. This leads to a slightly more complex state model.
Figure 9: Extended slashing conditions Exited status
When a validator reaches the exited state, he has officially completed his mission. He no longer needs to participate in witnessing or proposing blocks, and no longer needs to have information about the state of the Ethereum 2.0 chain.
After an exit, there is a final delay of approximately 1 day before funds can be transferred away from the validator. However, if the validator is marked as slashed, it will incur two additional penalties.
First, it takes longer before funds can be transferred in the exited state, 36 days (Note 9). Second, halfway through this 36-day period, he will suffer further deductions, the amount of which depends on the number of validators that were fined 18 days before the validator was found cheating and the number of validators that were fined 18 days after the validator was found cheating. The following figure shows the total percentage of a validator's effective balance loss (Note 10)
Chart 10: Comparison of the effective balance slashed as a percentage of the number of validators slashed on the network at roughly the same time
Once the 36 days are up, the remaining funds of the slashed validators can be transferred.
As can be seen in the lifecycle diagram, a quit validator cannot be re-entered into active state by any mechanism. That is, once a validator quits, its funds will remain dormant until they are transferred. Note that you cannot transfer funds in Phase 0 of Ethereum 2.0 - all quit validators' funds will remain in the validator until a fund transfer operation is introduced. The reason for the lack of a transfer operation is the lack of user accounts that can transfer ETH.
Extended validator lifecycle
Combining all of the above information will provide a more comprehensive picture of the validator lifecycle
Figure 11: Extended validator lifecycle
Understanding the conditions and time required to transition between different states is critical to ensuring the successful operation of the Ethereum 2.0 staking infrastructure. From the initial deposit to the withdrawal of funds, the lifecycle shows what can happen in each state and provides a clear explanation of the validator's behavior at any time.
footnote
Footnote 1: It is worth noting that Ethereum 2.0 does not set up an explicit state mechanism; that is, the names of the states are proposed by the author for ease of understanding.
Footnote 2: 1,024 Ethereum 1.0 blocks plus 32 Ethereum 2.0 epochs.
Footnote 3: This assumes that the deposit protocol requires the full 32 ETH. If the deposit protocol has less than this threshold, the validator will remain in the deposited state until more deposit protocols bring the validator's balance to at least 32 ETH.
Footnote 4: If not, then another deposit can be added to increase this validator's balance to this amount.
Footnote 5: Each epoch is (active + exiting + slashing validators)/65536, with a minimum value of 4.
Footnote 6: 4 epochs.
Footnote 7: A validator can only witness once per epoch, and there is only one designated validator to perform the proposer's duties per slot.
Footnote 8: 256 epochs
Footnote 9: 8192 epochs
Footnote 10: Note that because penalties can be up to 100% of the effective balance, a validator’s maximum penalty can never exceed 32 ETH, regardless of the validator’s actual balance.