Quickly read Justin’s new proposal for the Ethereum consensus layer, Beam Chain

Written by: Tia, Techub News

At the Mainstage of Devcon in Thailand yesterday, Ethereum researcher Justin Drake completed the launch of the Beam Chain proposal in the form of a speech. Beam Chain is Justin's proposal to redesign the consensus layer of Ethereum. This proposal is a further upgrade of Beacon Chain to further move towards the ultimate vision of Ethereum. This article will give you a quick overview of the goals of the Beam Chain proposal improvement 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: execution layer, blob data layer, and 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 application. The blob data layer is responsible for storing large amounts of data, involving long-term data storage required by applications. These two layers are the layers that interact directly with applications, and any changes will directly affect the compatibility of these layers.

The consensus layer is mainly responsible for ensuring data consensus among the entire network nodes and does not directly process the status or data of the application. This indirection makes it relatively easier to introduce innovations and upgrades without having a direct impact on applications. Therefore, consensus layer improvements like the Beam Chain proposal can provide room for innovation without destroying the compatibility of the front- end application layer.

Moreover, the Beacon Chain was designed 5 years ago and is already very old. After five years, the market has fully understood some of the mistakes of Beacon Chain, and its understanding of MEV has also deepened. It coincided with a breakthrough in SNARK technology. Therefore, riding on the breakthrough, a series of repairs were made to the Ethereum consensus layer.

What 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: one is to use inclusion lists to increase censorship resistance; the other is to use Attester Proposer Seperation and auction execution to isolate validators from block production; the third is to achieve Faster slot, reducing slot time to 4 seconds.

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

The goals of the cryptography part are to use zkVM and others to achieve snarkification of the chain; to maintain the security of Ethereum cryptography so that it can last for decades or even centuries; and to maintain strong randomness using MinRoot VDF and others.

Regarding how to achieve these goals, Justin divided these goals into two categories. The green part should be completed in the form of gradual forks, and the red part should be completed simultaneously in a holistic manner.

Taking 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 hash functions, signature methods, and Changes in serialization and Merkleization. The signature method needs to be able to quickly generate and complete verification, and needs to be serialized so that complex data structures can be transmitted and stored between nodes, and the serialized data will be processed by Merkle Tree to meet the requirements. Zero-knowledge proofs require verifiable formatting and transformation of data, as well as efficient verification of state.

ZK-based Beam Chain

In the past, the Ethereum consensus has experienced changes from POW to POS, and in the Beam Chain mechanism, the 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 done by the consensus mechanism before processing transactions or state transitions), network layer (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 (such as 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 zkVM code format, zkVM can execute these codes, read the external input of the blockchain, verify the legality of the state transition process, and generate zero-knowledge proofs.

zkVM is an environment that executes a zero-knowledge virtual machine that understands code in a specific format for verification of zero-knowledge proofs. The process of compiling code into a zkVM executable format may involve converting a high-level language (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 aggregate signatures (aggregatable signatures), which is the compression process of the signatures of multiple verifiers and witnesses (attesters), aggregating a large number of signatures into a single, verifiable proof.

We want to have post-quantum aggregate signature security (resistant to quantum attacks), so hash functions are expected to be used here. Hash functions have a level of post-quantum security and can be used as a basic component or basic module of a cryptographic system to build cryptography. Using hash-based snarks, thousands of signatures can be compressed into a proof. This is the post-quantum aggregate signature. Moreover, this kind of post-quantum aggregated signature is infinitely recursive. You can continuously superimpose and aggregate multiple aggregated signatures again to achieve higher compression efficiency. Compared with traditional BLS signature aggregation, it has been greatly improved.

In the past few months, snark-based hash function technology has improved significantly, allowing proofs to be generated quickly from a laptop and capable of completing approximately 2 million hash operations per second. This performance breakthrough makes post-quantum secure aggregated signature schemes more practical in reality, providing the possibility for efficient, quantum-resistant encryption.

Not only that, the snarked Beam Chain compresses the original complex verification, storage, and calculation processes, which enables the realization of a series of infrastructure such as libp2p, ssz, pyspec, protocolguild, etc. that could not be directly used in the 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.