Towards the Ethereum L1 Endgame: Taiko's Multi-Proof Roadmap

2024.01.23

Towards the Ethereum L1 Endgame: Taiko's Multi-Proof Roadmap

Taiko believes that multi-proofs in ZK can lay the foundation for SNARKed node diversity in future Ethereum L1.

2024.01.23 - 12:23:16

Navigating Web3 tides with focused insights

Taiko believes that multi-proofs in ZK can lay the foundation for SNARKed node diversity in future Ethereum L1.

Author: Taiko

Translation: Frank, Foresight News

Recently, we shared a detailed article titled "Why multi-prover matters," explaining the importance of multi-proofs and listing SGX as one of the options for multi-proof systems.

That article was inspired by our X Space discussion with Vitalik and his subsequent blog post, which introduced Taiko's overarching roadmap on multi-proof: its relationship to Ethereum’s endgame, our vision, and how we plan to achieve it.

We believe that multi-proof in ZK can be translated into using multi-SNARKs + multi-client—using multiple ZK-SNARK proofs across different Ethereum client implementations—which would lay the foundation for diverse SNARKed nodes in future Ethereum L1.

To provide a simple rationale for multi-proof, two points should be emphasized:

Multi-proof hedges against vulnerabilities and risks in both client implementations and proof systems. Therefore, even if one proof is compromised, it is unlikely that others would allow the exact same vulnerability to be exploited;
Ethereum’s endgame assumes the use of zero-knowledge (ZK) proofs to verify L1;

Similar to Ethereum's multi-client approach, this method has repeatedly saved the network from collapse, demonstrating that L1 blocks require a multi-validation strategy. For both ZK and non-ZK scenarios, this implies the need for multiple clients and different proving systems.

Multi-Client Systems and the L1 Endgame

As described by Vitalik in his article "What might an 'enshrined ZK-EVM' look like?," there are two approaches to a multi-client system: "open" and "closed."

In a closed multi-client system, a fixed set of known proofs is whitelisted within the protocol to generate proofs. According to Vitalik’s classification, all ZK L2s are closed because they only accept proofs from their own implementations;
In an open multi-client system, proofs reside "out-of-block" and are verified separately by individual nodes, allowing any user to validate blocks using whatever client they prefer;

If users need to verify a block, the simplest implementation involves either re-executing the block by running the corresponding node locally or requesting validity proofs from known provers. If a sufficient number of proofs meeting "whitelist" criteria are received, the block is considered valid. But what kind of zero-knowledge proof (ZKP) should we use when no such whitelist-compliant ZKP exists and we want to avoid full re-execution?

According to Vitalik’s vision, this issue is resolved outside the protocol through social (or cryptoeconomic) consensus:

At the consensus layer, we add a validation rule: a block is accepted only when nodes see valid proofs for every state transition within it. The proof must be a ZK-SNARK proving that the transaction_and_witness_blobs linkage forms a serialized sequence of (Block, Witness) pairs, and that executing the block based on pre_state_root and Witness (i) is valid and (ii) produces the correct post_state_root. Potentially, nodes may choose to wait for M-of-N types of proofs.

Imagine an honest Builder who has a type-1 block and wants to provide validity; several options already exist at the L2 level, such as Polygon, zkSync, and Scroll.

Assuming their ZK-EVMs have evolved to type-1 and are reputable and battle-tested, the Builder can select among these available proving systems. Those verifying his block will run corresponding verification software, ideally generating multiple proof types and undergoing multiple validations. Given the same L1 chain specification, if any validator disagrees, block validation becomes a consensus issue, and the open system reaches agreement via consensus.

Proving systems gain influence by convincing users to trust them—not by persuading protocol governance processes.

According to Vitalik, this means the ZKP ecosystem opens up to direct marketization. With proper incentives, existing L2 implementations could compete in the L1 proof market.

Taiko's Feasibility in Multi-Proof

In the Taiko protocol, a Proposer must find a Prover to propose a block, and the designated Prover must deposit TKO as collateral to ensure the correctness of the delivered proof. The Taiko protocol does not dictate how Proposers find or compensate Provers—they could even meet in person and transact in cash.

Thus, our supply chain operates like a free market, where Proposers can choose any Prover they prefer.

Beyond economic advantages, several technical features make Taiko an ideal candidate for a multi-client system:

Taiko is a type-1 ZK-EVM, offering two key benefits: First, in terms of execution diversity, existing EVM implementations (such as Geth, Besu, Reth, etc.) can be directly applied to L2. Second, to test the feasibility of L1-based designs, we need a standardized ZK-EVM for open multi-client validation, since validators must reach consensus on identical state transitions. In this context, a type-1 ZK-EVM is the most suitable choice because it strictly adheres to Ethereum specifications. Regarding rollup-specific logic, Vitalik also mentioned supporting modifications to ZK-EVMs via precompiles, and leveraging these precompiles is sufficient to support Taiko’s BBR (Based Booster Rollup) design;
Taiko publishes data availability directly on Ethereum, unlike some L2s exploring alternative data availability solutions. As long as data is published on L1, Taiko can easily adapt to Vitalik’s proposed implementation, which introduces ZKEVMClaimTransaction to cover state transitions, proofs, and data availability;

Taiko operates across multiple proving systems, and its current testnet already supports PSE’s ZK-EVM, SGX, and Reth. The infrastructure is designed to accommodate multiple execution clients and proving systems, which will be discussed further in the next section. Built upon this foundation, Taiko’s approach to zero-knowledge proofs centers around modular compilation.

A Modular and Open Roadmap

Modularity

In the context of zero-knowledge proofs (ZKP), considering multi-client requirements, Taiko leverages modern compilers to obtain general-purpose intermediate representations such as RISC-V or WASM. These instructions are then converted into arithmetic representations (AIR or PIL) compatible with various proving systems, and finally encoded into execution traces using different SNARKs.

In short, this workflow represents the most viable approach in a multi-proof system, as it fully leverages advantages from both sides. During node compilation, modern compilers offer the following benefits:

Node upgrades are decoupled from proving circuits—there is no need to redesign circuits for new EIPs or hard forks; simply keeping the source code updated suffices;
Code optimizations come freely from toolchains like LLVM;
Cross-compilation enables greater diversity; for example, Taiko compiling Geth or Reth into RISC-V or WASM instruction sets already yields four distinct proving paths;

SNARKs compilation is a key focus for Taiko’s future development. Note that this approach is not limited to a single ZK protocol during arithmeticization (e.g., PLONK, R1CS) and backend encoding (e.g., Halo2, eSTARK, Supernova). In contrast, monolithic ZK-VM/EVMs implement backends tailored to specific ZKPs. As more projects adopt each other's components for performance gains, entire tech stacks may become modular.

Given the rapid pace of ZKP research, flexibility is more important than immediately implementing the latest results. To maintain agility, Taiko collaborates with projects like Powdr Labs and Risc Zero on cross-compilation pipelines and pursues maximum modularity.

For technically proficient readers, here are specific benefits:

We can optimize compilers to target different backends—for instance, favoring high-degree gates or utilizing more lookup arguments;
Accelerated circuits for hash functions like Keccak and Poseidon can be implemented as reusable libraries;
We can incrementally add ZK capabilities (e.g., LogUp) to the language and enable corresponding backend support;
Integrating new ZK backend frameworks becomes faster. In many research-oriented ZK projects, only proof-of-concepts are developed in code, making production deployment challenging. By offloading heavy lifting to the compiler, we can readily apply early-stage frameworks;
Existing backend circuits, such as PSE ZK-EVM components written in Halo2, can still be reused via direct invocation;

Through collaborative efforts, Taiko has integrated Risc Zero’s zeth and ZK-VM into its development pipeline and added an SGX backend. Taiko engineers are also integrating Powdr into the multi-proof system, developing PIL languages and libraries, optimizing compilation, adding more backends, and performing low-level acceleration work. At the hardware level, Taiko’s Zero-Knowledge Acceleration Layer (ZAL) aims to standardize collaboration between proving systems (Halo2, Arkworks, Risc Zero, Polygon, etc.) and acceleration libraries (CPU, GPU, FPGA, etc.).

Openness

The greater the number of clients, proving systems, and integrated backends, the higher the degree of openness. Therefore, Taiko strives to bring together the entire community. The Taiko team has a long history of collaboration with other projects, such as working with PSE on ZK-EVM and Risc Zero.

Now, by building a more modular ZK stack, Taiko can effectively abstract APIs for broader adoption and integration. Taiko will serve as a platform to ship proving systems into production and test them in real-world on-chain environments. Taiko sincerely invites all projects to join hands in advancing better zero-knowledge technology.

Taiko Stack

A scalable and flexible infrastructure is critical for Taiko’s multi-proof paradigm.

The source of ZK validity proofs lies in the node’s execution trace and storage proofs, which are used to construct witnesses and public inputs. It’s important to note that witnesses are proof-specific, while public inputs are protocol-related. Having robust infrastructure for witness generation is essential. Therefore, we use a lightweight host to extract execution traces from multi-clients and convert them into multiple witness formats for respective proving systems.

On the proving side, the design supports both modular and monolithic stacks, while extracting the same public inputs from the target node (currently Geth).

In the future, if execution trace formats are compatible, Geth as a Taiko node could be replaced by another client. Additionally, the lightweight node currently running on the proving system (currently Reth) could be substituted by any implementation capable of accepting assembly-like input.

Key Takeaways

Taiko believes multi-proof = multi-client + multi-SNARKs (and TEEs like SGX);
The Taiko protocol is well-suited for a multi-client system due to its open multi-proof supply chain, type-1 execution, and data availability posted on L1;
Taiko envisions a modular and open multi-proof architecture, collaborating with Powdr Labs on cross-compilation of clients and ZKPs, and with Risc Zero to run Taiko execution on their ZK-VM and TEEs. Taiko will continue working with PSE to improve the ZK-EVM project;
Taiko’s flexible infrastructure supports both modular and monolithic ZKP stacks;