Breaking the Deadlock and Rebirth: The Legendary Journey After Ethereum's Merge

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

Written by: Frank Fan, 0xCryptolee, Arcane Labs

"As long as you dare to make a commitment, the world will help you remove insurmountable obstacles. Go fulfill your unfinished dreams, the universe will never suppress your progress, this is the essence." ------ Final block message of Ethereum's PoW era

Ethereum has undergone a historic upgrade, entering a new phase of development. After The Merge, Ethereum will continue to move towards 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 risk of 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, merging the Execution Layer and Consensus Layer on September 15, 2022. The biggest change is the switch from Ethereum's PoW consensus to PoS consensus.

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%.

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, reducing Ethereum's inflation rate. When the base fee exceeds 15 gwei, Ethereum even enters deflation.

• Staking rewards: Gas fees and MEV income are distributed to validators, with validator staking returns reaching 5-7%.

• Withdraw: After the merge, staked ETH cannot be immediately withdrawn; restrictions on withdrawals will be lifted after the Shanghai upgrade. Additionally, users cannot directly withdraw; to avoid large-scale withdrawals, there are certain limits on the amount and timing of single withdrawals. Therefore, after the withdrawal is opened, there will not be a large amount of withdrawal and 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 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.

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

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 no longer requires specialized mining machines to calculate difficulty values, but instead uses a random method to produce blocks. Let's continue exploring Ethereum's consensus algorithm and block production methods!

2. Gasper

Currently, 13,830,378 ETH is staked on the beacon chain, with 432,203 active validators (as of September 23, 2022). According to the characteristics of PBFT, the number of validators on the beacon chain is large, resulting in 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 the network structure, using the Gasper algorithm.

Gasper serves as the finality gadget in the beacon chain protocol, used to determine which blocks should be considered finalized and immutable by participants, and to determine which fork chain is the main chain during forks. The finality of Gasper generalizes the concepts in the paper "Casper Friendly Finality Gadget (Casper FFG)."

2.1 Concepts

• Slot: After the merge, a Slot corresponds to a block, with a committee responsible for generating that Slot within 12 seconds.
• Epoch: Every 32 Slots form an Epoch, with a duration of 384 seconds, or 6.4 minutes.
  Committee (validator committee): Each validator committee is allocated a minimum of 128 Validators, who will perform Attestation operations for their respective Slots, and one Validator in the committee will be randomly selected as the Proposer to produce blocks.
• Attestation: Validators in the committee corresponding to each Slot must vote and sign for the previous Epoch to ensure they acknowledge the transactions in the previous Epoch.
• Validator: After Ethereum's The Merge, the consensus algorithm switched to PoS, replacing the original miners with Validators. Validators become Validators by staking 32 ETH assets, responsible for producing blocks and signing within each Epoch's slots.
• Proposer: The Proposer is selected from the Validators in the committee using a random number generated by RANDAO, and is responsible for packaging the Slot block.
• Beacon chain: A PoS blockchain that replaces PoW consensus, with beacon chain nodes used to mount Data Blobs transaction types, providing more storage space for Rollup.

2.2 Process

At the beginning of an Epoch, RANDAO assigns a Committee to each Slot to perform Attestation for the previous Epoch.

Multiple Aggregators are assigned to the current Epoch's 32 Slots, aggregating the committee's Attestation for the previous Epoch and recording it in the Slot block.

RANDAO determines the Proposer responsible for producing blocks by generating random numbers.

In the current Epoch, during block production for each Slot, the committee performs Attestation for the checkpoint of the previous Epoch. After two consecutive checkpoints are attested, the previous checkpoint is finalized. This continues until all 32 Slots have attested to the checkpoint, marking the end of the current Epoch. When the first Slot of the Post-Epoch begins, the Pre-Epoch reaches a consensus of finality, meaning the Post-Epoch has gone through the Pre-Epoch and the current Epoch, totaling two rounds of Epochs (because if there are conflicting checkpoints outside the two Attestations, at least 1/3 of the validators must have acted maliciously, for example, if blocks at heights 32, 64, and 96 are involved, and the 64 height checkpoint is not reached until the 96 height, then the 32 height is finalized), taking 12.8 minutes, and transactions are confirmed on the chain, 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 number generated by 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 will choose 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 an increase in the number of validators benefits data availability sampling (DAS) and decentralization, it also means that there will be more validators for each Slot, increasing the communication burden between Aggregators and validators when collecting signatures. Additionally, the cost of validating aggregated signatures will also increase, which in turn increases the burden on validator nodes.

Long-range attacks: A long-range attack refers to a situation where a validator, after withdrawing staked ETH on the beacon chain, can use an old private key to maliciously fork a block they previously signed, as they no longer have any staked assets on the chain. They can then quickly produce 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 the checkpoint of the Pre-Epoch, with the idea of continuously pushing the initial state forward to avoid potential attacks.

3. Ethereum Staking Mining

3.1 Staking

Staking threshold: Validators need to 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 involves individuals who want to invest 32 ETH to become validators running their own validator nodes on cloud servers. Besides choosing to run nodes on cloud servers, they can also opt to set up server equipment at home to run Ethereum nodes. The difference is that running nodes on cloud services is more stable, helping to avoid and reduce penalties for downtime due to power outages and network issues, while the advantage of setting up nodes at home is that the hardware and network service costs are lower than those of cloud servers. Here, stakers can choose which hosting solution to adopt.
• Staking Pool: Since 32 ETH is a significant amount for ordinary individuals, small-scale stakers who want to participate in network consensus may not be able to run their own nodes. This has led to the emergence of staking pool solutions, with Lido being the main project in the semi-decentralized staking solution space, attracting substantial capital and becoming a leading solution in the field. Other more decentralized solutions include Rocket Pool and Swell. Additionally, aggregation solutions like Unamano have emerged to help and develop the Ethereum staking space.

In terms of node operation, Lido chooses to designate a portion of professional operators to run network nodes, which is a point of relative centralization. Operators hold the signing private keys, and users' assets partially rely on Lido and the operators. As for the 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 regarding nodes, allowing anyone to operate a node by providing 16 ETH and the necessary hardware and software. Although this lowers the barrier 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 receiving 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 respective advantages and disadvantages in terms of decentralization and security, depending on the trust of the stakers. However, it is undeniable that all three solutions have captured corresponding capital 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.

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 that aim 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. Moreover, the newly generated ETH will also concentrate in the hands of those who already hold more ETH, as they possess a large amount of ETH when staking. This undoubtedly presents a new challenge to Ethereum's decentralization, and 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 one of the sources of income for Validators. (High probability, low reward)

Block production rewards: Each Slot will have a Validator as the proposer to package blocks. The Validator selected as the proposer can receive block production rewards. (Low probability, high reward)

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

3.1.4 Types of Penalties

Inactivity penalties: Failure to produce blocks as expected in consensus: Not attesting to blocks within the expected time.

Malicious behavior leading to slashing: Producing two blocks or performing two attestations within a single Slot; 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 validators to sign messages while 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 to withdraw staked assets and block production 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 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 "punished" (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)

At the staking level, while we have decentralized staking solutions to lower the staking threshold and enhance the decentralization of staking services, there still exists a single point risk at the Validator level. Currently, a single validator runs multiple clients of the network, and if there are network issues or physical factors like power outages, it can lead to inactivity penalties, and the slot cannot collect valid signatures. We cannot run the same validator node redundantly in multiple locations, 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 point failures. During the implementation of upgrades, it also provides room for node upgrades, preventing large-scale node downtime due to network upgrades. For a detailed analysis, let’s explore further!

4.1 Concepts

Operator: An individual or entity that runs one (or more) nodes.

Operator node: Refers to hardware and software that perform the tasks of Ethereum validators. These tasks can be completed by a node alone or in conjunction with other nodes using DVT tools.

Distributed Validator Technology: Distributed Validator Technology is a technique that distributes the work of a single Ethereum validator to 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.

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 smaller keys are aggregated to produce a complete key signature.

Node Downtime

Crash Faults:

• Causes: Crashes caused by power outages, network disconnections, hardware failures, or software errors.
• Preventive measures: Implementing a redundant backup scheme by running the same node in multiple locations to prevent node downtime.

Byzantine Faults:

• Causes: Caused by software bugs or network attacks.
• Preventive measures: Multiple participating nodes reach a consensus, preventing a single node from making a decision.

4.4 Overall Architecture

• Distributed validators use private key sharding to remotely sign messages.
• Within the distributed validator client, aggregated signature technology is used to aggregate the signatures of distributed validators, and once the threshold is reached, the block is signed.

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 for 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 the share sk_i.

4.6 Threshold Signature Schemes (TSS)

When validators need to sign blocks, the BLS threshold signature scheme is used to achieve the signature. This allows N validators to jointly sign data, achieving a complete signature with t+1 (0) validators signing correctly. Through the TSS scheme, it ensures that no single validator can obtain the complete signing private key while guaranteeing 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. Digging 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 Configuration

• Distributed Key Generation: Operators calculate 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 utilize BLS technology to aggregate signatures, creating a complete key signature for the validator. By combining Shamir and BLS, the validator's signing private key is sliced and shared, and aggregated 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 reached.

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 for 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 matters 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 provides a 0-100% decentralized and transparent scoring based on their quality, experience, and services offered. 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 need to pay network fees. Network fees are fixed fees 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 processes.

Treasury: The network fees paid by stakers fund the DAO treasury, which is used for developing projects related to 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: Submitting funding requests and other proposals requiring voting 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, which can serve as a core module for various web3 products to obtain Ethereum staking rewards at low trust costs.

5.2.1 Four Core Public Products of Obol:

Distributed Validator Launchpad: CLI tools and dApps guiding distributed validators.

Charon: Charon is the distributed validator client of the Obol Network and the first step towards enabling trust-minimized validation. Charon supports fault tolerance and high availability validation, allowing a group of people to run validators across multiple machines instead of on a single machine.

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 a DVT cluster go offline, the remaining active nodes can still reach consensus on signing and generate valid signatures for the staking validators. This is a proactive redundancy approach, a common pattern 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.

• 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 responsibility of the consensus client 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. Reaching consensus on all candidate responsibilities 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 connected distributed validator nodes.

• Distributed Validator Key: The Distributed Validator Key is a set of BLS private keys that collectively serve as the threshold key for 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, the 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 signatures for validators, storage, and exit data, as well as all validator key shares and their associated metadata.

6. Summary and Outlook

6.1 Summary

Throughout the article, starting from The Merge, it discusses the Casper FFG algorithm adopted by Ethereum after the merge, familiarizing readers with the new block production methods and some new technical concepts. It then addresses Ethereum's new mining methods and the existing staking solutions, highlighting the single point failure issue among validators. The article delves into DVT technology and briefly illustrates how DVT addresses this issue through case studies of two projects. The entire article is narrated with a focus on 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, starting with EIP-4488 to reduce the gas costs of calldata from 16 gwei to 3 gwei, providing strong support for accelerating the 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 decentralized staking solutions and technologies like DVT are vital for Ethereum's future development.

Special thanks to former Huobi Research Institute Chief Researcher Li Lianxuan, Arbitrum integration engineer Jason Wan, Lido community member Jerry, Unipass researcher cyberorange, Dr. Zhou Qi from Web3Q, and Li Bai from Pomegranate Pool for their suggestions and reviews of this article.

References

1. https://www.ethereum.cn/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat
2. https://www.youtube.com/watch?v=awBX1SrXOhk
3. https://github.com/ObolNetwork/
4. https://www.ethereum.cn/Eth2/distributed-validator-specs
5. https://medium.com/nethermind-eth/sorting-out-distributed-validator-technology-a6f8ca1bbce3
6. https://docs.ssv.network/learn/introduction
7. https://medium.com/nethermind-eth/a-tour-of-verifiable-secret-sharing-schemes-and-distributed-key-generation-protocols-3c814e0d47e1
8. https://ecn.mirror.xyz/kFzA6fZKF-qIjAOvOkJT03WizNea0Bo2Gx6tUDamFsY
9. https://consensys.net/blog/ethereum-2-0/an-update-on-the-merge-after-the-amphora-interop-event-in-greece/
10. https://twitter.com/VitalikButerin/status/1570299062800510976?s=19
11. https://ultrasound.money/
12. https://rocketpool.net/
13. https://www.ethereum.cn/
14. https://beaconcha.in/
15. https://ethos.dev/beacon-chain/
16. https://medium.com/nethermind-eth/sorting-out-distributed-validator-technology-a6f8ca1bbce3
17. https://obol.tech/
18. https://ssv.network/