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 began 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 two main topics, analyzing its future based on technical details. The first topic is the Beam Chain.

What is the Beam Chain proposal, and why does it matter?

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

The core idea of the Beam Chain proposal is to redesign Ethereum's consensus layer completely. 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:

	Block production	Staking	Cryptography
P0	Censorship resistance (FOCIL)	Smarter issuance (e.g stake cap)	Chain snarkification (e.g. Poseidon + zkVM)
P1	Isolated validators (execution auctions)	Smaller validators (1 ETH Orbit staking)	Quantum security (e.g. hash-based sigs)
P2	Faster slots (4 sec)	Faster finality (3-slot FFG)	Strong randomness (e.g., MinRoot VDF)

Among these, the four areas marked as bold 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:

1. Implementing the roadmap for Ethereum's consensus layer requires a complete redesign of the consensus layer.

2. To this end, major changes on the roadmap will be bundled into a hard fork named Beam Chain.

3. It 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.

Technical details of the Beam Chain design

Faster slots & 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. To understand single-slot finality, we must understand Ethereum's current consensus algorithm, Gasper.

A key design principle of Gasper is ensuring that a block proposed in a slot attains a certain level of economic security after a set 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 using 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 can be verified using 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 complete 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 is relatively excessive.

• 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 may cause issues.

For example, in March 2024, Polygon zkEVM experienced a chain halt lasting over two days due to improper handling of 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^3). This means that as the number of nodes increases, the frequency of communication among them grows exponentially, restricting scalability. Thus, protocols like Ethereum, with many validators, cannot directly adopt Tendermint as is.

Additional work needs to be done to address these issues to apply Tendermint-style consensus to Ethereum.

An overview of the 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 proportionally in the committee, ensuring that the same economic security level is maintained even with fewer committees.

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 proposal is attractive 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 andProbability 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. It 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 a significantly big F would enable Ethereum to achieve finality within roughly three slots, thereby realizing Justin Drake's vision of a 3-slot FFG.

However, raising F to the level of Ethereum's entire validator set is not easy. It could reduce the cost of 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 times (4-second slots)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:

1. Long latency compared to other L1s like Solana and Sui

2. Higher vulnerability to MEV (MEV decreases as block time shortens, making Ethereum users more 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.

Two solutions have been proposed to address this:

a. Reduce Ethereum's block time to 4 or 8 secondss

b. Use preconfirmations

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. Due to physical constraints, geographically distant validators face longer communication times, 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 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 preconfirmations

In the interim, preconfirmations can improve user experience. Preconfirmations allow 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 L1 validators can utilize it without requiring a fork or client modifications. For instance, Commit-Boost is software enabling Ethereum validators to generate and propagate preconfirmations safely.

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:

Commitment	Use case
“Your transaction won’t be censored and will be included in the next block.”	Inclusion List
“This rollup’s batch submission transaction will be included in the next L1 block.”	Blob preconfirmation
“Your transaction will be in the next block, and the execution result is X.”	Preconfirmation

Using the third type of preconfirmation architecture, perceived latency for users can be significantly reduced even with longer block times. When a validator receives a user's transaction, they 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 few 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 role 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 reducing slot time to 4 seconds without sacrificing decentralization. It 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 Beam Chain's goal 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. It would significantly lower the hardware requirements for validators and enable anyone to run an Ethereum node from anywhere. To achieve this, Beam Chain and Ethereum will utilize ZK SNARKs.

ZK in the Ethereum protocol

ZK SNARKs have the following two properties:

1. They allow verification of the fact that a certain computation has been performed without needing to re-execute the computation

2. 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 proof that the prescribed logic has been followed. This means that validators can achieve consensus by verifying the ZK proof instead of re-executing the entire block and storing the updated state. Verifying a ZK proof is vastly more efficient in terms of data size and scalability than 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 its consensus and execution layers. Snarkifying both of these would make verifying the entire Ethereum system possible using ZK, thus enabling fully lightweight 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 in 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 note that not all validators can generate ZK proofs.

Beam Chain aims to achieve performance where a ZK proof can be generated within 3 seconds on a standard laptop. But, 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 at least one entity in the network generates 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 that 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 fewer data, reducing the network requirements compared to the current system.

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

1. Validators only need to verify proofs, not re-execute computations, lowering computational demands

2. 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?

What problems will Ethereum face in a post-quantum world?

There is another area that Beam Chain aims to snarkify: signature generation. Ethereum's consensus layer currently uses validator signatures as 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, this signature mechanism has a fundamental issue: 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 the superior computational power of quantum computers could compromise. 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^25 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. 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 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.

 ZK can be used to address this. It 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)

1. Validators sign a block using a quantum-resistant algorithm.

2. The signatures are sent to an aggregator ****or aggregation Committee.

3. The aggregator generates a ZK proof verifying the correctness of the signatures.

4. 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:

1. Enabling validators to perform proof verification instead of re-execution for the consensus layer's state transition function contributing to lightweight validator requirements.

2. 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 the proof of any program in any language, 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, various 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.

Conclusion

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

1. Users will experience transaction confirmations within 4 seconds, with finality achieved within 12 seconds.

2. Validators will verify state transitions in the consensus layer using ZK proofs. If the execution layer is also snarkified, validators will only need minimal amounts of data to participate in consensus.

3. Validator signatures will be quantum-resistan

4. t, preventing quantum computers from compromising Ethereum's consensus.

Currently, Beam Chain has not been officially recognized as part of Ethereum's roadmap. Implementing it would require extensive research, development, and testing over a long period. However, if Ethereum proceeds 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 what Ethereum might look like in 2025 from two perspectives: UX and censorship resistance.

Appendix: Beam Chain FAQs

(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 simply suggests implementing 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 Ethresear.ch. This, more or less, shows that the Beam Chain is not a proposal that proposes a new, previously undisclosed direction for Ethereum. Moreover, 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 Ethresear.ch.

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 5 years too long to implement Beam Chain?

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

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

(Consensus client diversity | Source: Ethereum Client Diversity)

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.

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.