Original title: "How Proof of Stake Ethereum Works" by Patrick McCorry

Original translation: 0x Felix

Proofreading of the original text: Franci, ECN

Ethereum has reached one of its long-awaited milestones - the merger! This is a very important moment. After seven years of hard work, the Ethereum community has successfully replaced the proof-of-work mechanism with the proof-of-stake consensus protocol. The immediate impact is to reduce the network's energy consumption by 99.95%, accounting for only 0.02% of global electricity consumption. This is a result worth celebrating!

In addition, there are many technical advantages brought by the upgrade, but most of the community is not clear. It’s time for more accessible material on how Proof-of-Stake works, why it’s important, and what exciting features are coming — especially now that Proof-of-Stake is protecting hundreds of billions of dollars in assets.

To support this effort, we have prepared a series of articles explaining the proof-of-stake protocol, aimed at researchers, developers, and end users interested in the technology. Over a two-week period, we will publish the following articles and update related links:

- Modular design and two blockchains,

- Epochs, Slots and Beacon blocks,

- validator witness and voting protocol,

- Compensation and punishment,

- Has Ethereum's Proof-of-Stake achieved its goals?

In addition, some of the following topics are covered:

- registration and withdrawal process,

- Delinquency penalties,

- the role of aggregators and subcommittees,

- swing attack (unpublished),

- Sync Board (unpublished).

We hope these articles help you understand how proof-of-stake protocols work, and serve as prerequisite knowledge before you dive into consensus client code during development.

Thanks to the Teku team, especially Ben Edington and Mikhail Kalinin for their patience in answering my questions.

Modular design and two blockchains

The block size war is ultimately a battle for decentralization - should it be as affordable as possible? Or should it be as verifiable as possible?

The quest for blockchain scalability has led the community to propose several ambitious proposals over the past 10 years. At the heart of the problem is a fundamental trade-off:

- Affordability: The size of the number of users who can afford to transact on the network.

- Verifiability: The number of users with hard requirements such as hardware and bandwidth to verify transaction integrity in real time.

Many modern blockchain systems prioritize affordability and maximum user numbers above everything else - assuming the network operator is willing to do their best to help make this happen. This assumption, that operators should work hard, tends to centralize blockchain systems because it reduces the number of people who can participate as operators. Especially for networks that require operators to purchase hardware from approved manufacturers.

It’s not that modern blockchain designs are wrong, but neither has so far garnered the same attention as Bitcoin or Ethereum. One of the reasons that stands out, in our opinion, is this fundamental trade-off. This is at the heart of the Bitcoin block size debate, with the community ultimately deciding to prioritize who can verify the integrity of the network over long-term affordability.

Hopefully, just like Ethereum, affordability can be pushed to another level with Lightning Network, Sidechains or Rollups. The Ethereum community, roadmap, and values ​​all stem from the same background. The only difference is that Ethereum has an ingrained social contract that enables its community to actually change the underlying platform to overcome this dilemma.

If there is one only takeaway that has nothing to do with Proof of Stake, it is that the TPS metric is meaningless in the context of a decentralized network. Scalability is not just about increasing throughput at any cost, but should be defined as the following:

"Increasing transaction throughput while still adhering to the same compute, bandwidth, and storage requirements required to run a fully validating node."

As a reader, this discussion may seem strange. Why are we talking about blockchain scalability? How does this relate to Proof of Stake? What's more, since the upgrade doesn't immediately increase transaction throughput in a meaningful way, this discussion seems even more off topic. The reason is that this upgrade has been underestimated in its ability to lay the groundwork for future scalability solutions.

Monolithic Blockchain to Modular Blockchain

A new mental model - consensus participants don't need to do all the hard work, they just verify and agree that the work is correct.

Let’s fast forward a few years, to after the block size wars. Now, we have better terms for how this dilemma affects the design of blockchain systems, namely monolithic blockchains or modular designs.

Single-type blockchain. This is a blockchain protocol and implementation mechanism that tries to find a general solution to all hardware bottlenecks, such as how to execute transactions, how to broadcast data, and how to store databases. Participating network operators must do all the heavy lifting and run the entire monolithic implementation, which greatly limits who can participate in the consensus protocol.

Modular design redefines resources into layers—enabling teams to build software to solve problems at each layer.

Resources form layers. One of the big forces behind Ethereum's proof-of-stake design and its long-term roadmap is the definition of each resource as a new tier. By being a layer, problems can be separated and independent, allowing teams to build new software clients to solve each specific problem. This is known as modular blockchain design.

Perhaps the most important understanding about the modular approach is how it changes the perceptions of consensus participants. It's no longer about putting them on top of the workload. Instead, it focuses on:

“What is the minimum amount of work a block proposer needs to do? Is it possible to take all the unnecessarily hard work elsewhere?”

the answer is yes

Validators act as light clients. Blockchain protocols are no longer designed around maximizing the network operator's job. In fact, the opposite is true, network operators (validators) should be light clients, only needing to check and verify work that has been done elsewhere.

That's why I personally like the name "validator". Their sole job is to verify, reach consensus (consensus), and ultimately secure all user assets stored in the Ethereum database. In the long run, participating should only require commercially available hardware and a good internet connection.

Furthermore, by making validators lightweight clients, it may finally address the altruistic nature of running node software. Users can finally get paid for validating the blockchain and checking its integrity in real time. Also, we can check if they are doing the work.

two blockchains

The merger is the first milestone in moving the Ethereum specification towards a modular design.

It separates the global consensus of transaction ordering from the eventual execution of transactions. At the same time, it introduces two new blockchains:

1) Implement the blockchain. The original Ethereum blockchain that handles user-generated transactions and smart contract execution. Sometimes referred to as the ETH 1 blockchain.

2) Consensus blockchain. A blockchain dedicated to the consensus layer. It is responsible for deciding on the canonical chain that executes the blockchain, and records the transcription of proof-of-stake. Sometimes called a beacon blockchain.

Two software clients. The proof-of-work PoW module, and generally any code that deals with decisions on the canonical chain, can be removed from the original Ethereum node software. The entire execution environment remains intact and is now called the execution client. To retrieve the canonical execution chain, it polls the software client that handles the consensus layer ("the consensus client") for new blocks.

Since the implementing blockchain and clients remain largely unchanged, our article will focus on implementing the consensus layer of a proof-of-stake protocol.

Multi-client ecosystem. As a result of the separation described above, several teams emerged that independently attempted to solve consensus or execution issues. Of course, in both cases they must follow the general specification, but are free to experiment with implementation details. There is currently a thriving (and surprisingly well-funded) multi-client ecosystem. For example, consensus clients include Teku and Prysm, while execution clients include Geth, Erigon, and Nethermind.

Validators are encouraged to run different combinations of consensus and execution clients. This is the first line of defense against consensus-level bugs, in the hope that the same bugs are not replicated across multiple independent implementations. This software engineering practice is called "N-version" programming.

write at the end

write at the end

Careful readers may have noticed the use of data availability, execution, and settlement layers here, but proof-of-stake Ethereum lays the foundation for the consensus and execution layers.

The long-term roadmap is towards:

Consensus → Data Availability. All validators reach a consensus on the ordering of data, and proto-danksharding helps solidify this role.

Rollups → Execution layer. Rollups assume the role of the execution layer,

ETH 1 → settlement layer. The original Ethereum blockchain is the foundation of trust that secures all user-defined assets.

This nomenclature can be confusing, depending on future iterations of the Ethereum protocol. We now simply call it the consensus and enforcement layer - as it has been implemented and deployed.