Editor's Note: This afternoon, at the main venue of Devcon in Bangkok, Ethereum core developer Justin Drake announced Ethereum's most ambitious consensus layer upgrade proposal in the past few years—Beam Chain. This proposal introduces a series of ZK technologies to replace the "legacy" Ethereum Beacon Chain. During the event, Justin mentioned that the development of the new consensus layer may continue until 2030. However, the market seemed unimpressed as the price of Ethereum sharply dropped during the announcement. Everyone seems to be wondering: Does the Foundation now have another excuse to sell coins?

The following is the full transcript of the speech:

The project I have dedicated a significant amount of time to this year is called "Beam Chain." Beam Chain is a redesign proposal for the consensus layer that combines 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 secure and efficient manner, bringing Ethereum closer to its final form.

Image Source: Uncommons Da Song

Before I share more details, I have two disclaimers: First, this is a proposal and merely my suggestion, which will only be advanced with consensus. Second, there are no new tokens, no new network; we will continue to use the same ticker, as Vitalik has made very clear.

In the upcoming speech, I will attempt to explain what may seem like a crazy idea as a reasonable proposal—that is, a complete redesign of the consensus layer.

First, I would like to discuss the overarching vision of Beam Chain. The scope of Beam Chain focuses on the consensus layer, excluding the blobs in the data layer and the EVM in the execution layer. Blobs and EVM are directly used by applications and require forward compatibility, so the opportunities for change in these two layers are relatively limited. The consensus layer is not directly consumed by applications, allowing us greater flexibility in this regard.

Why Beam Chain?

So, why am I proposing this large-scale refactoring of the consensus layer now?

The main reason is that the Beacon Chain has become somewhat "archaic."

The "specs" were frozen five years ago, and a lot has changed in these five years, especially in our deeper understanding of new perspectives. Five years ago, we were relatively naive about PoW issues, but since then, the market has rapidly evolved, and we have gained a better understanding of mechanisms that can help mitigate MEV externalities.

Next, from an engineering perspective, we now have a very powerful technology called SNARKs. Over the past five years, SNARKs technology has made significant breakthroughs, with speed improvements of several orders of magnitude. At the same time, we have also seen the emergence of zkVMs, which is an amazing technology that allows any programmer worldwide to leverage this powerful technology without needing expertise in cryptography or a deep understanding of SNARKs.

Furthermore, over time, we now have a clear understanding of the mistakes made on the Beacon Chain and the accumulated technical debt. This debt is very stubborn and will increase over time.

Now, perhaps we have the opportunity to clear this technical debt. Therefore, I suggest integrating the most advanced technologies from the consensus layer roadmap into the Beam Chain.

What Changes Are Included in the Beam Chain?

Next, I will take some time to introduce the specific contents included in the consensus layer roadmap. There are basically nine different projects, which I will categorize into three categories: block production, staking, and cryptography.

Image Source: Aaros.183

First is block production, which involves MEV. Currently, there are significant centralization issues at the block producer and relay layer. We aim to introduce an "inclusion list" to significantly enhance censorship resistance. Once the inclusion list has censorship resistance, we can explicitly separate validators from the block production process. This is known as Proposer-Builder Separation (PBS) and includes some execution functions.

The final item in the block production category is faster slots. Perhaps we can further shorten the slots while keeping the current 12-second slot unchanged, ensuring that even users in Australia with high network latency through a home internet connection can still participate as validators and enjoy top-notch staking.

The second category is staking. Researchers have essentially reached a consensus that the current issuance curve has flaws and there is an opportunity to improve Ethereum's health and long-term development through adjustments. The second project in the staking category is to significantly reduce the amount of ETH required to become a validator from the current 32 ETH to just 1 ETH.

Recently, there have been some ideas about "Orbit." Additionally, there is a long-discussed idea of single slot finality, which can significantly accelerate Ethereum's finality process.

The final category is cryptography, which includes two key initiatives. The first initiative is to perform real-time SNARK verification on the entire consensus layer with reasonable hardware support.

Lastly, can we ensure that Ethereum's cryptography can sustainably evolve over the next few decades or even hundreds of years and withstand quantum attacks?

Here, I use different colors to differentiate whether projects on the roadmap can be easily or gradually accomplished, or if they are challenging to implement. The four green projects in the top left corner are ones I believe can and should be incrementally achieved on the Beacon Chain, and once these smaller projects are completed, what remains are some major projects (highlighted in red), which I think are best addressed through a more comprehensive approach.

Take "Statelessness" as an example. To achieve real-time proof of Beacon Chain on reasonable hardware, we need to change the hash function, signature scheme, as well as the way state serialization and Merkleization are handled. This would be a significant change to the Beacon Chain, so perhaps we have an opportunity to make other improvements while making these adjustments.

A similar situation applies to the bottom two red boxes, "Faster Slots" and "Faster Finality." Five years ago, when designing the Beacon Chain, our focus was on security, not performance. However, we now find that some designs can maintain the necessary security while also enhancing performance, seizing some low-hanging fruit in performance improvements.

This slide illustrates the mapping between the consensus layer roadmap I just mentioned and Vitalik's more extensive roadmap. Some of our projects fall under the Merge phase, some under the Scourge phase, and some under the Verge and Scourge phases.

The core purpose of this slide is to convey that Beam Chain is not about altering the entire roadmap but identifying a specific subset, accelerating its progress, and giving it a unique significance.

Image Source: Aaros.183

The "Faster Slots" in the consensus layer roadmap is new because discussions about faster slots began in 2024, whereas Vitalik's roadmap was last updated in 2023.

In addition to accelerating these critical initiatives, we can also address some of the previously mentioned technical debts. If we achieve single-source finality, we will no longer need epochs and can directly use slots. Moreover, the current deposit contract is somewhat convoluted, a legacy of the merger; and infrastructures like the synchronous committee will no longer be necessary after achieving real-time SNARKification of the Beacon Chain. This is an opportunity for a one-time cleanup.

If you are interested in some of the design issues in the Beacon Chain, last year I gave a comprehensive talk discussing the 20+ mistakes we made in designing the Beacon Chain.

This chart shows the overview of our upgrades to the consensus layer since the genesis. At the bottom left, you can see the genesis in 2020, and since then, we have had yearly forks, with each fork gradually improving the consensus layer.

In 2021, we added the Sync Committee, in 2022 we did the merge, in 2023 we added the withdrawal capability and native dynamic sharding, and in 2025, we will add the max effective balance.

We expect to continue these gradual forks over the next few years, targeting the low-hanging fruit marked as green in the roadmap in the top left corner.

Eventually, we will hit a bottleneck where once all the low-hanging fruit is done, all that remains are major projects that are hard to incrementally realize, and this is where a "Beam Fork" is needed. The Beam Fork provides an opportunity for a consensus-layer leap forward through a one-time upgrade. Think of the Beam Fork as a batch processing opportunity, where multiple upgrades are bundled into one fork, offering both technical advantages and governance benefits.

You can think of this batch processing opportunity as "Hardening Accelerationism." It sounds like a contradiction, but the basic idea is to expedite Ethereum's transition into maintenance mode, given the current tension. We know there are key projects that require a fundamental Ethereum overhaul, and the longer we delay these changes, the further Ethereum is from reaching a stable state.

What Technologies Does Beam Chain Use?

Next is part two, where I will introduce some of the technologies that will be used in the Beam Chain. You can think of this as different epochs of Ethereum consensus mechanisms: starting with the Proof of Work (POW) era, then transitioning to the Proof of Stake (POS) era, and now potentially entering a Zero-Knowledge Proof (ZK) era.

In the ZK era, we will heavily utilize SNARKs technology. One area where we are already using SNARKs is to provide zero-knowledge validation for the entire Beam Chain—the entire consensus layer—where zkVMs (Zero-Knowledge Virtual Machines) become very handy.

Imagine being able to implement Beam Chain in different high-level programming languages like Rust and Go, and then compiling these high-level languages into bytecode understandable by zkVMs to achieve SNARK verification, without worrying about low-level details.

One key point to emphasize is that the only part that requires SNARK verification is the State Transition Function, which is at the core of becoming a consensus client. Essentially, the State Transition Function is a very small part of the client construction, and peripheral infrastructure (such as networking, synchronization, cache optimization, or block selection rules) does not require SNARK verification.

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

It is worth noting that this powerful technology can also be used for execution layers, which is different from the Beam Chain story, but it is very exciting because it means we can significantly increase the gas limit, enhancing Ethereum's vertical scalability as L1. However, that is another topic.

Another significant use of SNARKs in Beam Chain is in aggregate signatures. We aim to have quantum-resistant aggregate signatures, and the proposal here is to use a hash function. Hash functions have quantum resistance and can serve as a fundamental building block for constructing cryptography.

We will use hash-based signatures generated by verifiers and provers, and we will also introduce hash-based SNARKs, which can compress thousands of signatures into one proof. By combining these two, we can build a hash-based, quantum-resistant, aggregatable solution that can be used in Ethereum. An interesting detail is that this aggregation scheme has the ability for infinite recursive aggregation, meaning that the aggregated result can be further aggregated, which is not achievable by current BLS signatures and offers more flexibility.

The reason I am presenting this proposal today is that in recent months, SNARK hash function performance has made significant strides. For those in the know, we can now verify on a laptop.

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

In addition to the zkVM and SNARKs we will be using, I also want to emphasize that we will largely reuse existing infrastructure.

For example, networking libraries like libp2p, serialization libraries like Simple Serialize, can be directly reused. The Pyspec framework is also the same, which is the Python specification framework we use to write formal specs and unit tests.

In addition, foundational infrastructures like the Protocol Guild can also be reused, which did not exist in the early days of the Beacon Chain but are now available for free reuse.

Likewise, there are now multiple teams supporting the development of the Beacon Chain, whereas back then we did not have teams for consensus clients. The five consensus client teams now in place can be directly deployed without the need for reassembly.

Furthermore, we have dedicated teams for merging operations, such as the Panda Ops team providing DevOps support, security teams, and incentive teams, among other application research groups, all of which are valuable resources that can be directly utilized.

Lastly, I would like to discuss the next steps and future prospects. One possible outcome is that starting from 2025, we will enter a standardization process. This will be conducted by a small group of researchers and may take up to a whole year. In 2026, the development process will kick off, with client teams starting to write production-level code, followed by a very thorough testing phase in 2027 to ensure security and stability for production deployment.

Image Source: Uncommons

As a researcher, my next task is to begin writing an executable specification, which I refer to as an "executable roadmap." Our idea is to combine the "pixels" in the roadmap, the extensive content of various research and academic papers, and the myriad ideas in researchers' minds, extract their essence, and form an executable specification document. Ultimately, this will be a very concise document, approximately 1000 lines of Python code.

What excites me is that if there is a general consensus on Beam Chain's new direction, this will be an excellent opportunity to inject fresh blood into the consensus client.

Currently, our consensus client teams are spread across North America, Europe, and Oceania. Today, I am pleased to announce that there are new teams willing to develop the Beam client. One team is located in India, called Zine, and they are using the Zig language to write a Beam client. Another team, Lambda Class, located in South America, has also shown interest in developing a Beam client.

If you are also interested in participating, we need a large number of excellent talents, including specification and network experts, coordinators, cryptography experts, and client developers. Please contact us via this email to join us and embark on this new adventure together. Thank you very much!

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia