Editor’s note: This afternoon, at the main venue of the Devcon event in Bangkok, Ethereum core developer Justin Drake announced Ethereum’s “most ambitious” consensus layer change proposal in the past few years - Beam Chain, which introduces a series of ZK technologies to replace The “old” Ethereum Beacon Chain. At the meeting, Justin said that the development of the new consensus layer may continue until 2030. However, the market did not seem to buy it, and while the press conference was going on, the price of Ethereum fell sharply. Everyone seems to be thinking: Does the foundation have another excuse to sell coins?

The following is the full text of the speech:

The project that I have invested a lot of time in this year is called “Beam Chain”. Beam Chain is a redesign of the consensus layer that incorporates the latest and most advanced ideas from the research roadmap. The goal is to transition from the current Beacon Chain to this design in a safe and fast way, which will be closer to Ethereum. final form.

Image source: Uncommons Dasong

Before I share more, two disclaimers: First, this is a proposal, mine only, and will only move forward with consensus. Second, there is no new token, no new network, we will continue to use the same ticker, Vitalik was very clear about this.

In the following talk, I will try to explain a seemingly crazy idea into a reasonable proposal - namely to completely redesign the consensus layer.

First of all, I would like to talk about the big framework vision of Beam Chain. The scope of Beam Chain focuses on the consensus layer and does not include blobs in the data layer and EVM in the execution layer, because blobs and EVM are used directly by applications and need to maintain forward compatibility, so the opportunities to change these two layers are relatively limited. The consensus layer is not directly consumed by applications, which allows us to have more room for adjustment in this regard.

Why Beam Chain?

So why am I proposing this massive refactoring of the consensus layer now?

The main reason is that Beacon Chain is already a bit “old”.

“Specifications” were frozen five years ago, and a lot has changed in those five years, especially that our understanding of new perspectives is much deeper than it was five years ago. We were relatively naive when it came to PoW five years ago, but since then the market has grown rapidly and we have a better understanding of the mechanisms that can help mitigate MEV negative externalities.

Second, from an engineering perspective, we now have a very powerful technology called SNARKs. Over the past five years, there have been numerous breakthroughs in SNARKs technology, increasing speeds by orders of magnitude. At the same time, we also saw the birth of zkVMs, an amazing technology that allows any programmer in the world to take advantage of this powerful technology without needing to be versed in cryptography or have a deep understanding of SNARKs.

Additionally, over time, we now have a clear understanding of the mistakes that were made on Beacon Chain and the technical debt that accumulated. These debts are very stubborn and will grow over time.

Now, maybe we have an opportunity to clean up this technical debt. Therefore, I recommend integrating the most advanced technologies from the consensus layer roadmap into Beam Chain.

What changes does Beam Chain include?

Next, I’ll take a moment to describe what exactly is included in the consensus layer roadmap. There are basically nine different projects, and I divided them into three categories: block production, staking, and cryptography.

Source: Aaros.183

The first is block production, which involves MEV. There are currently a lot of centralization issues at the block builder and relayer level. We hope to introduce an “inclusion list” to significantly improve censorship resistance. Once the inclusion list is censorship-resistant, we will be able to clearly separate validators from the block production process. This is called proposer-builder separation (PBS) and includes ideas such as execution functions.

The last item in the block production category is faster time slots, maybe we can further reduce the time slots while keeping the current 12 second time slots unchanged and ensure that even over a home network connection, even if the network latency is high In Australia, users can still participate as validators and enjoy first-class rights.

The second category is pledge. Researchers have largely reached consensus that the current issuance curve is flawed and that there are opportunities for adjustments to improve Ethereum’s health and long-term development. The second project in the staking category is to significantly reduce the ETH required to become a validator from the current 32 ETH to just 1 ETH.

There have been some ideas about “Orbit” recently. Additionally, another idea that has been discussed for years is single-slot finality, which could significantly speed up Ethereum’s finality process.

The last category is cryptography, which contains two important projects. The first project is SNARK verification of the entire consensus layer in real time, with reasonable hardware support.

Finally, can we make the cryptography that secures Ethereum sustainable and resistant to quantum attacks for decades or even centuries to come?

Here I use different colors to differentiate whether items in the roadmap can be completed easily or gradually, or if they are difficult to achieve. The four green projects in the upper left corner are projects that I think can and should be implemented gradually on Beacon Chain, and when these smaller projects are completed, what is left are some major projects (red parts) that I think are the best through a more holistic approach.

Taking “Change Notification” as an example, in order to achieve real-time proof of Beacon Chain on reasonable hardware, we need to change the hash function, signature method, and state serialization and Merkelization methods. This will be a big change to Beacon Chain, so maybe there’s an opportunity for us to make these adjustments alongside other improvements.

A similar situation applies to “Faster Slots” and “Faster Finality” in the two red boxes at the bottom. When we designed Beacon Chain five years ago, our focus was on security, not performance. Now, however, we are discovering that there are designs that can maintain the security we need while also improving performance and seizing some easy-to-achieve performance improvements.

This PPT shows the mapping from the consensus layer roadmap I just mentioned to Vitalik’s broader roadmap. Some of our projects are in the Merge phase, some are in the Scourge phase, and some are in the Verge and Scourge phases.

The core purpose of this PPT is to convey that Beam Chain is not changing the entire roadmap, but identifying a specific subset of it, accelerating it, and giving it a unique meaning.

Source: Aaros.183

The “faster time slots” in the consensus layer roadmap are new, as discussions about faster time slots began in 2024, and Vitalik’s roadmap was last updated in 2023.

In addition to being able to accelerate these important projects, we can also clean up some of the technical debt mentioned earlier. If we implement single-source finality, epochs are no longer needed and slots can be used directly. In addition, the current deposit contract is a bit complex and is a legacy from the merger; infrastructure like the synchronization committee will no longer be needed after real-time SNARKing of Beacon Chain is achieved. This is an opportunity to clean up in one fell swoop.

If you’re interested in some of the issues in Beacon Chain design, last year I gave a full talk discussing over 20 mistakes we made when designing Beacon Chain.

This picture shows the full picture of our upgrades to the consensus layer since its creation. As you can see in the lower left corner, genesis happened in 2020, and since then we have had a new fork every year, and with each fork we have made incremental improvements to the consensus layer.

In 2021 we added a sync committee, in 2022 we did a merge, in 2023 we added withdrawal capabilities and native dynamic sharding, and in 2025 we will increase the maximum effective balance.

Expect us to continue making these incremental forks over the next few years, grabbing the low-difficulty projects marked green in the upper left corner of the roadmap.

Gradually we will encounter a bottleneck. Once all low-difficulty projects are completed, the rest are major projects that are difficult to gradually implement. At this time, “Beam Fork” is needed. Beam Fork provides an opportunity to make a big leap forward in the consensus layer through a one-time upgrade. Think of the Beam Fork as a batching opportunity, where multiple upgrades are merged into a single fork, with both technical and governance benefits.

This opportunity for batch processing can be called “solidified accelerationism.” This sounds like an oxymoron, but the basic idea is to want Ethereum to enter maintenance mode as soon as possible, and there is such tension at the moment. We know that there are some important projects that require a fundamental restructuring of Ethereum, and the longer these changes are delayed, the further it will be before Ethereum reaches a stable state.

What technologies does Beam Chain use?

Next up is part two, where I introduce some of the techniques that will be used in Beam Chain. Think of this as different eras of Ethereum’s consensus mechanism: initially the Proof of Work (POW) era, then moving into the Proof of Stake (POS) era, and now we may be entering a Zero Knowledge Proof (ZK) era.

In the ZK era, we will make heavy use of SNARKs technology. One place where we are already using SNARKs is to provide zero-knowledge verification for the entire Beam Chain - the entire consensus layer - and this is where zkVMs (zero-knowledge virtual machines) become very useful.

Imagine that we could implement Beam Chain in different high-level programming languages, such as Rust and Go, and then compile these high-level languages ​​into bytecode that zkVMs can understand to achieve SNARK verification without worrying about the low-level details.

One point that needs to be emphasized is that the only part that requires SNARK verification is the State Transition Function, which is the core of becoming a consensus client. Essentially, the state transition function is a very small part of the client build, and surrounding infrastructure (such as networking, synchronization, cache optimization, or block selection rules) does not require SNARK verification.

RISC-V has become the industry standard for these zkVMs over the past few years. RISC-V is an instruction set that basically compiles high-level code into RISC-V instructions. There are now seven companies offering RISC-V zkVMs, such as RISC Zero and SP1, which you may have heard of.

It is important to note that this powerful technology can also be used in the execution layer, which is a different story from Beam Chain, but it is very exciting because it means that we can significantly increase the gas cap and enhance Ethereum as L1 Vertical scalability, but that’s another topic.

Another place where SNARKs are heavily used in Beam Chain is in aggregable signatures. We would like to have quantum-resistant aggregable signatures, and the proposal here is to use hash functions. Hash functions are quantum-resistant and can be used as a basic module for building cryptography.

We will use hash-based signatures, generated by verifiers and provers, and will also introduce hash-based SNARKs that can compress thousands of signatures into a single proof. By combining the two, we can build a quantum-resistant, aggregable hash-based solution that can be used on Ethereum. An interesting detail is that this aggregation scheme has the capability of infinite recursive aggregation, which means that the aggregation results can be continuously re-aggregated, which is currently not possible with BLS signatures and is more flexible.

The reason I’m proposing this today is that there have been huge improvements in SNARK hash function performance in recent months. For those in the know, we’ve now been able to verify this on a laptop.

This benchmark was completed on a MacBook Pro CPU and can now verify 2 million hashes per second. This is an amazing speed, which means that this hash-based proposal has great performance on Beam Chain. potential.

In addition to the zkVM and SNARKs we will be using, I also want to emphasize that we will be reusing existing infrastructure to a large extent.

For example, the network library libp2p, the serialization library Simple Serialize, etc. can be reused directly. The same goes for the Pyspec framework, the Python specification framework we use to write formal specifications and unit tests.

In addition, infrastructure such as Protocol Guild can also be reused. These did not exist in the early days of Beacon Chain, but can now be reused for free.

Similarly, there are now multiple teams supporting the development of Beacon Chain. At that time, we did not have a consensus client team. The current five consensus client teams can be put into use directly without the need to reorganize.

In addition, we have dedicated teams responsible for combined operations, such as DevOps support provided by the Panda Ops team, application research groups such as the security team and the motivation team, these are all resources that can be directly leveraged.

In the final part, I want to talk about next steps and future prospects. One possible outcome is that starting in 2025 we will enter a normalization process. This will be carried out by a small team of researchers and may take the entire year. In 2026, the development process will kick off with client teams writing production-grade code, followed by a very thorough testing process in 2027 to ensure security and stability of production deployments.

Image source: Uncommons Dasong

My next task as a researcher is to start writing an executable specification, which I call an “executable roadmap.” The idea is to combine the “pixels” in the roadmap, the hundreds of thousands of words in various research and academic papers, and the various ideas in the minds of researchers, extract their core essence, and form an executable specification document. Ultimately, this will be a very compact document, about 1000 lines of Python code.

The exciting thing for me is that if there is a general consensus on the new direction of Beam Chain, this will be a great opportunity to inject new blood into the consensus client.

Currently, our consensus client team is spread across North America, Europe, and Oceania. Today, I’m happy to announce that a new team has been willing to develop the Beam client. One of the teams is based in India, called Zine, and they are writing a Beam client using the Zig language. There is also a Lambda Class team based in South America that has also expressed interest in developing a Beam client.

If you are also interested in participating, we need a lot of talented people, including specifications and network experts, coordinators, cryptography experts and client developers. Please contact us via this email to join us and start this new adventure together. Thank you so much!

Disclaimer：

1. This article is reprinted from [BlockBeats ], All copyrights belong to the original author [BlockBeats ]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.