Written by Tia, Techub News

At yesterday's Thailand Devcon Mainstage, Ethereum researcher Justin Drake completed the first release of the Beam Chain proposal in the form of a speech. Beam Chain is Justin's proposal to redesign the consensus layer of Ethereum, which is a further upgrade to the Beacon Chain, in order to further advance Ethereum's ultimate vision. This article will give you a quick look at the goals of the Beam Chain proposal and its related technical implementation.

Although redesigned as a consensus layer, Beam Chain will still use Ether tokens and will not issue new tokens or a new network.

Why propose Beam Chain?

Ethereum has three layers: the execution layer, the blob Data Layer, and the consensus layer. The execution layer is the part of Ethereum that processes transactions and executes smart contracts, directly managing the state and logic of the applications. The blob Data Layer is responsible for storing large amounts of data, involving long-term data storage required by the applications. These two layers are the levels that directly interact with the applications, and any changes will directly affect the compatibility of these layers.

The Consensus layer is mainly responsible for ensuring the data Consensus between nodes in the entire network, and does not directly handle the state or data of the application. This indirectness makes it relatively easier to introduce innovation and upgrades without directly affecting the application. Therefore, improvements to the Consensus layer, such as the Beam Chain proposal, can provide innovation space without disrupting the compatibility of the front-end Application Layer.

And, Beacon Chain is a design from 5 years ago, and it is very outdated. After 5 years, the market has a full understanding of some mistakes in Beacon Chain and a further understanding of MEV. Just as SNARK technology has also made a breakthrough, taking advantage of this breakthrough, a series of repairs will be made to the ETH blockchain consensus layer.

Goals of the Beam Chain Project

The target can be divided into three parts: Block production, stake, cryptography.

There are three goals for Block production, mainly related to MEV: first, to increase resistance to censorship by using inclusion lists; second, to isolate validators from Block production through methods such as Attester Proposer Separation and auction execution; third, to achieve faster slots by reducing slot time to 4 seconds.

The goal of the stake section is to improve the current issuance curve, drop the stake threshold from 32 ETH to 1 ETH, and achieve fast and final single slot finality.

The goal of the cryptography part is to use zkVM and other technologies to snarkify the chain; maintain the security of ETH cryptography to ensure its continuity for decades or even centuries; and use MinRoot VDF and other technologies to maintain strong randomness.

For the implementation of these goals, Justin divides such goals into two categories. The green part should be gradually completed through forks, and the red part should be completed simultaneously as a whole.

Taking snarkifacation (using zk-SNARKs technology to prove data or computation) as an example, if real time proving is desired, some structural adjustments must be made in the system, including hash functions, signature methods, as well as changes in serialization and Merkleization. The signature method needs to be able to generate and complete verification quickly, and serialization is required to enable complex data structures to be transmitted and stored between Nodes, and the serialized data is then subjected to Merkle Tree processing, thereby meeting the need for Zero-Knowledge Proof to verify the data in a verifiable format and to efficiently verify the state.

ZK-ized Beam Chain

In the past, the Consensus of Ethereum went through a change from POW to POS, while in the mechanism of Beam Chain, Consensus will have further updates - fully ZK, which means applying snark to the entire Consensus layer.

Chain snarkification

It should be emphasized that the snarkified part only exists in state transitions, but some basic level computations (the logical computations done by the Consensus Mechanism before processing transactions or state transitions), network layer (communication and data transmission between Nodes), cache management, and performance optimization remain unchanged and are not affected by ZK.

The work that needs to be done to implement the Beam Chain's implementation code (for example, the core logic and ConsensusAlgorithm code of the Beam Chain written in Go or Rust) is to convert the code into a format that zkVM can understand. After the implementation code of the Beam Chain is compiled into the code format of zkVM, zkVM can execute these codes, read external inputs of the Block chain, verify the legality of the state transition process, and generate Zero-Knowledge Proof.

zkVM is an environment for executing Zero-Knowledge Virtual Machine, which can understand code in a specific format for Zero-Knowledge Proof verification. The process of compiling code into an executable format for zkVM may involve converting high-level languages (such as Go or Rust) into a low-level, intermediate format (such as the RISC-V instruction set), and then executing it in zkVM.

Currently, RISC-V has become the industry standard for zkVM. There are currently seven companies offering Risc-v zkVM.

Attestation****snarkification

Another part that uses snark is aggregatable signatures, which is the compressed process of signing by multiple validators and attesters, aggregating a large number of signatures into a single, verifiable proof.

We hope to have post-quantum aggregate signatures security (resistant to quantum attacks), so hash functions are expected to be used here. Hash functions have post-quantum security levels and can be used as basic components or building blocks for cryptographic systems. By using hash-based snarks, thousands of signatures can be compressed into one proof. This is post-quantum aggregate signature. Moreover, this post-quantum aggregate signature is infinitely recursive, you can continuously stack and aggregate multiple aggregate signatures to achieve higher compression efficiency, compared to traditional BLS signature aggregation, achieving a significant improvement.

In the past few months, the snarkified hash function technology has made significant progress, allowing proofs to be quickly generated through laptops and enabling about 2 million hash operations per second. This performance breakthrough makes post-quantum secure aggregate signature schemes more practical in reality, providing possibilities for efficient and quantum-resistant encryption.

Moreover, the snarkified Beam Chain compresses the originally complex verification, storage, and computation processes, enabling a series of infrastructure such as libp2p, ssz, pyspec, protocolguild, which were originally not directly applicable to the Beacon Chain, to be implemented.

Timeline Planning

In terms of timeline planning, Justin plans to establish specifications in 2025, build in 2026, and conduct testing in 2027. Currently, there are two teams willing to develop the Beam Chain Consensus client. One is Zeam lambda from India, and the other is Lambda from South America.