Proof of Stake (PoS) is coming to Ethereum, perhaps by the end of the year, definitely by early 2022. This upgrade will fundamentally change how the Ethereum blockchain comes to consensus every 12 seconds.
99.95% more energy efficient: Carl Beekhuizen at the Ethereum Foundation estimates Proof of Stake will no longer require a country’s worth of power to secure the network.
More validators, more decentralization: Proof of Stake reduces the technical barriers for anyone to stake and help secure the network.
Improved security guarantees: The ability to compromise the network will be magnitudes more expensive with Proof of Stake, not to mention that a 51% attacker is identifiable with validator addresses, and can be forked away from the network in the event of an attack.
One Ethereum, Two Types of Clients
Proof of Stake has been part of Ethereum’s roadmap for years, more recently, a phase in the catch-all set of upgrades called Ethereum 2.0. You may have noticed that many of the client implementers, research leads, and developers are now eschewing the Eth2 terminology to avoid confusion. Importantly, Ethereum 1 will not be deprecated when Proof of Stake arrives. As Danny Ryan wrote in January, the terms Eth1 and Eth2, “actually represent different layers of the stack.” When Proof of Stake comes to Ethereum, it will still be Ethereum. And no, after Proof of Stake arrives, nothing will happen to the ETH you already hold.
The other important thing to remember is that all of the applications and protocols that rely on Ethereum today will also not be affected by the consensus upgrade to Proof of Stake. Today, Ethereum clients like Go-Ethereum (Geth), Hyperledger Besu, and OpenEthereum provide transaction data, which gets sent to a mempool and added to blocks by miners using a Proof of Work algorithm. These clients will still power the applications built on the Ethereum protocol. You’re also probably aware that there are a number of “Eth2” clients that have been running the Proof of Stake Beacon Chain, which has almost 5 million ETH staked. How will these two types of clients fit together when Ethereum turns on Proof of Stake after the merge?
After the merge to Proof of Stake, Ethereum will have execution clients and consensus clients, which may be combined in the future.
Execution clients (Eth1 clients). Responsible for transaction bundling, execution, and state management. This layer is already represented by clients that Ethereum uses daily, such as Geth, OpenEthereum, Hyperledger Besu, and Nethermind.
Consensus clients (Eth2 clients). Responsible for the validating blocks, also known as the Beacon Chain. This consensus-layer has been running smoothly for more than 6 months, with 155,663 validators collectively staking 4,981,046 ETH. Client teams include Teku, Lighthouse, Nimbus, and Prysm.
You can read more about the terminology, but the point is that transactions and applications will still continue as normal on Ethereum, maintained by the same software clients we use today. However, instead of Proof of Work mining, this execution data will be confirmed by the Proof of Stake consensus layer.
Rayonism: A Merged Proof of Stake Ethereum Testnet
Researchers at the Ethereum Foundation and Consensys, client teams like Teku and Besu, and many other developers have been coordinating for the past six months on how and when this “merge” to turn on Proof of Stake, and also what this composite client design will look like.
The ETH Global Scaling Ethereum Hackathon concluded recently, and of particular relevance was the Rayonism project which focused on building a testnet to simulate the merge to Proof of Stake. They also sought to answer key questions: can you successfully get consensus clients to interact seamlessly with execution clients? How will smart contracts work in this new environment? Over the course of four weeks, two simulation “testnets” successfully emerged: Steklo, which ran for a day, and Nocturne, which ran for a week.
I spoke with Mikhail Kalinin, who is a Consensys researcher working on the merge, and Senior Product Manager, Sajida Zouarhi, for Hyperledger Besu at Consensys, to understand more about the upcoming merge, and what this means for client teams.
James Beck (JB): The Rayonism team had an ambitious goal to both create a Proof of Stake testnet with execution and consensus clients, as well as attempt sharding functionality. How would you assess the progress?
Mikhail Kalinin (MK): As we started we aimed to understand sharding functionality and the merge. But after we started, it quickly became more merge-centric. It was great! We planned to go deeper into the merge research to not only understand interaction between consensus and execution clients, but also understand the transition process. It ended up involving 7 client teams, which signifies that they understand how important the merge is.
Sajida Zouarhi (SZ): The first results came early, and were very encouraging. What it demonstrated was that the community was able to rally around an accelerated timeline for the merge. We didn’t expect this level of participation from all the client teams, which in itself is a great result. Every client team was able to participate with a prototype and we were able to test all the combinations across the execution and consensus clients. This is what happens when developers are able to prioritize one common shared goal: we get results.
Various combinations between consensus and execution clients.
JB: What was the result of the first testnet? Why did it only last for a day?
MK: The purpose of this first testnet was to test our scripts, coordination, finality and the various issues in coming to consensus between clients. Not everyone was experienced in participating in the launch of a testnet. It was not meant to last for more than one day. It was a way of making sure we were ready to launch a longer-lived testnet. The result was that we did it, but it didn’t reach finality because of a few client issues.
SZ: There are phases for testing; you start with a shorter-lived devnet [a term for a participant-only testnet], and then move on to a longer devnet with more parameters and testing scenarios.
JB: Can you tell me more about the Nocturne testnet? Is it still running?
MK: It’s not still running. It lasted for a week. For this testnet, we had a block explorer, which was helpful to see transactions in the Beacon chain blocks. It was also useful for debugging. We were able to reach finality during the first possible epoch. By achieving finality it proved that the execution clients and consensus clients were in consensus with each other. We didn’t find any bugs in the communication protocol design. However we did find an issue with the Eth1 data voting.
JB: What is Eth1 data voting?
MK: This is the process of bringing new validators onchain by voting on Ethereum mainnet data coming from beacon block proposers, to further allow for deposit processing.
JB: What is next for the Rayonism project and the merge?
MK: Rayonism is finished, but we are continuing our work on the merge. Perhaps you could call it post-Rayonism? While the clients are working on their respective upcoming hard forks, researchers are working on the transition process.
JB: What’s the transition process? Does this describe the exact moment when Proof of Work turns off and Proof of Stake begins?
MK: Yes. Literally the transition process is the method by which we agree on the last Proof of Work block, add the first Proof of Stake block, and finalize this first Proof of Stake block. Once finalization is reached, we can say the merge happened. From that point on, Ethereum will come to consensus with Proof of Stake.
We are also working on standardizing the consensus API, which is the API exposed by the execution client to be driven by and communicated with the consensus client. I also know the Go-Ethereum team is working on the state-sync design. State sync will have a different bootstrapping process after the merge, so it needs to be adjusted to be compliant with the merge. Once London and Altair hard forks happen, we will be able to come together to launch a bigger merge testnet.
JB: Sajida, what are execution client teams like Hyperledger Besu doing to prepare for the merge?
SZ: We are participating in the devnets with other execution layer clients and consensus layer clients to identify the issues ahead of time, and fix them. My goal is that we increase the performance of Hyperledger Besu so that it is an execution engine of choice for any validator looking for an option. For now the results are encouraging in how Besu works with all the consensus clients.
The team that works on Teku is also the team that originally built Besu, so the combination between these works really well.
JB: Sajida, I’m sure there is a lot of focus on the upcoming London Hard Fork with EIP 1559 in July. Will there be an EIP related to the merge in this hard fork?
SZ: Actually, the client implementations have been frozen for the London Hard Fork, so we are actually ready for testnet deployment. Mainnet deployment will be sometime in July.
Another thing to note, is that ahead of the merge, we’ve already implemented a change that would delay the “difficulty bomb” called EIP 3554 to align with the new timeline of the merge, which would be December 2021.
JB: Sajida, what’s the feeling on the Besu team? What’s next for your work on the merge?
SZ: It’s a very optimistic feeling right now — both in terms of the devnets and the timeline. We are committed to turning off Proof of Work as soon as possible.
JB: Mikhail, Sajida, what are the risks that could happen with the merge?
MK: One risk is to break a non-obvious invariant which would affect existing applications. Of course, there is a risk of various attacks as we approach the merge and the risk of 51% attack is the most severe in terms of mitigation. We will have a thorough quality assurance process before releasing the merge with multiple testnet rounds — including stress testnets and production-sized testnet in the end. This will be a good time for all applications and infrastructure to check whether they are ready to go and if everything works well for them. We are working on removing various attack vectors near the Merge, but 51% is still a concern.
SZ: One risk is trying to move too fast because of market pressure — especially with the new narratives around Proof of Work being so harmful to the planet in terms of energy expenditure. The people developing the software’s utmost priority is making sure the software is safe. We are following best practices, step-by-step to mitigate problems, and market pressure shouldn’t put more pressure on standard software development methods.
We are also paying close attention to Miner Extractable Value (MEV) and flashbots. There are a lot of open questions about how these auctions may take place when activity returns on-chain.
And finally, Consensys wants more smart people involved in core protocol development that could help with the merge to Proof of Stake. We are hiring engineers for both our execution client, Hyperledger Besu, and our consensus client, Teku.