Future of Ethereum (1): Beam Chain

18 min readJan 6, 2025

Thanks to Ladislaus, Gavin, and Justin Drake for valuable feedbacks and helps to complete this article.

Introduction

In 2024, many significant events occurred surrounding Ethereum. Early in the year, Ethereum introduced blobs through the Dencun upgrade. This update dramatically reduced transaction costs for existing rollups, laying the foundation for the rapid expansion of rollup ecosystems.

(Fee reduction in OP Chains after the Dencun upgrade | Source: Optimism X)

However, as dApps within the ecosystem migrated to highly scalable rollups and alternative Layer 1 (L1) networks, user activity on Ethereum itself tended to decline. Additionally, as rollups stopped submitting high fees to Ethereum, concerns began to arise within the community.

Furthermore, 2024 was a year when scalability-focused L1s like Solana and Sui demonstrated significant strength. The enormous TPS (transactions per second) generated by these networks made the activity on rollups seem relatively small.

In this context, criticisms emerged, such as “Ethereum’s rollup-centric roadmap is flawed” or “Ethereum’s development is too slow to succeed.”

Is Ethereum truly on the right path? What will Ethereum look like in 2025 or even 2030?

This series delves into parts of Ethereum’s roadmap under 3 main topics, analyzing its future based on technical details. The first topic is the Beam Chain.

Future of Ethereum Consensus: Beam Chain

If one were to choose the most talked-about topic within the Ethereum community this year, it would likely be the announcement on the Beam Chain by Ethereum researcher Justin Drake at Devcon. This announcement garnered a great deal of interest and, correspondingly, a lot of noise. Let’s analyze what this proposal means.

Summary of Proposal

The core idea of the Beam Chain proposal is to completely redesign Ethereum’s consensus layer. Justin Drake presented the following three reasons as to why the current consensus layer, the Beacon Chain, needs to be redesigned:

Better understanding of MEV through past experiences.
Rapid advancements in SNARK technology (e.g., zkVM development progressing at an astonishing rate, over 10 times faster).
Eliminating the “technical debt” present within the Beacon Chain.

Currently, Ethereum’s consensus layer roadmap includes the following elements:

Among these, the four areas marked in red represent fundamental changes that go beyond mere modifications to the Beacon Chain.

For instance, chain snarkification refers to converting the state handling of the consensus layer to ZK technology, requiring fundamental changes starting from hash functions to the methods of merkleizing/serializing state.

Additionally, Faster slots and Faster finality are new designs proposed to achieve performance improvements while maintaining security, a factor not prioritized in the initial designs. Implementing these requires extensive changes at the consensus layer.

The Beam Chain proposes to achieve these changes through a single hard fork. To summarize:

Implementing the roadmap for Ethereum’s consensus layer requires a complete redesign of the consensus layer.
To this end, major changes on the roadmap will be bundled into a hard fork named Beam Chain.
This includes four elements: faster block times, faster finality, chain snarkification, and quantum resistance.

Next, let’s explore how each of these is implemented and the technical impacts they entail.

Faster Slot & Faster Finality

Currently, Ethereum’s slot time is 12 seconds, and it takes 2–3 epochs (approximately 15 minutes) for a block connected to a slot to reach finality. Improving these times would positively impact Ethereum users, apps, and rollups building on Ethereum.

Shorter Finality — Orbit SSF

This topic, known among Ethereum researchers as SSF (Single Slot Finality), aims to reduce the time for Ethereum blocks to reach finality from about 15 minutes to within 12 seconds, providing users with faster confirmation.

The key design principles of Ethereum’s current consensus algorithm, Gasper, are as follows:

Ensure that a block proposed in a slot attains a certain level of economic security after a set amount of time while minimizing the communication load on each validator.

To achieve this, Ethereum divides the entire set of validators into committees distributed across 32 slots. Each slot can contain up to 64 committees, and the goal is to compose each committee of 128 validators (though this number can increase if the total number of active validators exceeds this).

Validators within each committee independently verify the block and vote on it in the form of BLS signatures. The BLS signature mechanism allows multiple signatures to be aggregated into one, meaning that a designated node within the committee collects these signatures and compiles them into a single compact data package. By broadcasting this aggregated signature, the next block proposer can confirm with minimal data that the block has been properly verified.

(BLS signature Aggregation between Ethereum’s validators | Source: eth2book)

In summary, Ethereum’s Gasper achieves both scalability and economic security through the following mechanisms:

Validators are distributed across slots in committees over a 6.4 minute period, eliminating the need for direct communication among all validators.
The aggregated signature process ensures that validators’ votes on the block are verifiable with a small amount of data.

However, an issue arises because Gasper operates on an epoch basis, and the “connectivity” between epochs must be verified before a slot can reach finality. In Gasper, a minimum of two epochs (64 slots) must pass before achieving finality equivalent to Ethereum’s full economic security.

This results in the following diagrammatic representation:

(Economic Finality at Gasper | Source: Orbit SSF)

This introduces various challenges and diminishes UX. For instance:

When withdrawing funds from a CEX (centralized exchange) to Ethereum, or vice versa, the confirmation period may be about 10 minutes, which can be seen as excessively long.
Ethereum rollups and dApps face the risk that the L1 blocks they rely on may not be finalized and could become invalidated. If proper countermeasures are not implemented, this can lead to issues.
For example, in March 2024, Polygon zkEVM experienced a chain halt lasting over two days due to improper handling of an Ethereum reorg.

Reducing the time to finality is not impossible, as demonstrated by consensus algorithms like Tendermint, which are already applied in several protocols. However, the challenge with adopting Tendermint’s mechanism lies in the frequent P2P communication among nodes, which introduces scalability limitations.

In Tendermint, if the number of nodes is N, its message complexity is O(N³). This means that as the number of nodes increases, the frequency of communication among them grows exponentially, restricting scalability. Thus, protocols like Ethereum, with a large number of validators, cannot directly adopt Tendermint as is.

To apply Tendermint-style consensus to Ethereum, additional work is needed to address these issues.

Orbit SSF Proposal

Orbit SSF aims to modify Gasper’s committee mechanism to reduce the time for slot finality while maintaining high economic security.

The proposal is to reduce the epoch size of 32 slots to a single slot (~12 seconds). However, as mentioned earlier, this would increase the resource usage for validator communication, negatively impacting Ethereum’s decentralization.

To address this, Orbit SSF proposes the following ideas:

Increasing the maximum staking amount for each Ethereum validator can achieve the same level of economic security with fewer validators.
Instead of having multiple committees per slot, Orbit SSF suggests introducing a single “super committee.” Validators with higher staking amounts would almost always be included in the committee proportionally, ensuring that even with fewer committees, the same economic security level is maintained.

The next Ethereum upgrade, Pectra, includes EIP-7251, which proposes raising the maximum staking amount (MaxEB) for validators from 32 ETH to 2048 ETH. While this is an attractive proposal for Ethereum node infrastructure operators, it is also a prerequisite for Orbit SSF.

However, if validators with large staking amounts are almost always included in committees, smaller solo validators might experience reduced rewards, potentially harming Ethereum’s decentralization. To prevent this, Orbit SSF adjusts rewards so that the APR increases linearly with the staking amount, while ensuring that larger validators are included in committees more frequently.

(Reward and Probability to be included in the committee in Orbit SSF | Source: Orbit SSF)

Additionally, Orbit SSF shifts towards “committee-based finality.” In Gasper, committees could only contribute to finality after two or more epochs had passed, but Orbit SSF allows each slot-assigned committee to contribute to finality in real time. This aims to make committees more active contributors to finality and achieve scalability faster.

(Finality in Orbit SSF using Cap-and-slow-rotate | Source: Orbit SSF)

The key here lies in the composition of committee members. Orbit SSF proposes a “slow rotation” mechanism where large-stake validators are mathematically almost fixed within committees while smaller validators are rotated in and out. This allows the value of F, representing the economic security threshold, to be set very high while maintaining minimal communication overhead among validators and ensuring finality times remain low.

For instance, setting n = 3 and significantly big F would enable Ethereum to achieve finality within roughly 3 slots, thereby realizing Justin Drake’s vision of 3-slot FFG.

Orbit SSF’s Goal in Faster Finality

However, in reality, raising F to the level of Ethereum’s entire validator set is not an easy task. This could lead to a reduced cost for conducting a 51% attack on Ethereum. As such, the primary challenge for Orbit SSF moving forward is determining how to technically increase F to ensure Ethereum’s security remains robust, without sacrificing much decentralization.

Shorter Slot Time (4 Seconds)

Even if SSF (or 3-slot finality) is achieved, Ethereum users would still experience a minimum transaction confirmation time of 12 seconds. This leads to two main drawbacks for users:

Long latency compared to other L1s like Solana and Sui.
Higher vulnerability to MEV. Generally, the amount of MEV decreases as block time shortens, making Ethereum users less susceptible to MEV.

Additionally, a 12-second block time is particularly unfavorable for rollups, especially based rollups. For example, Taiko implements a based rollup by posting every L2 block to L1. As a result, Taiko’s block time could increase to a minimum of 12 seconds and sometimes exceed 24 seconds.

To address this, two solutions have been proposed:

Reduce Ethereum’s block time to 4 or 8 seconds.
Use preconfirmation.

Reducing Ethereum’s Block Time

Reducing Ethereum’s block time is a topic of active discussion. It has been formalized as EIP-7782, which proposes reducing the slot time from 12 seconds to 8 seconds, thereby increasing Ethereum’s scalability by 33%.

However, an 8-second slot time may not be optimal for user experience or based rollups. Achieving a shorter slot time seems more desirable.

That said, shorter block times could lead to increased centralization of the validator set. Geographically distant validators face longer communication times due to physical constraints, and a 4-second slot time could make communication infeasible in certain scenarios.

Ethereum mainnet’s block propagation time statistics provide insight into the feasibility of a 4-second block time. The graph below shows the distribution of block propagation times.

(CDF of message arrival times | *Source:* *Gossipsub Message Propagation Latency*)

Approximately 98% of blocks are propagated within 4 seconds, while about 2% take longer. Based on this data, a 4-second block time may appear feasible. However, block time accounts for more than just communication — it also includes execution and voting. Considering these factors, only about 2 seconds of a 4-second block time would be available for communication. Under these conditions, achieving a 4-second block time is challenging.

To address this, the size of transmitted data must be reduced, the performance of P2P components in clients must be maximized, or physical communication must become more efficient.

Using Preconfirmation

In the interim, preconfirmations can improve user experience. Preconfirmation allows block-producing entities to promise users, “Your transaction will be included in the next block,” delivering results to users faster than the slot time.

The advantage of preconfirmation is that it can be utilized by L1 validators without requiring a fork or client modifications. For instance, Commit-Boost is an example of software that enables Ethereum validators to safely generate and propagate preconfirmations.

Commit-Boost, like MEV-Boost, is an optional sidecar for validators, allowing them to safely generate and propagate “commitments.” Depending on the use case, these commitments can take various forms:

Using the third type of preconfirmation architecture, perceived latency for users can be significantly reduced even with longer block times. When a user’s transaction is received by a validator, the validator can execute it and return the result to the user. Since this result is based on the validator’s commitment and not block creation, users can receive it within milliseconds.

However, Commit-Boost’s effectiveness depends on validator adoption. If only a small number of validators use it, the impact on UX will be minimal. That said, Commit-Boost has garnered strong support from the Ethereum community and has the potential to become a widespread middleware like MEV-Boost. It has received endorsements from well-known validator operators such as Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41, and Figment. Additionally, it has secured grants from EF, Lido, and Eigenlayer, and enjoys strong support from block builder Titan.

Nevertheless, as mentioned earlier, preconfirmation is more likely to be used as an off-chain sidecar like MEV-Boost rather than being integrated directly into the protocol.

Beam Chain’s Goal in Faster Slots

As discussed in Justin Drake’s presentation, the goal of Beam Chain is to reduce block times. Thus, the research and implementation will likely focus on how to reduce slot time to 4 seconds without much sacrificing decentralization. This may be solved with the full snarkification of Ethereum, which will be explained in the latter part of this article.

Chain Snarkification and Quantum Resistance

Justin stated in his presentation that the goal of Beam Chain is to snarkify the consensus client using ZK technology. What does this mean, how can it be achieved, and why is it necessary?

Chain Snarkification

Currently, the Ethereum Beacon Chain achieves consensus by having validators “re-execute” every block to verify that the resulting state root is correct. This re-execution process introduces inefficiencies and acts as a barrier to lowering the hardware requirements for validators.

Beam Chain aims to replace this re-execution process with “verification” using ZK technology, significantly lowering the hardware requirements for validators and enabling anyone to run an Ethereum node from anywhere. To achieve this, Beam Chain and Ethereum will utilize ZK SNARKs.

ZK in Ethereum Core

ZK SNARKs have the following two properties:

They allow verification of the fact that a certain computation has been performed without needing to re-execute the computation.
The proof size is compact compared to the original data.

The idea is to apply ZK to the computations and data required for consensus in Ethereum, generating a proof that the prescribed logic has been followed. This means that instead of re-executing the entire block and storing the updated state, validators can achieve consensus by verifying the ZK proof. Verifying a ZK proof is vastly more efficient in terms of data size and scalability compared to re-execution.

As a result, the hardware requirements for Ethereum validators can be dramatically reduced. For example, Vitalik has expressed in The Verge article that the goal is to enable validators to operate even on resource-constrained environments such as smartwatches.

What Needs to Be Done?

The first step is snarkifying the state transition function. The state transition function generally takes the following form:

f(S,B)=S’

Here:

S: The pre-state of the blockchain.
B: The given block.
S’: The post-state of the blockchain after executing the block.
f: The state transition function.

All blockchains are based on deterministic state transition functions, and Ethereum is no exception. Ethereum has different state transition functions for both its consensus layer and execution layer. Snarkifying both of these would make it possible to verify the entire Ethereum system using ZK, thus enabling fully lightweighted validators.

In Beam Chain, the goal is to snarkify the state transition function of the consensus layer. Currently, the state transition function within Ethereum’s consensus layer is executed every slot and performs the following actions:

Updates slot and block header information after receiving a block.
Verifies the signature of the validator who proposed the block.
Validates the transactions within the block.
Processes withdrawals, slashing, block finalization, and other information whenever an epoch transitions.

This function is executed every time a validator receives a block from another validator. If this function is snarkified, validators would no longer need to execute the state transition function directly. Instead, they could verify a proof showing that the function was executed correctly.

In this case, who generates the ZK proof? Typically, one might assume that the proposer of the block is also responsible for generating the ZK proof. However, it’s important to consider that not all validators may have the capability to generate ZK proofs. Beam Chain aims to achieve performance where a ZK proof can be generated within 3 seconds on a standard laptop. Even if this goal is met, validators running on devices like smartwatches or smartphones may not have sufficient resources to generate ZK proofs.

Here, the network can rely on altruism. Only one ZK proof for the state transition of the consensus layer is needed per block, and it doesn’t necessarily have to be generated by the block proposer. In other words, as long as there is at least one entity in the network generating a ZK proof for each block, it can ensure that Beam Chain’s blocks are correctly produced.

Future: Full Snarkification of Ethereum

This change alone might not significantly improve validator performance. The state transition function of the consensus layer involves relatively lightweight actions compared to the execution layer’s state transition function. However, the primary bottleneck lies not in the resources required to execute the state transition function but in the network bandwidth. Validators struggle to achieve consensus within the allocated time when the size of the data (blocks) they exchange increases. This is one reason Ethereum has maintained a 30M gas limit for the past three years.

If this change is implemented alongside the snarkification of the execution layer, validators would only need to exchange much smaller amounts of data compared to entire blocks. This is because SNARK proofs are significantly more compact than the original data. Fully snarkified Ethereum validators would exchange less data, reducing the network requirements compared to the current system.

In summary the followings are the advantages of full snarkification of Ethereum, for validators.

Validators only need to verify proofs, not re-execute computations, lowering computational demands.
Validators exchange proof data instead of full block data, reducing network bandwidth requirements.

As a result, Ethereum’s ecosystem could change dramatically. For example:

Things like “Ethereum Node Apps” could allow validators to operate on mobile devices.
Anyone meeting the minimum staking requirements could run an Ethereum node, significantly lowering the barrier to becoming a validator.

This would make validator participation much more accessible and decentralized.

Quantum-Resistant Signatures

Does snarkifying the state transition function alone suffice for the Beam Chain as a consensus layer?

Problem of Ethereum in post-quantum world

There is another area that Beam Chain aims to snarkify: signature generation. Currently, Ethereum’s consensus layer uses validator signatures in the form of attestation data to finalize blocks and determine the correct chain in case of forks. Ethereum currently employs BLS signatures for this purpose, which, as explained earlier, have the property of aggregation, enabling multiple signatures to be combined into one. This aggregation significantly improves the efficiency of Ethereum’s consensus process.

However, there is a fundamental issue with this signature mechanism: it is vulnerable to quantum computers.

The BLS signatures used in Ethereum’s Beacon Chain are based on elliptic curves. The security of elliptic curve-based signature mechanisms relies on the Discrete Logarithm Problem (DLP), which could be compromised by the superior computational power of quantum computers. This makes elliptic curve-based signatures inherently vulnerable to quantum computers.

Quantum computing has been advancing rapidly, as evidenced by Google’s recent developments with quantum computing chips such as Willow. Google claims that Willow can perform calculations in 5 minutes that would take a supercomputer for 10²⁵ years. While this does not yet threaten the security of elliptic curves fundamentally, continued advancements at this pace could put blockchain systems at risk within a few years.

(Transition to Post-Quantum Cryptography Standards | Source: NIST IR 8547)

The U.S. National Institute of Standards and Technology (NIST) has already begun efforts to standardize quantum-resistant signature algorithms to address the anticipated collapse of existing systems due to quantum computers.

Ethereum is also taking this issue seriously, and in Beam Chain, the goal is to achieve quantum-resistant signature algorithms.

There are several types of quantum-resistant signatures, but Justin’s Beam Chain presentation specifically mentioned hash-based signature algorithms. Unlike elliptic curves, hash-based signatures do not rely on mathematical mechanisms, making them significantly harder for quantum computers to compromise. As a result, hash-based signatures are considered quantum-resistant, and Beam Chain aims to adopt such signatures.

Challenges and the Role of ZK

The main challenge here is that hash-based signatures lack the aggregation property present in BLS signatures. Ethereum relies on signature aggregation during consensus to achieve efficiency. Without aggregation, Ethereum would no longer be able to accommodate a large validator set.

To address this, ZK can be used. This involves leveraging Proof Aggregation, a technology that combines multiple ZK proofs into a single proof. The mechanism works as follows:

(Diagram of Proof Aggregation | Source: Figment Capital)

Validators sign a block using a quantum-resistant algorithm.
The signatures are sent to an aggregator or aggregation Committee.
The aggregator generates a ZK proof verifying the correctness of the signatures.
Using proof aggregation techniques, the aggregator combines new proofs with existing ones as new signatures are received.

This approach enables Ethereum to achieve the same efficiency as BLS signature aggregation while also attaining quantum resistance at the consensus level.

Roles of ZK in Beam Chain

In summary, Beam chain with ZK will bring the following advantages:

Enabling validators to perform proof verification instead of re-execution for the consensus layer’s state transition function, contributing to lightweight validator requirements.
Serving as the basis for an aggregation algorithm for quantum-resistant signatures, improving the efficiency of the consensus layer.

zkVM as the Foundation for ZK in Beam Chain

The proof system underlying ZK in Beam Chain will be zkVM. Risc-V based zkVM allows any program in any language to be proven, offering greater flexibility.

(Beam state transition to be compiled into Risc-V and proven in zkVMs | Source: Beam Chain Announcement by Justin Drake)

This aligns well with Ethereum’s existing client ecosystem, which is developed in multiple languages, preserving Ethereum’s diversity and fault tolerance. In the future Beam chain, multiple clients will write the state transition function in multiple programming languages, compile it to Risc-V, and allow it to be proven in any Risc-V based zkVMs. For this reason, zkVM is a natural choice for Beam Chain.

Short Q&A about Beam Chain

Q) Justin Drake’s proposal was discussed privately. Doesn’t this conflict with Ethereum’s core value of being “open”?

A) No, it does not. The Beam Chain proposal is simply a suggestion to implement certain parts of Ethereum’s existing roadmap in one go. Whether or not it will be implemented is something that still requires community discussion.

All the topics discussed above already have associated EIPs or posts on ethresearch, which confirms that Beam Chain is not a proposal to discuss anything previously undisclosed.

Discussions regarding Ethereum’s roadmap are held publicly during the biweekly All Core Devs Call, which anyone can participate in. If someone disagrees with the roadmap or has new ideas, they can voice their opinions during these calls or submit new proposals in the form of EIPs or posts on ethresearch.

In summary, Justin’s Beam Chain proposal is not about changing the roadmap but rather grouping parts of the roadmap under a single name or meme.

Q) Isn’t 4 years too long to implement Beam Chain?

A) Four years might feel like a long time, but two factors need to be considered:

Ethereum is built on a multi-client architecture.
Ethereum has the largest number of validators of any blockchain.

Ethereum’s consensus mechanism follows a BFT-based protocol where if more than one-third of validators act differently from others, blocks cannot be finalized. If Ethereum were built with only one or two clients, any bug in these clients could disrupt block production. Therefore, Ethereum has always aimed for a multi-client architecture developed in multiple programming languages. This diversity is evident in Ethereum’s current client ecosystem.

(Consensus client diversity | Source: Ethereum Client Diversity)

As shown in the image, Ethereum’s consensus layer currently operates with at least four clients. To replace the Beacon Chain with Beam Chain, all four client teams must collaborate on development.

Considering this and Ethereum’s large validator set, the Beam Chain development process must prioritize stability and cannot be accelerated to a timeframe of a few months or 1–2 years.

Conclusion

If Beam Chain is successfully implemented, Ethereum will likely have the following features:

Users will experience transaction confirmations within 4 seconds, with finality achieved within 12 seconds.
Validators will verify state transitions in the consensus layer using ZK proofs. If the execution layer is also snarkified, validators will only need very small amounts of data to participate in consensus. It will enable Ethereum validators to be run inside smart phones or smart watches.
Validator signatures will be quantum-resistant, preventing quantum computers from compromising Ethereum’s consensus.

Currently, Beam Chain has not been officially recognized as part of Ethereum’s roadmap. Its implementation would require extensive research, development, and testing over a long period. However, if Ethereum does proceed with the Beam Chain fork, the resulting UX improvements could be transformative.

This concludes our exploration of how Ethereum might evolve in five years through the lens of Beam Chain. In the next article, we will examine the ‘censorship resistance solutions in Ethereum’.