Quick read of Justin’s new Ethereum consensus layer proposal Beam Chain

Written by: Tia, Techub News

Yesterday, at the Mainstage of Devcon in Thailand, Ethereum researcher Justin Drake completed the first presentation of the Beam Chain proposal in the form of a speech. Beam Chain is Justin's proposal to redesign the Ethereum consensus layer. This proposal is a further upgrade of Beacon Chain to further move towards the ultimate vision of Ethereum. This article will take you to a quick look at the goals of the Beam Chain proposal and its related technical implementation.  

Although it is a redesign of the consensus layer, Beam Chain will still use Ethereum tokens, and will not issue new tokens or new networks.

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 handles transactions and executes smart contracts, and directly manages the state and logic of the application. The blob data layer is responsible for storing large amounts of data, which involves long-term data storage required by the application. These two layers are the layers that directly interact with the application, and any changes will directly affect the compatibility of these layers.  

The consensus layer is mainly responsible for ensuring data consensus among nodes in the entire network, and does not directly process the state or data of the application. This indirectness makes it relatively easy to introduce innovations and upgrades without directly affecting the application. Therefore, consensus layer improvements such as the Beam Chain proposal can provide room for innovation without destroying the compatibility of the front-end application layer.  

In addition, Beacon Chain was designed 5 years ago and is already very old. After 5 years, the market has fully realized some of the errors in Beacon Chain and has further deepened its understanding of MEV. It coincides with the breakthrough of SNARK technology. Therefore, taking advantage of the breakthrough, a series of repairs were made to the Ethereum consensus layer.  

Goals that Beam Chain plans to achieve 

The goals can be divided into three parts: block production, staking, and cryptography.  

There are three goals for block production, mainly related to MEV: first, plans to increase censorship resistance with inclusion lists, etc.; second, to isolate validators from block production by using Attester Proposer Seperation and execution auctions; third, to achieve faster slots, shortening the slot time to 4 seconds.

The goal of the pledge part is to improve the current issuance curve, reduce the pledge threshold from 32 ETH to 1 ETH, and achieve single slot finality.  

The goal of the cryptography part is to use zkVM and other methods to achieve chain snarkification; maintain the security of Ethereum cryptography so that it can last for decades or even hundreds of years; and use MinRoot VDF and other methods to maintain strong randomness.  

As for the implementation methods of these goals, Justin divided these goals into two categories. The green part is completed in the form of gradual forks, and the red part should be completed simultaneously in an overall manner.  

Take snarkifacation (using zk-SNARKs technology to prove data or calculations) as an example. If you want to achieve real-time proving, you must make some structural adjustments in the system, including changes in hash functions, signature methods, serialization and Merkleization. The signature method needs to be able to generate and verify quickly, and serialization is required so that complex data structures can be transmitted and stored between nodes, and the serialized data is processed by Merkle Tree, so as to meet the needs of zero-knowledge proof for verifiable formatting and transformation of data, as well as efficient verification of status.  

 ZK-based Beam Chain 

In the past, Ethereum consensus has undergone a change from POW to POS, and in the Beam Chain mechanism, consensus will be further updated - fully ZK-based, that is, snark is applied to the entire consensus layer.  

Chain snarkification 

It should be emphasized that the snarkified part only exists in state transitions, but some basic-level calculations (logical calculations performed by the consensus mechanism before processing transactions or state transitions), network layers (communication and data transfer between nodes), cache management and performance optimization remain unchanged and are not affected by ZK.

What needs to be done for the implementation code of Beam Chain (e.g. the core logic and consensus algorithm code of Beam Chain written in Go or Rust) is to convert the code into a format that zkVM can understand. After the implementation code of Beam Chain is compiled into the code format of zkVM, zkVM can execute the code, read the external input of the blockchain, verify the legitimacy of the state transition process, and generate zero-knowledge proofs.

zkVM is an environment for executing zero-knowledge virtual machines, which can understand code in a specific format for the verification of zero-knowledge proofs. The process of compiling code into a format executable by zkVM may include converting high-level languages ​​(such as Go or Rust) into a low-level, intermediate format (such as 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 providing Risc-v zkVM.

Attestation snarkification

Another area where snarks are used is in aggregatable signatures, which is the process of compressing the signatures of multiple verifiers and witnesses into a single, verifiable proof.

We want post-quantum aggregate signature security (which is resistant to quantum attacks), so we expect to use hash functions here. Hash functions have post-quantum security levels and can be used as the basic components or building blocks of cryptographic systems to build cryptography. Using hash-based snarks, thousands of signatures can be compressed into a single proof. This is a post-quantum aggregate signature. Moreover, this post-quantum aggregate signature is infinitely recursive, and you can keep stacking and aggregating multiple aggregate signatures again to achieve higher compression efficiency, which is a huge improvement over traditional BLS signature aggregation.

In the past few months, snarked hash function technology has been significantly improved, and proofs can be quickly generated through a laptop, and proofs can be completed at about 2 million hash operations per second. This performance breakthrough makes post-quantum secure aggregate signature schemes more practical in reality and provides the possibility for efficient, quantum-resistant encryption.  

Not only that, the snarked Beam Chain compresses the originally complex verification, storage, and calculation processes, which enables a series of infrastructures such as libp2p, ssz, pyspec, and protocolguild that were not directly used in Beacon Chain.

Timeline Planning

In terms of timeline planning, Justin plans to develop specifications in 2025, build in 2026, and test 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 in South America.