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<t<n) validators sign correctly. Through the TSS scheme, no single validator can obtain the complete signing private key, while ensuring the smooth generation of the complete signature.

5: DVT from the Perspective of Mainstream Projects

5.1 SSV On the surface, SSV provides a robust and decentralized pathway into the Ethereum staking ecosystem. Delving deeper, SSV is a complex multi-signature wallet equipped with a consensus layer, acting as a buffer between beacon chain nodes and validator clients. 5.1.1 Main components of the configuration

• Distributed Key Generation: Operators compute and generate a shared public-private key set by running the SSV program. Each operator only possesses a single part of the private key, ensuring that no single operator can influence or control the entire private key to make unilateral decisions.

• Shamir Secret Sharing: This mechanism is used to reconstruct the validator key using predefined KeyShares thresholds. A single KeyShare cannot be used to sign messages. SSV can leverage BLS technology to aggregate signatures, creating complete key signatures for validators. By combining Shamir and BLS, the validator's signing private key is sliced and shared, and reassembled when a signature is needed.

• Multi-Party Computation: Secure multi-party computation (MPC) is applied to secret sharing, allowing SSV's KeyShares to be securely distributed among operators and enabling decentralized computation of validator responsibilities without reconstructing the validator key on a single device.

• Istanbul Byzantine Fault Tolerance Consensus: Tying everything together is SSV's consensus layer, based on the Istanbul Byzantine Fault Tolerance (IBFT) algorithm. This algorithm randomly selects a validator node (KeyShare) responsible for block proposals and sharing information with other participants. Once the predetermined KeyShares threshold considers the block valid, it is added to the chain. Therefore, even if some operators (reaching the threshold) have issues or are currently offline, consensus can still be achieved.

Figure 19: SSV V2 network topology 5.1.2 Three types of participants in the SSV ecosystem

• Stakers: Exchanges, service providers, or individual ETH holders utilizing SSV/DVT technology to achieve optimal effectiveness, security, and decentralization of their validators. Stakers pay operators fees in SSV tokens to manage their validators.

• Operators: Operators provide hardware infrastructure, run the SSV protocol, and are responsible for maintaining the overall health of validators and the ssv.network. Operators determine their service fees in SSV tokens and charge validators for operating and maintaining their validators.

• DAO (SSV token holders): The ssv.network DAO decentralizes the ownership and governance of the ssv.network protocol and funds. SSV is the native token of the network. Anyone holding SSV tokens can participate in the DAO and vote on proposals and other items requiring votes. The number of SSV tokens held determines the voting power on decisions affecting the network.

5.1.3 Responsibilities of the ssv.network DAO:

• Operator scoring: The ssv.network relies on operators and their quality, experience, and services to provide a decentralized and transparent scoring system from 0-100%. The DAO is also responsible for auditing "Verified Operators" (VOs) and maintaining a list of VOs. Stakers can view and use these rankings to select operators to manage their validators.

• Network fees: To use ssv.network, stakers must pay network fees. The network fee is a fixed fee charged for each validator, added to the operators' fees. Network fees flow directly into the DAO treasury, which can be used to fund further development of the SSV ecosystem and activities through DAO voting procedures.

• Treasury: The network fees paid by stakers fund the DAO treasury, which is used for developing projects within the SSV protocol and ecosystem. This may include grants for protocol development and network growth, sharing revenue directly with SSV token holders, marketing and community incentives, token swaps for treasury diversification, and investments from strategic partners in exchange for SSV tokens.

• Voting: Submissions for funding requests and other proposals requiring votes to the DAO. Anyone holding SSV tokens can vote on decisions affecting the DAO, such as funding requests, requests to become validator operators, and other ideas or requests submitted for DAO consideration.

5.2 Obol Obol is a protocol that facilitates trust-minimized staking through multi-operator mechanisms, serving as a core module for various web3 products to obtain Ethereum staking rewards at low trust costs. 5.2.1 Four core public goods of Obol:

• Distributed Validator Launchpad: CLI tools and dApps to guide distributed validators.

• Charon: Charon is the distributed validator client of the Obol Network and is the first step towards enabling trust-minimized validation. Charon supports fault-tolerant, highly available validation, allowing a group of people to run validators across multiple machines rather than on a single machine.

Figure 20: Internal architecture of Charon

• Obol Managers: A set of reliable smart contracts for forming distributed validators.

• Obol Testnets: A set of ongoing public incentivized testnets allowing operators of any scale to test their deployments before serving the Obol mainnet.

5.2.2 Key Concepts:

• Distributed Validator: A distributed validator is an Ethereum proof-of-stake validator running on multiple nodes/machines. This is made possible using Distributed Validator Technology (DVT). DVT avoids the single point of failure issue; if less than 33% of participating nodes in the DVT cluster go offline, the remaining active nodes can still reach consensus on signing and generate valid signatures for staking validators. This is a proactive redundancy approach, a common pattern used to minimize downtime in critical systems.

• Distributed Validator Node: A distributed validator node is a set of clients that operators need to configure and run to fulfill their responsibilities as distributed validator operators. Operators can run redundant execution and consensus clients on the same hardware, running execution layer relays (like mev-boost) and other detection services to ensure optimal performance. In the above example, the client stack includes Geth, Lighthouse, Charon, and Teku.

Figure 21: Example of Obol's clients

• Execution Client: The execution layer client (formerly known as Eth1 client) is specifically responsible for running the EVM and managing the transaction pool of the Ethereum network.

  Execution layer clients include: Go-Ethereum, Nethermind, Erigon.

• Consensus Client: The consensus client's responsibility is to run Ethereum's proof-of-stake consensus layer, commonly referred to as the beacon chain. Consensus layer clients include: Prysm, Teku, Lighthouse, Nimbus, Lodestra.

• Distributed Validator Client:

  The distributed validator client intercepts the information flow between the validator client and the consensus layer client through a standardized REST API, focusing on two core responsibilities:

1. Achieving consensus on all candidates signed by validators.

2. Combining all validators' signatures into a distributed validator signature.

• Validator Client: The validator client is a piece of code that runs one or more Ethereum validators.

• Validator clients include: Vouch, Prysm, Teku, Lighthouse.

• Distributed Validator Cluster: A distributed validator cluster is a collection of interconnected distributed validator nodes.

Figure 22: Obol's DVT network topology

• Distributed Validator Key: The Distributed Validator Key is a set of BLS private keys that collectively serve as a threshold key participating in proof-of-stake consensus.

• Distributed Validator Key Share: A share of the distributed validator private key.

• Distributed Validator Key Generation Ceremony: To achieve fault tolerance in distributed validators, various private key shares need to be generated together. Instead of having a trusted dealer generate the private key, split it, and distribute it, each operator in the distributed validator cluster participates in a so-called distributed key generation ceremony. The benefit of this approach is that a complete private key is never constructed at any time. The distributed validator key generation ceremony is a type of DKG ceremony. The ceremony generates the signing validators' storage and exit data, as well as all validator key shares and their associated metadata.

6: Conclusion and Outlook

6.1 Conclusion Throughout this article, we started with The Merge, discussing the Casper FFG algorithm adopted by Ethereum after the merge, familiarizing ourselves with the new block production methods and some new technical concepts. We then covered Ethereum's new mining methods and the existing staking solutions, understanding the single point of failure issues faced by validators. We then delved into DVT technology and briefly described how DVT addresses this issue through two project cases. The entire article narrates from the perspective of decentralization, providing readers with a reference for understanding Ethereum's consensus algorithm and decentralized development direction. 6.2 Outlook After The Merge, Ethereum will gradually implement Danksharding, first by reducing calldata gas costs through EIP-4488 from 16 gwei to 3 gwei, providing strong support for the acceleration and scalability of rollups. The next step will be to introduce Blob transaction types in Proto-danksharding, allowing Ethereum to provide more storage space for rollups and reduce D/A costs, gradually achieving Danksharding.

To realize the concepts described in Danksharding, such as data availability sampling (DAS) and separation of block proposers/builders (PBS), it is essential to ensure that the number of nodes in the Ethereum network is sufficient and sufficiently decentralized, so that data availability sampling can be implemented. In other words, ensuring scalability and low-cost D/A is crucial, as the decentralization of Ethereum is the most important aspect, because decentralized staking solutions and technologies like DVT are vital for Ethereum's subsequent development.