How to Develop ZK Fraud Proof with RISC0

What is ZK Fraud Proof

In traditional Optimistic Rollup, Fraud Proof is used to resolve disputes for disputed blocks. However, due to the challenge period and the need to reserve time for on-chain interactions, it takes about seven days to confirm disputed blocks. This is unacceptable for users and developers. In ZK Rollup, all off-chain blocks need to submit relevant commitments and proofs to ensure their validity. This allows for immediate block confirmation, but the computational and storage costs are much higher than OP Rollup.

Can we combine the efficiency of both to solve the problem of disputed blocks? The answer is yes, and this is ZK Fraud Proof. For ordinary off-chain blocks, their validity is assumed by default. However, when a dispute arises, the validity proof of the off-chain block is used to accelerate the dispute resolution process.

zkVM in RISC0

Guest Program

Refers to the part in zkVM that needs to be proven. It receives input from the host and can output in two ways:

• Using the env::commit method to commit public outputs to the journal.
• Using the env::write method to send private outputs to the host.

Each method in the guest program is written in Rust, compiled into an ELF binary before execution, and proves the execution trace corresponding to each method.

Host Program

Refers to the untrusted part in zkVM, capable of loading guest programs and providing input to them as needed. The host sets up the zkVM environment (ExecutorEnv) and handles input/output during execution. It is also responsible for building and running the executor and prover.

Workflow of zkVM

1. The host inputs shared private data into ExecutorEnv, builds the zkVM environment, executor, prover, etc.
2. The guest reads input information, commits public outputs to the journal, or sends private outputs to the host.
3. The host builds the prover, completes the proof by generating a receipt from the proving ELF binary. The receipt consists of two parts: a proof of the correctness of the receipt and the public commitment record of the proof, i.e., the journal.
4. The verifier verifies the receipt to determine its validity.

Integration with OP Stack

If we want to use zkVM to implement zk Fraud Proof on OP Stack, how should we design it? For the validity proof of state transitions, we need to verify two aspects:

• Correct program execution (introducing zk clients): In zkVM, we prove the state transition in the L2 block.
• Valid program input (commitment to pre-state and tx list using cryptographic commitment): By executing the derivation from L1 to L2 in zkVM, we prove the source of transactions used to produce new L2 blocks.

Approach

For optimizing fraud proof, we can choose from two different approaches:

1. Retain the bisection strategy of traditional fraud proof, i.e., interactively determine the disputed opcode or instruction and submit its validity proof for verification.
2. Skip the interactive bisection step and directly prove the validity of the disputed block.

System Design

zkVM Guest Program

Acts as the role of op-program in Optimism, responsible for calculating state transitions. It mainly completes the functions of block derivation and block proof in zkVM.

In the block derivation process, L1 block sequences and their corresponding transactions are inputted. We then execute the following steps to obtain the state of L2 (hash commitment of L2 transaction sequence):

• Extract calldata from relevant transactions.
• Extract frame data from calldata.
• Deserialize L2 transactions from channels.

In the block proof process, the guest program inputs the context related to the disputed block (transaction request list, block containing the initial state, relevant state tree, etc.). It verifies the validity of the initial state root, authorization signatures in the transaction request list, executes the transactions, generates relevant receipts and updates the state tree, ultimately obtaining the validity proof of the block.

zkVM Host Program

Acts as the role of cannon in Optimism, responsible for obtaining the data needed for state transitions, coordinating the execution of zkVM guest program, and generating zk proofs for transaction execution state transitions.

During the runtime, we input the tx requests list and the L2 block hash with the initial state. By executing the following steps, we finally obtain the zero-knowledge proof generated by zkVM:

1. Use L2 RPC to obtain relevant account and storage information, sequentially execute transactions.
2. Track which accounts/storage nodes need to be executed for transactions.
3. Obtain proofs of the inclusion/non-inclusion of the relevant account/storage node's initial state.
4. Use the data provided by the proof to construct the state tree required by the zkVM client.
5. Use zkVM to execute the guest program with the required input.

Workflow

1. Verifier node discovers a disputed block and completes the derivation from L1 block to L2 state.
2. Stake action is performed to initiate the verification process. The verifier calls the fault proof contract on L1 to disable deposits and withdrawals.
3. Verifier simulates the state in the verifiable zkVM, returning a cryptographic receipt as fraud proof.
4. On-chain verifier uses the receipt for verification.
5. Verification completed, deposits and withdrawals are re-enabled.