Written by: Tia, Techub News
At the Mainstage of Devcon in Thailand yesterday, Ethereum researcher Justin Drake made a speech to launch the Beam Chain proposal. 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 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: 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 application. The blob data layer is responsible for storing large amounts of data, involving long-term data storage required by the application. These two layers are the layers that interact directly 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 easier 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.
Moreover, 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 a deeper understanding of MEV. Coincidentally, SNARK technology has also made a breakthrough, so taking advantage of 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, which are mainly related to MEV: one is to increase censorship resistance through inclusion lists, etc.; the second is to isolate validators from block production through Attester Proposer Seperation and execution auctions, etc.; the third is to achieve faster slots and shorten the slot time to 4 seconds.
The goal of the staking part is to improve the current issuance curve, reduce the staking threshold from 32 ETH to 1 ETH, and achieve fast single slot finality.
The goal of the cryptography part is to achieve chain snarkification using zkVM, etc.; maintain the security of Ethereum cryptography so that it can last for decades or even hundreds of years; and maintain strong randomness using MinRoot VDF, etc.
As for how to achieve these goals, Justin divides them into two categories: the green part is completed in a step-by-step manner, 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 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-ized Beam Chain
In the past, Ethereum consensus has undergone a change from POW to POS, and in the Beam Chain mechanism, the consensus will have a further update - fully ZK-ized, that is, applying snark to the entire consensus layer.
Chain snarkification
It should be emphasized that the snarkified part only exists in the state transition, but some basic-level calculations (logical calculations performed by the consensus mechanism before processing transactions or state transitions), the 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 (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 that 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 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. Currently, there are seven companies providing Risc-v zkVM.
Attestationsnarkification
Another part that uses snark is aggregatable signatures, which is the compression process of signatures from multiple validators and witnesses, aggregating a large number of signatures into a single, verifiable proof.
We want post-quantum aggregate signature security (to resist 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 basic modules of cryptographic systems to build cryptography. Using hash-based snarks, thousands of signatures can be compressed into one proof. This is the post-quantum aggregate signature. Moreover, this post-quantum aggregate signature is infinitely recursive. You can continuously superimpose and aggregate multiple aggregate signatures again to achieve higher compression efficiency, which is a great improvement over traditional BLS signature aggregation.
Snarked hash function technology has improved significantly in the past few months, 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 originally complex verification, storage, and calculation processes, which enables a series of infrastructures that were originally not directly used in the Beacon Chain, such as libp2p, ssz, pyspec, protocolguild, etc.
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.
