Written by: Zoe, Puzzle Ventures

TL; DR

Since the competition among numerous public chains, the Danksharding in Ethereum's roadmap, and the second-layer solutions like op/zk, we have been continuously discussing the scalability of blockchain—what to do when a large number of users and funds come in? Through a series of upcoming articles, I want to show everyone a future vision, which consists of data acquisition, off-chain computation, and on-chain verification.

Trustless Data Access + Off-chain Computation + On-chain Verification

"Proof of Consensus" is an important part of this blueprint. This article discusses the significance of using zero-knowledge proof of consensus on the basis of Ethereum's PoS, including:

1. The importance of decentralization for EVM.
2. The importance of decentralized data access for web3 scalability.

Proving the full consensus of the Ethereum mainnet is a complex task, but if we can achieve the zkization of the consensus layer, it will help Ethereum's scalability while enhancing the robustness of the entire Ethereum ecosystem, reducing participation costs, and allowing more people to join.

1. Why is proving consensus layer important?

Using zk to verify Ethereum L1's consensus layer is meaningful in two major directions. First, it can compensate for the diversity of current nodes, enhancing the decentralization and security of Ethereum itself. Second, it provides the basis for the availability and security of various protocol layers in the Ethereum ecosystem facing more users, including cross-chain security, trustless data access, decentralized oracles, and scalability.

1. Perspective from Ethereum

For Ethereum to achieve its decentralization and robustness, it needs a diverse client environment. This means more people, especially ordinary users, running clients based on different code environments. However, requiring every user to run a full node is unrealistic because it requires a large amount of resources, and not many people can afford at least 16 GB+ RAM and Fast SSD with 2+TB, which are constantly increasing requirements.

The current goal is to achieve a light node that can provide the same level of trust as a full node (minimal trust) while having lower costs in terms of memory, storage, and bandwidth requirements. However, currently, light nodes do not participate in the consensus process, or only receive partial protection from the consensus mechanism (Sync Committee).

This goal is referred to as "The Verge" in Ethereum's roadmap.

Goal:verifyingblocks should be super easy - download N bytes of data, perform a few basic computations, verify a SNARK and you’re done— The Verge on Ethereum’s Roadmap

"The Verge" aims to bridge the client gap, with a key step being how to achieve a trustless light node that is as secure as today's full node, thereby enabling more people to actively participate in the decentralization and robustness of the network.

https://www.ethernodes.org/network-types

https://clientdiversity.org/

2. Perspective of Protocol Stacks on Ethereum

From first principles, we need to address the combination of on-chain data access and off-chain computation verification.

Currently, the use of on-chain data is relatively primitive and insufficient. In many cases, the data required for protocol adjustments is too complex to be computed on-chain, and obtaining data in a trustless manner is costly, requiring a large amount of historical data access and frequent digital calculations.

For individual users and projects, our ideal situation is to achieve decentralized, end-to-end trustless data transmission and read/write, with the goal of minimizing computational costs for future users while ensuring security, availability, and economic efficiency.

Specifically, this includes the following aspects:

1. Decentralized and trustless oracles: Current protocols use centralized oracles to avoid direct access to a large amount of historical data on-chain, increasing unnecessary trust costs and reducing composability.

2. Data read/write for protocols related to sensitive assets: For example, DeFi protocols need to make dynamic adjustments to some parameters during operation. Whether it is possible to access historical data and perform more complex calculations without trust, such as adjusting AMM fees based on recent market fluctuations, designing on-chain derivative trading price models and dynamic fluctuations, introducing machine learning methods for asset management, and adjusting borrowing interest rates based on market conditions.

3. Cross-chain security: Currently, light node solutions based on zk technology are superior in security, capital efficiency, statefulness, and diversity of information transmission. The current Succinct Telepathy cross-chain solution and Polehedra's cross-chain solution on LayerZero are both based on zk verification of light node block headers using the Sync Committee. However, the Sync Committee is not the Ethereum PoS consensus layer itself and has certain trust assumptions, leaving room for more comprehensive improvements in the future.

Currently, due to considerations such as economic costs, technical limitations, and user experience, developers often rely on centralized RPC servers, such as Alchemy, Infura, and Ankr, when using on-chain data.

2. Where is Blockchain Data? Trust Assumptions for Different Data Sources

There are two sources of computational data in the blockchain: on-chain data and off-chain data. Corresponding to the on-chain and off-chain directions for computation. For example, the demand for adjusting parameters of DeFi protocols mentioned earlier.

Data Access, computation, proof and verification

The reading, writing, and computation of on-chain and off-chain data have two significant characteristics:

1. To achieve decentralization and security, it is best to verify the data we obtain, i.e., "Don’t Trust, Verify."

2. Often involves many complex and expensive computational processes.

If suitable technical solutions are not found, the above two points will affect the availability of the blockchain.

We can illustrate different data acquisition methods through a simple example. Suppose you want to check your account balance, how would you do it?

One of the safest ways is to run a full node yourself, check the Ethereum state stored locally, and obtain the account balance from it.

Full Node Benchmark. Sync mode and client selection will affect the space requirements. Reference: https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/; https://docs.google.com/presentation/d/1ZxEp6Go5XqTZxQFYTYYnzyd97JKbcXlA6O2s4RI9jr4/mobilepresent?pli=1&slide=id.g252bbdac496_0_109)

However, the cost of running a full node yourself is very high and requires maintenance. To save trouble, many people may directly request data from centralized node operators. Although there is nothing wrong with doing so, similar to operations in Web2, and we have never seen these suppliers engage in any malicious behavior, it also means that we have to trust a centralized service provider, increasing the overall security assumption.

To solve this problem, we can consider two solutions: reduce the cost of running nodes and find a way to verify the credibility of third-party data.

Then why not just store the necessary data? In order to access data more efficiently, reduce trust costs, and independently verify data, some organizations have developed light clients, such as the Rust-based Helio (developed by a16z), Lodestar, Nimbus, and JavaScript-based Kevlar, among others. Light clients do not store all block data, but only download and store block headers—a "summary" of all block information. Light clients can independently verify the received data, so when you obtain data from a third-party data provider, you no longer need to fully trust the provider's data.

https://medium.com/coinmonks/ethereum-data-transaction-trie-simplified-795483ff3929

The main features of light nodes include:

• Ideally, light nodes can run on mobile or embedded devices.
• Ideally, they can have the same functionality and security guarantees as full nodes.
• However, light nodes do not participate in the consensus process, or only receive partial protection from the consensus mechanism, namely the Sync Committee.

The Sync Committee is a trust assumption for light nodes.

Before The Merge, starting from December 2020, the Beacon Chain underwent a hard fork called Altair, with the core purpose of providing consensus support for light nodes. Unlike PoS full consensus, a smaller dataset of validators (512) is selected at longer intervals (256 epochs, approximately 27 hours) using a random selection process.

Light clients such as Helios and Succinct are taking steps toward solving the problem, but a light client is far from a fully verifying node: a light client merely verifies the signatures of a random subset of validators called the sync committee, and does not verify that the chain actually follows the protocol rules. To bring us to a world where users can actually verify that the chain follows the rules, we would have to do something different.

How will Ethereum's multi-client philosophy interact with ZK-EVMs?, by Vitalik Buterin*

This is why we need to verify the entire consensus layer of Ethereum in order to usher in a more secure, more available, more diverse protocol, and widely adopted future. Currently, the best solution appears to be zero-knowledge (ZK) technology.

3. The Path to Prove Consensus Using ZK

To build a trustless environment, the issues of light node credibility, decentralized data access, and off-chain computation verification must be addressed. In these aspects, zero-knowledge proof is currently the most recognized core technology, including but not limited to underlying solutions such as zkEVM, zkWASM, other zkVM, and zk Co-processor.

Proving the consensus layer is an important part of this.

The PoS algorithm is very complex, and implementing it in a ZK manner requires a lot of engineering work and architectural considerations. We will first break down its components.

1. Key Steps in Consensus Formation in Ethereum 2.0

(1) Validator-Related Algorithms

This includes the following steps:

• Becoming a validator: Validator candidates need to send 32ETH to the deposit contract and wait at least 16 hours to several days or weeks for the Beacon Chain to process and activate them as formal validators. (Refer to FAQ - Why does it take so long for a validator to be activated)
• Exercising validation duties: Involves random number and block proof algorithms.
• Exiting the validator role: The way to exit as a validator can be voluntary or due to being penalized (slashed) for violations. Validators can initiate "exit" at any time, with a limit on the number of validators exiting each epoch. If too many validators attempt to exit simultaneously, they will be placed in a queue and still need to fulfill validation duties until they are processed. After successful exit, validators can withdraw staked funds after 1/8 of an eek.

(2) Random Number-Related Algorithms

• Each epoch contains 32 slots, and 2 epochs in advance are used for random grouping, dividing all validators into 32 committees to exercise duties in the current epoch, each responsible for consensus on each block.
• Each committee has two roles, a proposer and builders, randomly selected. This separates transaction ordering and block construction processes (see proposer/builder separation - PBS).

(3) Block Attestation and BLS Signature-Related Algorithms

• The signature part is the core of the consensus layer.
• The validation committee for each slot votes (using BLS signatures) and requires a 2/3 pass rate to build a block.
• In the Ethereum PoS consensus layer, BLS signatures use the BLS12–381 elliptic curve, pairing-friendly, suitable for aggregating all signatures, reducing proof time and size.
• In proof of work, blocks may undergo reorganization (re-org). After merging, the concept of "finalized blocks and safe heads" on the execution layer is introduced. To create a conflicting block, an attacker needs to destroy at least 1/3 of the total staked Ether; PoS is much more reliable than PoW.

https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer

In late June 2023, "Puzzle Ventures Evening Study" introduced the zkPoS of Hyper Oracle (using zk to verify the Ethereum full consensus layer). For details, please see zkPoS: End-to-End Trustless

(4) Others: Weak Subjectivity Checkpoints

One of the challenges faced by trustless PoS consensus proof is the selection of weak subjectivity checkpoints, involving social consensus based on social information. These checkpoints are revert limits because blocks before weak subjectivity checkpoints cannot be changed. See: https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/

Checkpoints are also a point to consider in the consensus layer zkization.

2. Tech Stacks to Prove Consensus Using ZK

In proving the consensus layer, proving signatures or other computations themselves are very expensive, but verifying zero-knowledge proofs is relatively cheap.

When choosing to use zero-knowledge proof for the consensus layer, protocols need to consider the following factors:

• What do you want to prove?
• What are the application scenarios after proving?
• How to improve the efficiency of the proof?

Taking Hyper Oracle as an example, for proving BLS signatures, they chose Halo2 instead of Circom used by Succinct Labs, for several reasons:

• Both Circom and Halo2 can generate zero-knowledge proofs for BLS signatures (BLS12–381 elliptic curve).
• Hyper Oracle does more than just zkPoS; its core product is a programmable on-chain zero-knowledge oracle. It directly faces users with zkGraph, zkIndexing, and zkAutomation, and also uses zkWASM virtual machine to verify off-chain computations. Although Circom is easier for engineers to use, it has poor compatibility and cannot ensure that all logic can be used.
• Circom-pairing compiles into R1CS, which is incompatible with the Plonkish constraint system of zkWASM and other circuits, while Halo2 Pairing circuits can be easily integrated into zkWASM circuits; R1CS is also not ideal for proof batching.
• From an efficiency perspective, Halo2-pairing generates smaller BLS circuits, shorter proof times, lower hardware requirements, and lower gas fees.

https://mirror.xyz/hyperoracleblog.eth/lAE9erAz5eIlQZ346PG6tfh7Q6xy59bmA_kFNr-l6dE

Another key point in proving the consensus layer using zero-knowledge is recursive proof—proofs of proofs—packaging previous events into a proof.

If there is no recursive proof, the proof size will eventually be O(block height), i.e., each block attestation and its corresponding zkp. Through recursive proof, apart from the initial state and final state, for any number of blocks, we only need a proof size of O(1).

Verify Proof N and Step N+1 to get Proof N+1, i.e. you know N+1 pieces of knowledge, instead of verify all N Steps separately.

Returning to the initial goal, our solution should be aimed at "light clients" with computational and memory limitations. Even if each proof can be verified in a fixed time, the verification time will become very long as the number of blocks and proofs accumulates.

3. The End Game: Diversified Level 1 zkEVM

The goal of Ethereum is not only to prove the consensus layer but also to achieve the zero-knowledgeization of the entire Layer 1 virtual machine through zkEVM, and ultimately to realize diversified zkEVM to enhance the decentralization and robustness of Ethereum.

For these issues, Ethereum's current solutions and roadmap are as follows:

"Lightweight" - Smaller Memory, Storage, and Bandwidth Requirements

• Currently achieved through light nodes storing and verifying only block headers.
• Future developments also require further efforts in verkle tree and stateless clients, involving improvements to the mainnet data structure.

"Trustless" - Achieving Minimal Trust Equivalent to Full Nodes

• Basic light node consensus layer has been implemented, namely Sync Committees, but this is only a transitional solution.
• Using SNARK to verify Ethereum Layer 1, including verifying Verkle Proof on the execution layer, verifying the consensus layer, and SNARK-ifying the entire virtual machine.
• Level 1 zkEVM is used to achieve the zero-knowledgeization of the entire Ethereum Layer 1 virtual machine and to realize diversified zkEVM.

Potential Risks

Ideally, when entering the era of zk, we need multiple open-source zkEVMs—different clients have different zkEVM implementations, and each client waits for proof compatible with its own implementation before accepting a block.

However, multiple proof systems may face some issues because each proof system requires a peer-to-peer network, and a client that only supports a certain proof system can only wait for the corresponding type of proof to be recognized by its verifier. Two main challenges that may arise include "latency challenge" and "data inefficiency," with the former mainly due to slow proof generation, leaving a time gap for malicious actors to create temporary forks when generating proofs for different proof systems, and the latter because you need to generate multiple types of zk proofs, requiring the storage of original signatures. Although theoretically, the advantage of zkSNARK itself is the ability to delete original signatures and other data, there are some contradictions that need to be optimized and resolved here.

4. What is the Future?

To bring more users to web3, provide a smoother experience, create higher availability, and ensure application security, we must build infrastructure for decentralized data access, off-chain computation, and on-chain verification.

Proving the consensus layer is an important part of this. In addition to Ethereum PSE and the previously mentioned zkEVM layer2, some protocols are using zero-knowledge proof consensus to achieve their application goals, including Hyper Oracle (Programmable zkOracle Network) planning to use zero-knowledge proof for the entire consensus layer of Ethereum PoS to obtain data; Succinct Labs' Telepathy is a light node bridge that achieves cross-chain communication by verifying Sync Committee consensus and submitting state validity proof; Polyhedra was originally a light node bridge, but now claims to have achieved full node full consensus zk proof using devirgo.

In addition to cross-chain security and decentralized oracles, this off-chain computation + on-chain verification approach may also be involved in fraud proof in Optimism rollup, integrating with OP L2; or in intent-based architecture, providing on-chain proofs for more complex intent structures, and so on.

Here, we are discussing not only the off-chain ecosystem surrounding Ethereum but also the broader market beyond Ethereum.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。