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.

• Ethereum endgame assumes ZK-proving L1 blocks.

Source: https://twitter.com/vitalikbuterin/status/1741190491578810445.

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.

Multi-client systems & L1 Endgame

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.

Taiko’s Feasibility for Multi-Proofs

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.