This article is written by Taiko’s ZK Engineer CeciliaZ_.

A while ago, we shared a detailed article titled “Why multi-prover matters,” explaining the significance of multi-proofs and focusing on SGX as one of the options for multi-proofs. This article is inspired by our X (Twitter) space with Vitalik and the blog post he published subsequently, which presents Taiko’s general roadmap on multi-proofs: how it relates to the endgame, what our vision is, and how we will get there.

In our view, multi-proofs in ZK translate to multi-clients compiled with multi-SNARKs, which will lay a foundation for SNARKed client diversity in the future Ethereum L1. To provide a very brief reasoning for multi-proofs, we should mention two points:

• The multi-proofs approach can hedge the risk of bugs and vulnerabilities in client implementation and proving systems. Then, in case of a bug, even if one proof is broken, others will unlikely allow the exact same vulnerability to be exploited.

• The Ethereum endgame assumes ZK-proving L1 blocks.

Similar to Ethereum’s multi-client approach, which has saved the network from downfall several times, proving L1 blocks will require a multi-proof approach. That, for both ZK and non-ZK scenarios, means multi-clients + various proving systems.

As Vitalik described in his article “What might an “enshrined ZK-EVM” look like?”, there are two approaches to multi-client systems: “open” vs. “closed.”

In a closed multi-client system, a fixed set of proofs is known within the protocol and “whitelisted” to generate proofs. All ZK L2s are “closed” following his categorization because they only accept their own implementation of proofs.

In an open multi-clients system, proofs are placed “outside the block” and verified by clients separately. Individual users would use whatever client they want to verify blocks.

In a naive case, they would re-execute the block using the desired client, or they can query for validity proof for the execution from some provers. The user will be convinced if more than the expected number of valid proofs is seen. However, if there is no “whitelisted” ZKP and we want to avoid re-execution, which ZKP should we actually use? In Vitalik's vision, this is solved by out-of-protocol social (or crypto-economic) consensus.

On the consensus layer, we add a validation rule that a block is only accepted once the client has seen a valid proof for each claim in the block. The proof must be a ZK-SNARK proving the claim that the concatenation of transaction_and_witness_blobs is a serialization of a (Block, Witness) pair, and executing the block on top of the pre_state_root using the Witness (i) is valid, and (ii) outputs the correct post_state_root. Potentially, clients could choose to wait for an M-of-N of multiple types of proof.

Imagine an honest builder with a type-1 block who wants to provide validity; several options are already available from the L2s, such as Polygon, zkSync, and Scroll. Assuming that their ZK-EVMs have evolved to type-1, and they are reputable and battle-tested. The builder will then choose from these available proof systems, while whoever verifies his block will run the corresponding verification software. Preferably, multiple types of proofs are created, and multiple verifications are passed. Given the same L1 chain specifications and if any verifiers disagree, it becomes a consensus problem.

Proof systems would gain influence by convincing users to trust them, and not by convincing the protocol governance process.

According to Vitalik, this would mean that the ecosystem ZKP is being opened for direct marketization. The existing L2 implementations could potentially compete for the L1 proof market if they are incentivized.

In the Taiko protocol, a proposer must find a prover to propose a block, and the assigned prover will deposit a TKO bond to guarantee proof of delivery. Taiko does not dictate how proposers find and compensate provers, so they may even meet in person and transact with cash. As a result, our supply chain operates as a free market. Proposers can choose any prover(s) they prefer.

Besides economic advantage, a few more technical features make Taiko an ideal fit for a multi-client system:

• Taiko is a type-1 ZK-EVM, which has two benefits:

  • For execution diversity, existing EVM implementations (Geth, Besu, Reth, …) can be directly brought to L2.

  • To test the L1 enshrined design, we need a standardized ZK-EVM for open multi-client verification, since verifiers need to check against the same transition to reach consensus on their validation results. In that case, type-1 ZK-EVM would be the best fit because it clearly follows Ethereum Specs. For rollup-specific logic, Vitalik also mentions how ZK-EVM can be modified through precompile support, and it will be sufficient to leverage these precompiles to support Taiko’s BBR (Based Booster Rollup) design.

• Taiko posts data on Ethereum, unlike some L2s that explore alternative data availability options. As long as data is posted to L1, Taiko can easily adapt to Vitalik’s implementation proposal, which presented ZKEVMClaimTransaction to cover state transition, proof, and data availability.

• Taiko works on multiple proof systems. The existing testnets already support PSE's ZK-EVM, SGX, and Reth. The infrastructure is configured to accommodate multiple execution clients and proof systems, which will be discussed in the last section. Building upon this infrastructure, our position in ZKP will revolve around modular compilation.

Taiko’s multi-prover is all about modularity and openness.

Given multiple clients in the context of ZKP, we leverage modern compilers to obtain general-purpose assemblies such as Risc-V or WASM. These instructions are then translated into arithmetizations for various proof systems (AIR or PIL), and the arithmetized execution trace is ultimately encoded with different SNARKs.

Execution Clients -> Assembly Languages -> Arithmetizations -> SNARKs    
             multi-clients           |              multi-proofs

In short, this pipeline is the most feasible for a multi-proof system because it leverages the best of the two worlds. During the client compilation, modern compilers give us the following benefits:

• Client upgrades are agnostic to the proofs because there’s no need to implement circuits for the latest EIPs or hard forks; we only need to keep the source code up-to-date.

• We get code optimization for free from toolchains like LLVM.

• Cross-compilation yields more diversity; given the above example, we have Geth or Reth compiling to RICS-V or WASM instructions, which already have four sets of proofs.

The SNARKs compilation is our emphasis moving forward. Note that arithmetization methods such as PLONK and R1CS encoding with backends like Halo2, eSTARK, or Supernova don’t limit us to one single ZK protocol, whereas *monolithic* ZK-VM/EVMs commit to specific ZKPs for backend implementation. As more projects adopt each other’s components for better performance, the monolithic tech stack might become modularized. The ZKP research field is moving so fast that flexibility matters more than directly implementing the latest results. To stay flexible, we collaborate with projects like Powdr Labs and Risc Zero on their cross-compilation pipeline, achieving modularity as much as possible. For tech-savvy readers, here are specific benefits:

• We can apply optimizations to compilers to target different backends, such as favoring high-degree gates or using more lookup arguments.

• Accelerated circuits like the keccak and Poseidon hash functions can be implemented as libraries.

• We may incrementally add ZK features such as LogUp to the language and enable corresponding backend support.

• Integrating new ZK frameworks for backends becomes faster. In some research-oriented ZK projects, only the proof of concept is developed in code, which makes them challenging to use in production. By having the compiler do the heavy lifting, we can easily apply early-stage frameworks.

• Existing backend circuits, such as PSE ZK-EVM components written in Halo2, may still be reused via direct invocation.

In a collaborative effort, Taiko has already integrated Risc Zero’s zeth and ZK-VM while developing an additional SGX backend for it. Taiko's engineers will also integrate Powdr into our multi-proofs system, develop the PIL language and library, optimize compilation, add more backends, and perform general low-level acceleration. At the hardware level, our ZK Acceleration Layer (ZAL) aims to standardize cooperation between proof systems (Halo2, Arkworks, Risc Zero, Polygon, etc.) and accelerator libraries (CPU, GPU, FPGA, etc.).

The more clients, proving systems, and integrated backends – the better, so we strive to bring the entire community together. Our team has a long-standing history working with others, for example, PSE on the ZK-EVM and Risc Zero. Now, by constructing a more modularized ZK stack, we can effectively work on abstracting APIs for better generalizations and integration. Taiko will serve as a gateway for shipping proof systems in production and battle-testing them on-chain. We wholeheartedly invite all projects to join us for a better ZK.

A scalable, flexible infrastructure is essential for our multi-proofs paradigm. The source ingredient of a ZK validity proof is the client's state trace and storage proofs, which are used to construct the witness and public input. Note that the witness is proof-specific, while public input is protocol-wise. It’s important to have a robusgt infrastructure to handle witness generation. Hence, we use a lightweight host to fetch traces from multi-clients and feed traces to multi-provers. On the prover end, the design supports modular and monolithic stack while we extract the same public input from the targeted client (currently Geth).

In the future, Geth as the Taiko node can be replaced by another node if the trace format is compatible. Additionally, the light client that runs on proof systems (currently Reth) can also be replaced by any implementation that compiles to an accepted assembly language.

• We believe that multi-proofs = multi-clients + multi-SNARKs (and TEEs like SGX).

• Taiko protocol is well-fit for the multi-client system because it has an open multi-proof supply chain with type-1 execution, which posts data availability on L1.

• Taiko envisions a multi-proof architecture with modularity and openness. We work with Powdr Labs to leverage cross-compilation with clients and ZKPs, and collaborate with Risc Zero to implement Taiko’s execution on their ZK-VM and TEEs. We will also continue our efforts with PSE to improve the ZK-EVM project.

• Taiko's flexible infrastructure accounts for modular and monolithic ZKP stacks.

Explore open positions on our job board.

Get the latest from Taiko:

• Website: https://taiko.xyz.

• Discord: https://discord.gg/taikoxyz.

• GitHub: https://github.com/taikoxyz.

• Twitter: https://twitter.com/taikoxyz.

• Community forum: https://community.taiko.xyz.

• Youtube: https://www.youtube.com/@taikoxyz.

Contribute to Taiko on GitHub and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the contributing manual.