Can Ethereum's proposed new Beam Chain change the game for ETH?
Ethereum L1 is also transitioning to ZK, giving the foundation another excuse to sell off coins.
Editor's Note: This afternoon, at the main venue of Devcon in Bangkok, Ethereum core developer Justin Drake unveiled the most ambitious consensus layer upgrade proposal for Ethereum in recent years — Beam Chain. This proposal introduces a series of ZK technologies to replace the "outdated" Ethereum Beacon Chain. During the event, Justin mentioned that the development of the new consensus layer may continue until 2030. However, the market did not seem convinced, as the price of Ethereum plummeted rapidly 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:
This year, a project I have dedicated a significant amount of time to is called "Beam Chain." Beam Chain is a redesign proposal for the consensus layer, incorporating 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, which will bring Ethereum closer to its ultimate form.
Image Source: Uncommons Doso
Before I share more details, I have two disclaimers: first, this is a proposal, merely my suggestion, and will only proceed with consensus from the community. Second, there is no new token, no new network; we will continue to use the same ticker, as Vitalik has made very clear.
In the following speech, I will try to explain what may seem like a wild idea as a reasonable proposal — a complete redesign of the consensus layer.
First, I would like to discuss the overarching vision of Beam Chain. The scope of Beam Chain is focused on the consensus layer, excluding the blobs in the data layer and the EVM in the execution layer. Blobs and the EVM are directly consumed by applications and need to maintain forward compatibility, so the opportunity to change these two layers is relatively limited. The consensus layer, not directly consumed by applications, allows 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 is starting to show its age.
The "spec" was frozen five years ago, and in these five years, a lot has changed, especially 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 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 a remarkable technology that allows any programmer worldwide to leverage this powerful technology without the need to be proficient in cryptography or have a deep understanding of SNARKs.
Furthermore, as time has passed, we now have a clear understanding of the mistakes made on the Beacon Chain and the accumulated technical debt. This technical debt is very stubborn and will increase over time.
Now, perhaps we have the opportunity to clear this technical debt. Therefore, I propose to integrate the most advanced technologies from the consensus layer roadmap into the Beam Chain.
What Changes Does Beam Chain Include?
Next, I will take some time to introduce the specific contents included in the consensus layer roadmap. Basically, there are nine different projects, which I will categorize into three groups: Block Production, Staking, and Cryptography.
Image Source: Aaros
First is Block Production, which involves MEV. Currently, there are significant centralization issues at the block producer and proposer level. 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 referred to as Proposer-Builder Separation (PBS) and includes some execution functions ideas.
The final project 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 with a high network latency in Australia through a home network connection, users can still participate as validators and enjoy top-tier staking.
The second category is Staking. Researchers have essentially reached a consensus that the current issuance curve is flawed and there is an opportunity to make 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 only 1 ETH.
Recently, there have been some ideas about "Orbit." Additionally, there is a long-discussed idea of a single-slot finality, which can significantly speed up Ethereum's finality process.
The last category is cryptography, comprising two significant projects. The first project is real-time SNARK validation of the entire consensus layer, leveraging reasonable hardware support.
Lastly, can we ensure that Ethereum's cryptography remains sustainable for the next few decades or even hundreds of years and achieve resistance to 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, in my opinion, projects that can and should be gradually implemented on the Beacon Chain. Once these smaller projects are completed, the remaining are major projects (highlighted in red), which I believe are best addressed through a more comprehensive approach.
Take "Statelessness" as an example. To achieve real-time proof of the Beacon Chain on reasonable hardware, we need to change the hash function, signature scheme, as well as the way state serialization and hashing are done. This would be a significant change to the Beacon Chain, so perhaps we have the opportunity to incorporate other improvements while making these adjustments.
A similar situation applies to the bottom two red boxes, "Faster Slots" and "Faster Finality." When designing the Beacon Chain five years ago, our focus was on security rather than performance. However, now we find that some designs can both maintain the required security and improve performance, seizing some low-hanging performance improvements.
This slide shows the mapping relationship from the consensus layer roadmap I just mentioned to Vitalik's broader roadmap. Some of our projects belong to the Merge phase, some to the Scourge phase, and a portion to the Verge and Scourge phases.
The core purpose of this slide is to convey that the Beam Chain is not about changing the entire roadmap but identifying a specific subset, accelerating its progress, and giving it a unique significance.
Image Source: Aaros
The "Faster Slots" in the consensus layer roadmap is new because discussions about faster slots began in 2024, while Vitalik's roadmap was last updated in 2023.
In addition to speeding up these crucial projects, we can also address some of the previously mentioned technical debt. If we achieve single-source finality, epochs are no longer needed, and slots can be used directly. Furthermore, the current deposit contract is somewhat complex, a legacy of the merger; and infrastructure like the Sync Committee will no longer be needed 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 issues with the Beacon Chain design, last year I gave a comprehensive talk discussing over 20 mistakes we made while designing the Beacon Chain.
This diagram illustrates our upgrades to the consensus layer since our genesis. In the bottom left, you can see that the genesis happened in 2020, and since then, we have had annual forks, with each fork progressively improving the consensus layer.
In 2021, we added the Sync Committee, in 2022 we did the Merge, in 2023 we added the Withdrawal Functionality and native dynamic sharding, and in 2025, we will be adding the Maximal Effective Balance.
It is expected that in the coming years, we will continue with these incremental forks, following the roadmap of low-hanging fruit marked in green in the top left corner.
Eventually, we will hit a bottleneck where all low-hanging fruit projects are completed, and what remains are significant projects that are hard to achieve incrementally, signaling the need for a "Beam Fork." The Beam Fork provides an opportunity for a consensus layer leap forward through a one-time upgrade. The Beam Fork can be seen as a batching opportunity where multiple upgrades are bundled into one fork, offering both technical advantages and governance benefits.
This batching opportunity can be referred to as "Cathedral Accelerationism." This may sound contradictory, but the basic idea is to push Ethereum into maintenance mode as soon as possible due to existing tensions. We are aware that there are essential projects requiring a fundamental overhaul of Ethereum, and the longer these changes are delayed, the farther Ethereum is from reaching a stable state.
What Technologies Does Beam Chain Use?
In the following part, I will introduce some of the technologies that will be used in the Beam Chain. This can be seen as different epochs of the Ethereum consensus mechanism: starting with the Proof of Work (POW) era, moving into the Proof of Stake (POS) era, and potentially transitioning into a Zero-Knowledge Proof (ZK) era now.
In the ZK era, we will heavily rely on SNARKs technology. One area where we are already using SNARKs is to provide zero-knowledge validation for the entire Beam Chain—the whole consensus layer—making zkVMs (Zero-Knowledge Virtual Machines) very useful.
Imagine being able to implement the Beam Chain in different high-level programming languages like Rust and Go, then compile these high-level languages into bytecode understandable by zkVMs to achieve SNARK verification, without worrying about the underlying details.
One key point to emphasize is that the only part that needs 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, syncing, caching optimizations, or block selection rules) does not need 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. Seven companies are now offering RISC-V zkVMs, such as RISC Zero and SP1 that you might 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 very exciting as it means we can significantly increase the gas limit, enhancing Ethereum's vertical scalability as L1. However, this is another topic.
Another significant use of SNARKs in Beam Chain is for aggregatable signatures. We aim to have quantum-resistant aggregatable signatures, with the proposal here being to use hash functions. Hash functions provide 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 that 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 for Ethereum. An interesting detail is that this aggregation scheme has the ability for infinite recursive aggregation, meaning that aggregated results can be further aggregated, a flexibility that current BLS signatures lack.
I am presenting this proposal today because in recent months, the performance of SNARK hash functions has made tremendous progress. For those who are aware, we can now perform verification on a laptop.
This benchmark was done on a MacBook Pro CPU, and we can now verify 2 million hashes per second, which is incredibly impressive speed. This means that this hash-based proposal has great performance potential on Beam Chain.
In addition to the zkVMs and SNARKs we will be using, I also want to emphasize that we will largely reuse existing infrastructure.
For example, network libraries like libp2p, serialization libraries like Simple Serialize, can all be directly reused. The Pyspec framework is no exception; this is the Python specification framework we use to write formal specifications and unit tests.
Furthermore, 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 freely reusable.
Similarly, there are now multiple teams supporting Beacon Chain development, whereas back then we did not have teams for consensus clients. The current five consensus client teams can be directly deployed without the need for reassembly.
In addition, we have dedicated teams for merging operations, such as the Panda Ops team providing DevOps support, security teams, incentive teams, and application research groups—all of which are valuable resources that can be directly utilized.
Lastly, I would like to talk about the next steps and future outlook. One possible outcome is that starting from 2025, we will enter a normalization process. This will be conducted by a small group of researchers and may take an entire year. In 2026, the development process will begin, with client teams starting to write production-grade code, followed by a very thorough testing process in 2027 to ensure security and deployment stability.
Image Source: Uncommons Daisuke
As a researcher, my next task is to start writing an executable specification, which I call an "executable roadmap." Our idea is to combine the "pixels" in the roadmap, the hundreds of thousands of words from various research and academic papers, and the myriad ideas in researchers' minds to extract the core essence and create an executable specification document. Ultimately, this will be a very concise document, approximately 1000 lines of Python code.
One exciting aspect for me is that if there is a rough consensus on Beam Chain's new direction, this will be an excellent opportunity to inject fresh blood into the consensus clients.
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 a Beam client. One of the teams 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 expressed interest in developing a Beam client.
If you are also interested in participating, we need a large number of excellent talents, including standards and networking 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!
Disclaimer: The content of this article solely reflects the author's opinion and does not represent the platform in any capacity. This article is not intended to serve as a reference for making investment decisions.
You may also like
Musk: I'm beginning to think that the Department of Government Efficiency (DOGE) has real potential
The total market value of stablecoins increased by 2.46% in the past week
US spot Ethereum ETF had a net outflow of US$59.86 million yesterday