Lido Explained, Part 2: Consensus & Withdraw

Introduction

In our previous article from this series, we explored the history of the Lido protocol’s development, discussed the components of its architecture, and how they interact with each other.

In this part of the article, we will dive into how the Ethereum Consensus and Lido withdrawal module are structured. We highly recommend reading the first part of the series beforehand to catch all the details.

As mentioned earlier, to deeply understand the withdrawal mechanism in the Lido protocol, it’s essential to first explore the consensus in Ethereum itself, especially since the transition to version 2.0 brought significant changes.

Before diving in, we need to agree on some definitions that will be used further. Our definitions will be somewhat generalized to maintain a consistent context.

• Beacon Chain is the name given to the updated version of the Ethereum ecosystem’s blockchain. It’s based on the Proof of Stake (PoS) paradigm and was launched in 2020. This chain is responsible for coordinating and facilitating interactions among network validators and shard chains, support for which will be added in future updates. Consider this part of the ecosystem as the heart of the Consensus Layer, a concept we’ll define shortly.
• Consensus Layer is the level responsible for verifying blocks, organizing them, and ensuring that validators successfully reach agreements among themselves. It’s similar to a “rulebook,” containing instructions for every stage of the Ethereum protocol’s operation.
• Execution Layer is the level that provides an environment for applications and smart contracts to function and process transactions within and between applications. It is at this layer where the processing and accumulation of all network changes in the form of transactions take place.
• Validator is software running on the computational power of a specific node, encompassing a set of rules and instructions that regulate the activity of all nodes. Each validator is a full participant in the network, obligated to contribute to maintaining network functionality by performing its duties, which we’ll discuss later.
• Block Proposer is a validator randomly selected by the Beacon Chain to create and distribute a new block across the network.
• Block Attester is a validator that checks the correctness of the new block’s content (created by the Block Proposer) before it is distributed across the network.

Let’s start by examining the core rules of network operation, united by the common concept - the Network Layer.

Network Layer

First, let’s establish that the Network Layer is essentially a stack of protocols standardizing the communication process among thousands of Ethereum network nodes. It enables them to engage in both one-to-one and one-to-many communications, following unified rules applicable to all network participants. Every node must adhere to these rules to ensure it correctly sends and receives data about the network’s state.

General scheme of interaction

With the upgrade to version 2, the network was split into two chains that support each other. One handles transactions (Execution Layer - EL), while the other (Consensus Layer - CL) manages the construction of the master chain from sequential blocks in the form of a directed acyclic graph, commonly associated with blockchain. To keep this structure operational, its participants use a Network Client, which in turn consists of a Validator Client and an Execution Client, each operating on their respective layers.

Let’s look at the diagram below to understand how EL (eth1) and CL (eth2) interact with each other.

• The diagram shows that EL first takes the beacon state from CL, then synchronizes it with the EL state, processes transactions from the TX Mempool using the EVM, updates the EL state, and sends it via RPC to CL.
• Based on the results from EL, CL creates new beacon blocks, attests and finalizes them, recording the results in the main consensus chain.
• Both levels form a peer-to-peer network and operate in parallel. Each level has its client (EL Network client & CL Network client, respectively), and each type of client has its network stack.

The EL Network client distributes tx blocks data through the peer-to-peer network, while the CL Network client distributes beacon blocks data. This data distribution across the network begins only after it has been validated by built-in mechanisms, which we will discuss later.

As the diagram illustrates, both levels exchange information via RPC requests. An API, known as Engine-API, defines the instructions passed between the two clients. It’s crucial to understand that Consensus Client and Execution Client form a unified system that always operates in tandem and parallel, simply performing different tasks at each network level.

Consensus Layer

So, let’s take a step back. For a block to be validated, agreed upon by all validators, and finalized, Execution Layer nodes accumulate information about state updates from network transactions until the block’s gas limit is reached, after which the collected information about the updated state is transmitted to the Consensus Layer. Essentially, the whole algorithm is divided into three main stages, which we will now examine:

[I] Block Creation [II] Block Attestation and Distribution [III] Block Finalization

[I] Block Creation

One of the CL clients is randomly chosen by the network to process, validate, and distribute a new block in the peer-to-peer network. There’s only one block proposer, leading to two possible scenarios for validator behavior:

[1] When the CL client is the block proposer. [2] When the CL client is not the block proposer (= is a block attester).

Each of these two scenarios has its tasks, and we’ll start by looking at them. First, let’s consider scenario [1], where the CL client is the block proposer. To simplify understanding, let’s examine the diagram below:

You might ask, “What exactly is happening in this diagram?”. It represents the interaction algorithm between the peer-to-peer network and the block proposer itself, consisting of 6 steps:

1. Using the RanDAO mechanism, which assigns roles to network validators and which we will discuss further, a block proposer is chosen.
2. At the EL level, the block proposer is granted access to the EL state and mempool, and the “Create block” method is invoked.
3. The block proposer extracts all “pending” transactions from the mempool.
4. Applies these transactions to the current state, gets a new block and its hash.
5. Distributes the new block through the Consensus Layer P2P.
6. Completes its lifecycle.

[II] Block Attestation and Distribution

Okay, as we’ve seen, the chosen client has successfully fulfilled its role. But what are all the other consensus clients, who didn’t get to be the block proposer, doing in the meantime? They are rechecking the block proposer’s work to minimize the risk of approving false information for the entire network. This process is known as Block Attestation. Let’s look at the diagram below to understand this better.

Based on the diagram, let’s examine the flow of the block attester:

1. After the block proposer has distributed the new block via Consensus Layer P2P, validators acting as block attesters first conduct a pre-validation of the received data at the level of their Consensus Client. They check the correctness of the sender’s address and the structure of the sent data to ensure it matches the metadata.
2. Then, using the same RPC connection, the pre-validated block is sent to the Execution Client, where the attester reconstructs the transaction hash tree to check the block header, as well as verifies the transactions themselves.
3. If everything is successful, the block attester, by further distributing the block through the peer-to-peer network, effectively casts its vote for it. If 2/3 of the validators do the same (= a Supermajority is reached), the block moves into the finalization phase.

As the diagram shows, the main task of block attesters is to independently recheck and validate the block proposer’s work, preventing the spread of false information by malicious nodes (this concept is known as Byzantine Fault Tolerance).

[III] Block Finalization

Block Finalization is the process of ensuring that a block can under no circumstances be altered or removed from the chain. This is crucial for economic security, allowing network participants to rely on strictly accurate, recorded data for their activities. The determinism of finalized blocks can only be disrupted if more than 33% of the total staked ETH is burned, which is improbable.

However, for a complete understanding of the finalization process, we will momentarily shift our focus away from the Network and Consensus layers to explore the workings of the Beacon Chain and Sync Committees. After this, we will return to the discussion of block finalization.

Beacon Chain & Sync Commitees

Now that we understand the creation, validation, and distribution of new blocks, as well as the role each network layer plays in these processes, let’s look at how the Beacon Chain, the heart of the Consensus Layer, operates.

To prevent network validators from colluding and collectively including incorrect blocks in the main chain, the Beacon Chain employs Sync Committees - a “flagship feature” of the Altair hard fork (activated on October 27, 2021). To grasp its significance, let’s first discuss the architecture of the Beacon Chain. The life cycle of this network is divided into Epochs, which are separated by the following rule.

⌛ 1 Epoch = 32 Slot = 32 * 12 sec = 6.4 min

Each epoch, the RanDAO mechanism ensures that all active validators are evenly distributed across slots.

• Epoch is a conditional unit of time, within which the Ethereum protocol completes a full cycle of its operations. Each epoch, the protocol processes information from transactions, forms a new block, attests it, and includes it in the main chain, which ensures continuity between epochs.
• Slot is an opportunity window for a new block to be added to the Beacon Chain. Every 12 seconds, assuming optimal system performance, a new block is added to the chain. A slot is somewhat similar to block time, but slots can also be empty if validators fail to reach an agreement or if transaction processing is not optimal.
• RanDAO is an algorithm for generating pseudorandom outputs, responsible for selecting block proposers (according to their balance values) and block attesters (according to their distribution in sync committees) in the Beacon Chain. All participants first locally select a pseudorandom number, then each participant sends the hash of their chosen number. Subsequently, participants reveal their chosen numbers in turn, and perform an XOR operation on the revealed numbers, with the result of this operation becoming the protocol’s output.

Within slots, block attesters are distributed into committees with a minimum of 128 validators each (up to 512 maximum). These committees are called Sync Committees, and they are needed for independent verification and securing changes in the state of the entire network. Using such committees allows light clients to track the chain of beacon block headers. Also, one of the validators in each slot is appointed as a Block Proposer, as we discussed earlier. All validators within the committee attest to blocks, but strictly within the time frame of their assigned slot. This cycle repeats every epoch. Below you can see a graphical illustration of this process.

Alright, we’ve covered the mechanism for attesting new blocks. But how are they finalized? Let’s understand this with the diagram below, which illustrates the flow of finalizing a new block.

As shown in the diagram, during normal network operation, each block passes through three states:

1. Block Proposed | This state is assigned when the signatures of the block under consideration have been entered into the Beacon Chain during Epoch 0. In the next epoch, validators must vote for them.
2. Block Justified (Attested) | This state is assigned if, at the start of Epoch 1, at least 2/3 of the validators have voted for the block proposed in Epoch 0.
3. Block Finalized | This state is assigned to a block from Epoch 0 at the end of Epoch 2, if the block proposed in Epoch 1 has achieved Justified status.

Once a block is successfully attested and is to be given the “Finalized” status, the Gasper algorithm comes into play, which is a combination of two components:

1. Casper-FFG | friendly finality gadget | updates the block to a finalized status, so new network participants can be sure they are synchronizing the only correct chain.
2. LMD-GHOST | fork choice algorithm | uses accumulated votes to ensure that nodes can easily choose the correct option when forks occur in the blockchain.

We have understood the processing, validation, and finalization of blocks at the scale of the entire Consensus Layer. We have also looked at how validators interact with each other. But what about the behavior of an individual validator? How does it make a deposit, become activated, and deactivated? Without understanding these aspects, we cannot comprehend the withdrawals. Let’s delve into this.

Validator Lifecycle in Ethereum

To answer questions about how validators are activated and the risks they face, we need to study their lifecycle and analyze how it is interconnected with withdrawals in the context of the Lido protocol. Let’s take a closer look at their activation and deactivation process.

The entire process of validator activity in terms of balance changes can be illustrated by the diagram below. It shows how the balances of a validator’s address (Account 1) change and how funds are distributed during the native deactivation of a validator (Account 2).

On the Execution Layer side, the majority of operations are managed by the deposit contract, which serves as the entry point for anyone wanting to activate a validator. The deposit contract receives user funds and sends a deposit receipt and request for activating a new validator to the Consensus Layer. What follows is what we have already discussed.

When processing a validator’s deactivation request, the Consensus Layer calculates rewards and penalties for each validator, after which funds are transferred to the specified address (Account 2).

As you can see, most parts of this diagram are already clear to us, with the activation and withdrawal processes of new validators from the network being the only blind spot. Let’s address this.

The lifecycle of Ethereum network validators is divided into 6 main steps:

1. Deposited

   • At this stage, it is verified that the validator has deposited a sufficient amount and that the period of validator activation has not yet been set.
   • After successful verification, the validator enters the activation queue.

2. Eligible to be activated (Pending)

   • Before activation, it’s checked that the validator’s right to be activated was finalized in the previous epoch, and that the validator has not yet been assigned a future activation epoch.
   • After successful verification, the validator is removed from the queue and assigned a future activation epoch.

3. Activated

   • When the activation epoch arrives, each epoch, the validator starts to take on either the role of Block Proposer or Block Attester and fulfill the assigned duties. There are three scenarios for how this activation stage can end:
   • [3.A] If the validator’s actions harm the network state, other validators sanction the slashing of this validator, leading to its forced ejection with a 36-day deposit return delay.
   • [3.B] If the validator is frequently penalized by the network and its balance falls below the minimum threshold, forced ejection occurs.
   • [3.C] If the validator initiates deactivation, after 2^11 epochs (~9 days), it can proceed.

4. Slashed and Ejected (EXITED)

   • As mentioned in [3.A], there’s a 36-day delay imposed on the validator.
   • Slashing is burning a portion of the validator’s funds and ejecting them from the active set of validators chosen for the current epoch. To avoid slashing, the block proposer must refrain from proposing two conflicting versions of a new block for one slot, and the block attester must avoid signing two conflicting attestations.
   • Ejecting is simply deactivating the validator from the network and returning all rewards. If the validator violated network rules, it will be slashed during ejecting. If the validator acted honestly, only ejecting with a reward return occurs.

5. Unslashed and Ejected (EXITED)

   • In cases [3.B] and [3.C], validators wait about 27 days, then receive “Withdrawable” status.

6. Withdrawable

   • At this stage, the validator’s deposit becomes available for withdrawal, and the cycle ends.

For a more visual representation, we suggest you study the diagram below, based on our explanations:

In the context of the Lido protocol, validators play the role of the protocol’s “workforce,” generating income like a regular employee at a company, and upon their departure, the protocol receives the accumulated work results, pays the validator for their labor, and reallocates the earned funds for other purposes: in our case, this includes paying off other obligations and creating new “workforce”.

Now, we have reviewed and repeated everything necessary to delve into the technical details of the withdrawal process.

Specific of Lido Withdrawals

Does a validator’s lifecycle always proceed without incident? Are there any risks for a validator in carrying out their activities? Do these risks affect the operation of the Lido protocol in any way? Things are not always straightforward; let’s explore this.

Validators Risks

Throughout the process of interacting with the Beacon Chain, Lido protocol validators face certain risks:

1. Double Finality

   • This is an unlikely but serious condition where two forks can finalize simultaneously, creating a permanent split in the chain. Theoretically, this is possible for a malicious actor willing to risk 34% of the total staked ether. The community would be forced to coordinate actions off-chain and agree on which chain to follow, requiring social-level strength.

2. Finality Delay

   • This condition prevents the network from finalizing certain parts of the chain. Without finality, it’s challenging to trust financial applications built on Ethereum. The aim of a finality delay attack is likely to disrupt Ethereum rather than gain direct profit unless the attacker has some strategic short position.

3. Blocks reshuffling

   • Malicious reorganization can guarantee the inclusion or exclusion of certain blocks, allowing for double-spending or profit extraction through MEV.
   • Reorganizations can also be used to prevent certain transactions from being included in the canonical chain — a form of censorship. The most extreme form of reorganization is “finality reversion,” where blocks that were previously finalized are removed or replaced. This is only possible if more than ⅓ of all staked ether is burned by the attacker.

To the extent possible, Lido addresses these risks to ensure that the procedure for withdrawing funds from the protocol is conducted correctly. But how exactly does it do this? Let’s explore this in the next section.

Lido Withdrawal Considerations

Several key solutions are responsible for risk management: Exit Daemon, Lido Buffer, and Oracle Report Delay. Let’s examine each of these.

Using Ejector Daemon

• This component is used to inform about the need to remove Lido validators chosen from a number of existing exit requests. Its purpose is to protect and disseminate such reports through smart contract events.
• The Ejector Daemon has its own lifecycle and does not require coordination with Lido’s general oracle reports.

Using Lido Buffer

• The protocol strives to use the Buffer in such a way that the Ether stored in it spends as little time as possible in the buffer without movement, and also in the activation queue. This strategy maximizes the efficiency of capital use.

• The Buffer acts as an intermediary module, accumulating funds from user deposits, Execution Layer rewards, and Withdrawal Vault funds, and then either finalizes withdrawal requests with them or restakes them during the activation of new Beacon Chain validators. The diagram below visually depicts this process.

  

• Execution Layer Rewards are rewards that protocol receives from priority fees and MEV. According to LIP-12, after collecting, these rewards are re-staked in Beacon Chain.

• Withdrawal Vault is a contract where funds are received.

• User’s Deposits are the amounts of deposits that are directly sent to the buffer from users’ wallets.

Oracle report delay

• It is important to note that the fulfillment of requests only occurs when the oracle forms a fresh report on the state of the network. This delay is due to the inability to monitor updates from the consensus level to the protocol level in real-time.
• Additionally, the oracle report MUST provide data on beacon balance and withdrawals vault balance at the same time to prevent double accounting, which can occur because data on beacon balance is not directly accessible from the Execution Layer.
• You might also ask - “why aren’t withdrawal requests executed instantly?”. Instant execution would allow unscrupulous participants to avoid financial losses due to the slashing of validators, negatively impacting the capital efficiency of the protocol. Consequently, the protocol first pays for validator penalties, accounts for these financial losses on its balance, and then satisfies withdrawal requests. This maintains a high level of capital efficiency.

Lido Withdrawal Scenarios

Expedited exit (via protocol buffer)

Lido Protocol is designed to accumulate funds in the Buffer while an off-chain oracle decides on their distribution between user withdrawals and maintaining the process of creating new validators.

In the case of Expedited Exit, it’s assumed there are sufficient funds in the buffer, allowing the protocol to accelerate the process of returning deposits.

However, if the buffer lacks sufficient funds, the process of standard exit is initiated, which involves withdrawing validators from the Beacon Chain to ensure enough funds are available.

Standard exit (via network broadcast)

For this, the protocol identifies the next validator to exit based on a predetermined order and notifies the corresponding node operator of this decision. Subsequently, the time required for the validator’s withdrawal from the Beacon Chain and the redemption rate at which the user’s share in the stETH token will be converted back to ETH are determined. In this case, users face a time delay ranging from 6.5 to 50.5 hours, in addition to the time for Expedited Exit.

To make these decisions, the protocol requires information from the Consensus Layer, which is not directly available from the Execution Layer. The current version of the protocol relies on an oracle committee that provides this missing information for the protocol’s operation at the execution level, though this solution has its own issues related to MEV attacks.

In practice, members of the Oracle Committee are additionally tasked with signaling which validators will be exited next. Every N epochs, oracle participants analyze newly emerging withdrawal requests, calculate the list of next validators to be ejected using an algorithm approved by Lido DAO and implemented in the oracle’s code, and publish the list in oracle smart contracts. The algorithm must handle failures and delays in removing validators.

Delayed exit (in bunker mode)

In bunker mode, withdrawal requests are suspended until negative events are resolved.

For incidents leading to prolonged downtime, affecting tens/hundreds of thousands of validators, the expected delay is 1 day with a maximum delay of 7 days.

The expected delay in the event of mass slashings is 18 days with a maximum delay of 36 days.

Factors Affecting Withdrawal Completion Time

• The amount of stETH in the withdrawal queue
• The performance of the validator pool
• The size of the validator exit queue in the Beacon Chain
• Overall market changes in withdrawal demand and supply

We should also mention that stETH is a rebase token, which means that staking rewards are accumulated (minus a 10% fee that goes to Lido) and your stETH balance will increase over time.

Now, the final step is to integrate all three scenarios into a comprehensive picture - studying the Withdrawal Flow.

Withdrawal Flow

Let’s recall that in the first article of this series, we defined a simplified algorithm for users to withdraw their funds from the protocol.

Here is the diagram describing the Lido Withdrawals process you are already familiar with. Now, we will expand our understanding of it by adding a range of technical details.

Let’s look at the advanced algorithm for withdrawing funds from Lido, considering the material we have studied. But first, let’s break down what the Withdrawal Infrastructure includes.

Withdrawal Infrastructure - In our diagram, this is the combination of off-chain and on-chain components responsible for correctly processing withdrawal requests. It includes:

1. Withdrawal Queue

   • This contract is responsible for managing the validator exit queue. It maintains the funds from a validator’s balance before and after the finalization of their exit, then transfers the funds to Withdrawal Vault.

2. Lido Buffer

   • As discussed earlier, this contract accumulates funds from two types of vaults and user deposits, which are then redistributed between two main tasks: covering obligations for withdrawal requests and activating new CL validators through Deposit Contract.

3. Ejector Daemon

   • In the context of withdrawals, the Ejector Daemon is hosted by the node operator. It monitors the event log of the ValidatorExitBusOracle contract and, as necessary, sends the signature of the validator deactivation request to the consensus node.
   • After receiving the signatures of the requests, the consensus node deactivates them and distributes the message about the validators’ exit via Consensus Layer P2P.

4. Validator Exit Bus

   • To prevent the Ejector Daemon from needing to deactivate each validator in a separate iteration, the Exit Bus was devised.
   • It is a numbered list of all signed deactivation requests, allowing the withdrawal of all necessary validators at once.
   • This component is also convenient as it allows the Ejector Daemon to easily obtain all the necessary information for its operation from one place.

5. Ejector Oracle

   • We will discuss the oracle in more detail in the next part, but in the withdrawal process, the Ejector Oracle is responsible for collecting and disseminating information about Lido validators at the consensus level, based on which the Ejector Daemon decides on the next validator to exit.
   • More importantly, this component is responsible for predicting the amount of available ETH after the last validator withdrawal request (which the protocol has already submitted and cannot cancel) is executed. This is necessary to make the exit of precisely the number of validators the protocol needs at the moment, otherwise capital will be less efficiently used due to idleness in the Buffer.

6. Withdrawal Vault

   • Let’s just repeat that all validator deposits are sent here from the Buffer after their deactivation request has been finalized.

7. EL Rewards Vault

   • Rewards earned by Lido protocol validators for their participation in attestation and creating new blocks are delivered here.
   • Funds from this vault, as well as from the Withdrawal Vault, go towards covering obligations for withdrawal requests and activating new validators.

Now that we have understood the infrastructure involved in the withdrawal algorithm, let’s look at the algorithm itself, considering all the additions from this part of the article.

1. The user submits a withdrawal request. An ERC721-token is minted, confirming the holder’s right to claim the deposit with rewards. It can be transferred to any address (and with it, the right to claim the rebased ETH). After claiming the funds, the NFT-token is burned.

2. Within the Withdrawal Infrastructure, a Withdrawal Queue is formed from all withdrawal requests.

3. Within the Withdrawal Infrastructure, the Exit Daemon selects the next validators for exit based on their balances.

4. The Ejector Oracle checks the mode in which the protocol operates (turbo/bunker).

5. If the protocol is in turbo mode:

   • ETH in the protocol’s buffer is used to execute requests.
   • If this amount is insufficient to fulfill all requests, the Ejector Oracle registers validators for exit from the Beacon Chain according to the list of unfulfilled deposit withdrawal requests.
   • Classic exit from Beacon Chain: Lido sends an exit message, each validator receives an exit epoch, after reaching which the funds from the stake go to the Withdrawal Vault.
   • After the funds return to the contract, rewards are calculated for each withdrawer.
   • The Ejector Oracle passes information about new withdrawals to the Accounting Oracle, which then issues an updated report for the entire protocol.
   • Funds become available for final withdrawal.

6. If the protocol is in bunker mode:

   • Withdrawal requests are postponed until the consequences of the incident that triggered “bunker mode” are resolved.

Withdrawal Flow

On the diagram, you can see the entire process we have discussed, but at the level of contract interactions. Above the arrows are the methods called and the inputs.

Bunker Flow

We will discuss bunker mode in more detail in the 3rd part of the series, in the context of oracles. However, for now, it’s important to know that bunker mode is a state of the protocol that arises due to an unhealthy number of slashes among Lido validators. Bunker mode is sanctioned by the oracle committee and temporarily suspends the ability to make withdrawals from the protocol until this mode is deactivated.

Complete Flow

Here you can see the complete flow of the protocol, which includes all modules and components. The main difference from our diagrams is that we divided the processes into 3 large groups to simplify the understanding of the whole picture.

Conclusion

So, we have examined this vast system in parts and assembled it into a unified picture. Now let’s draw conclusions!

We have understood how Ethereum 2.0 works, analyzed the risks of validators when interacting with it, learned how Lido processes these risks, and how the entire process of withdrawing funds from the protocol occurs.

However, to have a complete picture, we still need to delve into how Lido obtains funds to finalize these requests and how Oracle Infrastructure, consisting of off-chain and on-chain components, is involved.

In the next article, we will talk more about these two aspects:

[1] Deposit & Staking [2] Oracle Infrastructure

📢 To stay updated with the next part of our series and other exciting articles, subscribe to our blog!

References

I. Withdrawals

1. Withdrawals for Lido in Ethereum
2. Withdrawals: Automating Lido Validator Exits
3. Withdrawals: On Validator exiting order
4. Lido Withdrawals Design & Bunker Mode
5. Protocol accounting with enabled withdrawals
6. Lido protocol with enabled withdrawals. Audit scope
7. Lido on Ethereum. Withdrawals Landscape
8. Ethereum withdrawals with Lido Protocol

II. Consensus

1. ETH2 book. Consensus
2. Ethereum Beacon chain explainer
3. Gasper