Post-Merge Era: The Breakthrough and Rebirth of Ethereum's New Consensus

Author: Frank Fan, 0xCryptolee, Arcane Labs

Ethereum has undergone a historic upgrade, entering a new phase of development. After The Merge, Ethereum will continue to advance in the direction of scalability and decentralization. The Merge is just the first step into the PoS era, and Ethereum still faces significant challenges, including the centralization of the validator community, scalability, and the Lazy Validator Problem, which continue to restrict the explosion of applications and the secure expansion of Ethereum. This article will start from The Merge and gradually analyze the consensus algorithm adopted by PoS, focusing on exploring the use of DVT technology to address the single point of risk for validators, and analyze Ethereum's issues and future development opportunities with practitioners. It is recommended that readers with a certain foundation in Ethereum read this article.

1: The Merge

1.1 Background The Merge is the largest technical upgrade in Ethereum's history, achieving the merger of the Execution Layer and the Consensus Layer on September 15, 2022. The most significant change is the switch of Ethereum's consensus from PoW to PoS. Figure 1: The Merge In addition, after the merge, Ethereum's energy consumption has decreased by nearly 99.95%. According to a tweet by Vitalik Buterin, the Ethereum merge will reduce global electricity consumption by 0.2%. Figure 2: Vitalik's views on Ethereum's energy consumption after the merge 1.2 Changes brought by the merge

• **Token issuance: ** The issuance of ETH tokens during the PoW era has stopped, and new ETH is only generated through PoS consensus. Ethereum's inflation rate has decreased, and when the base fee exceeds 15 gwei, Ethereum even enters deflation.

Figure 3: Total Burn after the merge

• **Staking rewards: ** Gas fees and MEV income are distributed to validators, with the staking yield for validators reaching 5-7%.

Figure 4: Rocket Pool staking yield

• **Withdrawals: ** After the merge, staked ETH cannot be immediately withdrawn; the withdrawal restrictions will be lifted only after the Shanghai upgrade. Additionally, when withdrawing, users cannot directly extract their funds. To avoid large-scale withdrawals, there are certain limits on the amount and timing of single withdrawals, so after withdrawals are opened, there will not be a large sell-off. Specific information can be referenced in EIP-4895: Beacon chain push withdrawals as operations.

• **Changes in data structure: ** The Consensus Block will include the hash value of the Execution Block, while the parameters related to PoW in the Execution Block will no longer be effective. The mixHash field will record Ethereum's native RANDAO random number for EVM calls, allowing Ethereum developers to directly use this random number in smart contract development.

Figure 5: Changes in data structure after the merge

• **Consensus replacement: ** PoW consensus has been replaced by PoS, and the original responsibilities of miners have been taken over by validators. There are now two chains that need to run two client nodes simultaneously: the Execution Layer Client (EL) and the Consensus Layer Client (CL).

Figure 6: Ethereum clients after the merge After switching to PoS consensus, Ethereum's algorithm has changed from Ethash to Casper FFG (Gasper). Compared to the previous algorithm, Gasper is more energy-efficient, as it does not require specialized mining machines to calculate difficulty values, but instead generates blocks randomly. Let's continue to explore Ethereum's consensus algorithm and block generation methods!

2: Gasper

Currently, 13,830,378 ETH are staked on the beacon chain, with 432,203 active validators (as of September 23, 2022). Based on the characteristics of PBFT, the number of validators on the beacon chain is large, leading to a high volume of network communication data. Simple PBFT is no longer suitable for the Ethereum network, so Ethereum has adopted PBFT ideas to improve and design its network architecture, using the Gasper algorithm.

Gasper serves as the finality gadget in the beacon chain protocol, determining which blocks should be recognized by participants as confirmed and immutable, and identifying which forked chain is the main chain during a fork. The finality of Gasper generalizes the concepts in the paper "Casper Friendly Finality Gadget (Casper FFG)."

Figure 7: Staking and validator situation 2.1 Concepts Figure 8: Epoch and Slot illustration

• Slot: After the merge, a Slot corresponds to a block, with a committee responsible for generating that Slot within 12 seconds.

• Epoch: Each Epoch consists of 32 Slots, with a duration of 384 seconds, or 6.4 minutes.

• Committee: Each validator committee is assigned a minimum of 128 validators, who will perform attestation operations for their respective Slots. One validator in the committee will be randomly selected as the Proposer to create blocks.

• Attestation: Each validator in the committee corresponding to a Slot must vote on the previous Epoch to ensure they acknowledge the transactions in that Epoch.

• Validator: With the switch to PoS consensus after The Merge, miners have been replaced by validators. Validators stake 32 ETH to become validators, responsible for block production and signing within each Epoch's Slots.

• Proposer: The Proposer is selected from the committee's validators using a random number generated by RANDAO, and is responsible for packaging the Slot block.

• Beacon chain: This is the PoS blockchain that replaces PoW consensus. Beacon chain nodes are used to mount Data Blobs transaction types, providing more storage space for Rollups.

2.2 Process At the start of an Epoch, RANDAO assigns a committee to each Slot for attestation of the previous Epoch.

Multiple aggregators are assigned to the 32 Slots of the current Epoch, aggregating the committee's attestations of the previous Epoch and recording them in the Slot block.

RANDAO determines the Proposer responsible for block production by generating a random number.

Figure 9: Committee block production During the current Epoch, each Slot's committee attests to the checkpoint of the previous Epoch when producing blocks. After two consecutive checkpoint attestations, the previous checkpoint is finalized. This process continues until all 32 Slots have successively attested to the checkpoint, marking the end of the current Epoch. When the first Slot of the Post-Epoch begins, the Pre-Epoch has reached consensus on finality, meaning the Post-Epoch has experienced both the Pre-Epoch and the current Epoch, totaling two rounds of Epochs (because if there are conflicting checkpoints outside of the two attestation checkpoints, it is inevitable that 1/3 of the validators have acted maliciously; for example, at block heights 32, 64, and 96, if the 64 height checkpoint is not reached until 96, then the 32 height checkpoint is finalized), taking 12.8 minutes, and the transactions are confirmed on-chain, achieving what is known as finality. 2.3 Features RANDAO provides on-chain randomness. The random number generated by RANDAO will be included in the Execution Layer Block, allowing smart contracts to directly use this random number. With the availability of native on-chain randomness, new applications in DeFi may emerge, such as gambling-related DeFi applications that can directly trust and use the random numbers generated by RANDAO. Figure 10: RANDAO 2.4 Latest Message Driven GHOST (LMD-GHOST)

In Ethereum's new PoS consensus mechanism, LMD-GHOST is used as the fork choice rule. When a fork occurs, GHOST selects the subtree that has received more message support. The underlying principle is that when calculating the chain head, only the most recent votes of each validator are considered, rather than any past votes, thus reducing the computational load required to run GHOST.

For those who want to learn more, you can refer to: https://eprint.iacr.org/2013/881.pdf 2.5 Associated Issues

• Increased communication and validation costs: Is it better to have more validators? Not necessarily. While increasing the number of validators benefits data availability sampling (DAS) and decentralization, it also means that more validators will be involved in each Slot, increasing the communication burden between aggregators and validators when collecting signatures. Additionally, the validation cost of aggregated signatures will also increase, which will inadvertently add to the burden on validator nodes.

• Long-range attacks: A long-range attack occurs when a validator withdraws their staked ETH on the beacon chain. They can use an old private key to maliciously fork a block they previously signed, as they no longer have any staked assets on-chain, quickly generating empty blocks up to the current block height to attack the network. This is a potential attack method that may arise in the future. Ethereum's design involves voting on Pre-Epoch checkpoints, with the idea of continuously pushing the initial state forward to avoid potential attacks.

3: Ethereum Staking Mining

3.1 Staking Staking threshold: Validators must stake 32 ETH as collateral to fulfill their responsibilities in consensus block production.

Responsibilities of validators: Produce blocks and attestations within the time specified by the protocol.

3.1.1 Staking Methods

• Solo Staking: The solo staking method allows individuals who want to stake 32 ETH to run a validator node on a cloud server. Besides choosing to run the node on a cloud server, they can also set up server equipment at home to run an Ethereum node. The difference is that running a node on a cloud service is more stable, reducing the risk of penalties due to power outages or network issues during network consensus, while setting up a node at home has the advantage of lower hardware and network service costs compared to cloud servers. Here, stakers can choose which hosting solution to adopt.

• Staking Pool: Since 32 ETH is a significant amount for ordinary individuals, small stakers who want to participate in network consensus may not be able to run their own nodes. Thus, staking pool solutions have emerged, with Lido being the main project offering a semi-decentralized staking solution. It has attracted a large amount of capital, becoming a leading solution in the field. There are also more decentralized solutions like Rocket Pool and Swell. Additionally, aggregation solutions like Unamano have emerged to help and develop the Ethereum staking field.

  In terms of node operation, Lido chooses to designate certain professional operators to run network nodes, which is a point of relative centralization, as operators hold the signing private keys, and users' assets partially rely on Lido and the operators. As for withdrawal private keys, before July 2021, the withdrawal address was a 6/11 multi-signature address, with the multi-signature private keys held by industry OGs. After July 2021, the withdrawal address points to an upgradable contract address managed by a DAO. Rocket Pool opts for a more decentralized approach, allowing anyone to run a node as an operator by providing 16 ETH and the necessary hardware and software. While this lowers the threshold for operators, Rocket Pool introduces $RPL staking to mitigate the risk of operator misconduct.

  The staking pool solution allows ordinary users to deposit small amounts of ETH into contracts to earn Ethereum mining rewards, while also returning interest-bearing tokens like stETH and rETH to release the liquidity of staked assets, further enhancing Ethereum's decentralization and capital efficiency, which is a direction highly favored by the community.

• CEX, centralized custodial institutions: In addition to Solo Staking and Staking Pools, centralized exchanges and various asset management institutions are also major participants in Ethereum staking, such as Coinbase and Binance, which have launched their own staking services to absorb small amounts of ETH for low-risk Ethereum staking mining. The three solutions have their pros and cons in terms of decentralization and security, depending on the trust of the stakers. However, it is undeniable that all three solutions have captured corresponding funds and users, jointly maintaining the security and decentralization of Ethereum.

3.1.2 Risks and Hazards

Is everything really fine after the merge? I think not necessarily. From the data in the following chart, we can glimpse the situation after the withdrawal restrictions on the beacon chain are lifted.

Figure 11: The direction of staked ETH after the merge

Currently, Ethereum's staking volume is mainly concentrated in Lido, Coinbase, and Solo Staking. After the merge, new Ethereum staking has largely flowed into relatively centralized institutions and protocols like Lido and Coinbase. Once the withdrawal restrictions are lifted, I believe that the previously staked Ethereum will be redistributed to Lido and Coinbase. Over time, Lido and Coinbase will control an increasing number of Ethereum validators and staking volume, ultimately posing a serious threat to Ethereum's decentralization. Once they control Ethereum, transactions attempting to break this situation will be rejected by large mining pools like Lido or Coinbase, as they will have the final say on whether your transaction to stake ETH on Ethereum can be included on-chain. Additionally, the newly generated ETH will also concentrate in the hands of those who already hold more ETH, as they will have a large amount of ETH when staking, which undoubtedly presents a new challenge to Ethereum's decentralization. We can expect the community and core developers to work together to address this issue. 3.1.3 Types of Rewards

• Attestation rewards: Each committee for every slot must attest to the historical block checkpoint of the previous Epoch. Successful attestations will earn attestation rewards, which are part of the validator's income. (High probability, low reward)

Figure 12: Attestation rewards

• Block rewards: Each Slot will have a validator as the proposer to package the block. The validator selected as the proposer can earn block rewards. (Low probability, high reward)

Figure 13: Proposal rewards

• MEV (Miner Extractable Value) income: In addition to gas fee income, MEV income includes revenues from sandwich attacks and other methods. According to EigenPhi data, the volume of sandwich attacks has exceeded 100M in the past week, with the highest volume approaching 400M. MEV income has become an important component of validators' income.

Figure 14: MEV situation after the merge 3.1.4 Types of Penalties

• Inactivity penalties: Failure to produce blocks as expected by consensus: failing to attest to blocks within the expected time.

• Malicious actions leading to slashing: Producing two blocks within a single Slot or performing two attestations; proposing incorrect blocks that violate Casper FFG consensus rules.

3.2 Types of Private Keys

• Signing private key: The signing private key is used for message signing by validators when fulfilling their responsibilities, including attesting and proposing blocks. This key will be used once every 6.4 minutes, or every Epoch.

• Withdrawal private key: The key used for withdrawing staked assets and block rewards, which needs to be stored offline. After the Shanghai fork, the withdrawal private key can be used to withdraw staked ETH and rewards.

3.3 ETH2 Staking Risks

• Private key theft: The signing/withdrawal private keys of ETH2 may be stolen.

• Single point of failure/validator effectiveness: Currently, validators exist and fulfill their responsibilities on a single machine or node. The protocol's strict rules prohibit common redundancy forms, such as running the same validator on multiple nodes, as this may lead to the validator being "penalized" (slashed). If using staking services, the keys are located on a cloud server (e.g., AWS). If any component fails, the validator will stop validating and be penalized.

4: Distributed Validator Technology (DVT)

In terms of staking, while we have decentralized staking solutions to lower the staking threshold and enhance the decentralization of staking services, there still exists a single point of risk at the validator level. Currently, a single validator runs multiple clients for the network. If there are network issues or physical factors like power outages, it can lead to inactivity penalties, and the slot may not be able to collect valid signatures. We cannot run the same validator node in multiple locations redundantly, as this would cause signature confusion and be considered an attack on the network. However, we can split the signing private key and use DVT technology to reduce the risk of single points of failure, providing upgrade space for nodes during implementation, and preventing large-scale node outages due to network upgrades. Let's explore this in detail! 4.1 Concepts

• Operator: An individual or entity running one (or more) nodes.

• Operator node: Refers to a hardware and software setup that performs the tasks of an Ethereum validator. These tasks can be completed by the node independently or in collaboration with other nodes using DVT tools.

• Distributed Validator Technology: This technology distributes the work of a single Ethereum validator across a group of decentralized nodes. Compared to running a validator client on a single machine, distributed validator technology can provide more secure and decentralized services.

Figure 15: Relationship between Validators, Nodes, Committees, and Operators 4.2 Distributed validator nodes need to run

• Ethereum execution layer client

• Ethereum consensus layer client

• Ethereum distributed validator client

• Ethereum validator client

4.3 How DVT mitigates ETH2 staking risks

• Private key theft

1. Using threshold signature technology (m-of-n) can prevent the risk of private key theft.

2. A complete validator key is split into multiple smaller keys.

3. The split smaller keys generate a complete key signature through aggregation.

Figure 16: Key splitting and aggregated signing

• Node downtime

1. Crash Faults:

   Causes: Crashes due to power outages, network disconnections, hardware failures, or software errors;

   Mitigation: Prevent node downtime through a redundancy backup plan that runs the same node in multiple locations.

2. Byzantine Faults:

   Causes: Caused by software bugs or network attacks;

   Mitigation: Multiple participating nodes reach consensus, preventing a single node from making decisions. 4.4 Overall Architecture Figure 17: Overall architecture of DVT

• Distributed validators use key sharding to remotely sign messages.

• Within the distributed validator client, aggregated signing technology is used to aggregate the signatures of distributed validators, signing blocks once the threshold is reached.

4.5 Two paths to implement DVT technology

• An approach to DVT using SSS: This solution involves entities staking 32 ETH to create signing private keys (sk, pk) and withdrawal private keys, running a Secret Sharing Scheme program to securely distribute shares of the sk key among committee nodes.

• An approach to DVT using a DKG protocol: In the DKG scheme, no single entity distributes shares of the signing private key to validators; instead, a group of validator committee nodes runs the DKG protocol together. Thus, a secret key and public key (sk, pk), along with n shares of sk (sk1, …, skn), are created, with the i-th node (i=1,…n) holding share sk_i.

Figure 18: DKG Protocol 4.6 Threshold Signature Schemes (TSS) When validators need to sign blocks, the BLS threshold signature scheme is used. This allows N validators to jointly sign data, achieving a complete signature when t+1 (0