TL;DR

ZK fraud proof is a validity proof of L2 block transition.
ZK fraud proof enables the challenge of a malicious sequencer in a single transaction, significantly reducing gas costs and time compared to traditional fraud proofs.
To generate a ZK fraud proof, we emulate the L2 Geth in an instruction set architecture (ISA) and prove the execution result using zkVM.
We choose WebAssembly (Wasm) - a widely adopted open-standard ISA and prove the execution of Wasm code using zkWasm, the state-of-the-art zkVM for Wasm developed by Delphinus Lab.
Directly compiling L2 Geth to Wasm with Go proved challenging, necessitating modifications to L2 Geth to support Wasm compilation.
Further, we introduced zkGo - a minimum modified Go compiler to produce Wasm code compatible with ZK prover.
As a result of these modifications, the execution of the compiled L2 Geth Wasm code can now be proven using zkWasm.

Motivation

Optimistic Rollup stands out as a widely adopted Layer 2 solution designed to scale Ethereum. This approach optimistically posts L2 transactions and their execution outcomes on the Ethereum mainnet, substantially reducing the costs associated with on-chain execution. To ensure the correctness of these execution results, Optimistic Rollup employs a mechanism that permits anyone to challenge the outcome with a fraud proof. This entails an interactive on-chain dispute game between the challenger and the sequencer. The objective is to pinpoint the specific instruction where disagreement exists between the two parties and then replay that instruction on-chain to determine the rightful winner. This approach significantly lowers the expenses of generating validity proofs for L2 transactions, as seen in other popular rollup solutions like ZK Rollup.

However, the interactive nature of on-chain dispute games often involves multiple rounds of on-chain interactions (for example, up to 32 interactions in a 4-billion-instruction game). Consequently, considering the worst cast attack scenarios, Optimistic Rollup typically requires 7-days challenge period) before finalizing an L2 transaction. Moreover, when Ethereum's gas prices are high, the multiple interactions within the dispute game can incur substantial gas costs.

To address these challenges, a proposal known as ZK fraud proof has emerged to harness the benefits of both Optimistic Rollup and ZK Rollup. The fundamental concept behind ZK fraud proof is to replace the multi-interaction dispute game with a single ZK fraud proof. This proof validates the L2 block transition in a single transaction, resulting in significant time and gas cost savings compared to the dispute game.

However, proving an L2 block transition in ZK fraud proof is no simple task, and it is even more intricate than Type 1 zkEVM. The complexity arises from the need to emulate the L2 execution engine written in a higher-level language, such as L2 Geth in Go, within a lower-level instruction set architecture (ISA). This ISA can produce lengthy traces, sometimes comprising billions of instructions, and demand substantial memory resources (approximately 64MB or more) that may exceed the limit of the prover supported. The advantage of proving approach lies in its maximal reutilization of the battle-tested execution engine code such as Geth. Due to characteristics, this approach is sometimes referred to as Type 0 zkEVM.

In this article, we aim to provide an update on our progress in proving the Optimism fault-proof program (op-program) using WebAssembly (Wasm) as the chosen ISA and zkWasm as the ZK virtual machine (zkVM).

What is OP-Program?

Op-program serves as the default implementation of the Optimism fault-proof program, consisting of two essential components:

op-program-client: This component is responsible for accepting the parameters of the L2 block and then replaying the block through a minimally modified version of Geth (L2 Geth). Following execution, it determines the correctness of a claim regarding the execution result.
op-program-host: This component acts as a host environment for op-program-client, providing the essential data required for op-program-client to replay a block. This data encompasses block headers, block bodies, transaction receipts, and trie nodes pertaining to the state tree in both Ethereum L1 and L2.