OP Stack + Zero-Knowledge Proof = The ultimate game of Layer 2?

OP Stack + Zero-Knowledge Proof = Layer 2 game?

For future Layer2 developers, OP Stack will become a universal Layer2 architecture. When developers start their own Layer2, they can flexibly choose between optimistic proof or zero-knowledge proof based on the security and efficiency required by the application.

Written by: Bill Qian, Yongxin Song, Bonan Yuan, Cypher Capital

The endgame of Layer2

Currently, the competition in the Layer2 track is extremely fierce. There are optimistic rollups such as Arbitrum, Optimism, and Base, as well as ZKP rollups such as Scroll, zkSync, Starkenet, Scroll, Polygon zkEVM, Taiko, Linea. It seems that there is a wide variety of competition in the Layer2 field, but in fact, they all use off-chain computation and on-chain proof in engineering principles. Whether it is optimistic fraud proof or ZKP circuit proof, the core difference in engineering practice lies in the different on-chain proof methods, while other principles are actually similar. Therefore, Optimism chose a special path, that is, modular Layer2, which logically decouples various components of Layer2. When OP Stack achieves the decoupling of various modules of Layer2, a very logical and seemingly imaginative idea is opened, that is, ZKP on OP Stack, which changes the challenger of OP Stack from Optimistic Proof to Zero Knowledge Proof. OpStack will become a universal Layer2 architecture that supports multiple proofs!

• Cosmoverse 2023 Conference Summary Glimpsing the Development Direction of the Ecosystem from the Latest Roadmap
• Head Warehouse Research Report MMORPG Blockchain Game Big Time
• These DAOs are changing Japan.

ZKP on OP Stack

Everything begins with an RFP from Optimism, https://github.com/ethereum-optimism/ecosystem-contributions/issues/61.

Below, I will introduce the problems and development directions proposed in this RFP.

Intent: Implement zero-knowledge proof to prove Optimism’s error proof program (supported by the instruction set of the Golang compiler)

How to implement: Implementing zero-knowledge proof (ZKP) for OP Chain is a prerequisite for secure and low-latency communication between L2 and L1. A zero-knowledge proof that supports the instruction set can prove Optimism’s error proof program, including any OP Stack blockchain. Based on the execution trace of the standard execution of the ISA, supporting the error proof program also introduces additional requirements.

Specifically, the error proof program introduces the concept of a “pre-graph oracle”, which uses special system calls to load external data into the program. Each error proof virtual machine is responsible for implementing a mechanism through which the hash of certain data is placed in a specific location in memory, executing a system call, and then loading the pre-image of that hash into memory for the program to use. The pre-graph oracle is also used to bootstrap the program with initial input. For more information, please refer to the “pre-graph oracle” section in the error proof program documentation.

In short, this proposal aims to utilize the highly modular nature of OP Stack to switch from the error proof method based on optimistic proof to the one based on zero-knowledge proof. To further specialize, since OP currently compiles GETH into Mini Geth through MIPS, the zero-knowledge proof of OP Stack can be understood as ZKMips, which is a zero-knowledge proof based on the MIPS virtual machine.

Why ZKP?

Currently, based on the OP Stack, everything is running smoothly. Optimism and Arbitrum, which are based on Optimistic Proof, have gained strong community support and developer support. So why explore zero-knowledge proofs in the OP Stack? Here are a few reasons:

• The OP Stack abstracts the modules of layer2 to a high degree. Introducing ZKP only means introducing a different way of error proof, and does not imply that OP will abandon optimistic proof. Developers using OP Stack can freely choose different proof methods.

• Optimism and Arbitrum, based on Optimistic Proof, still do not support error proofs. Essentially, OP and ARB are two unverifiable single-machine chains.

• The final confirmation speed of optimistic proof in 7 days is too slow. When ZKP Layer2 occupies the market, ZKP’s proof speed of up to 30 minutes will become a significant advantage, and end users will choose the higher security of ZKP Layer2.

Therefore, it is only a matter of time before Optimism supports ZKP. A bold guess is that in the future, the OP Stack will support two sets of error proof systems: optimistic proof and zero-knowledge proof. OP Stack is a universal Layer2 architecture that continues to iterate. In order to help everyone understand why OP Stack can switch between different proof systems, the following text will provide a detailed breakdown of OP Stack.

Core Modules of OP Stack

(This figure is from Optimism’s GitHub)

For OP Stack, the important modules are as follows:

• op-node

• op-geth

• op-batcher

• op-proposer

• op-program

• Cannon

• op-challenger

These modules are all independent programs and communicate through standard HTTP interfaces. This means that if developers want to modify certain features of the OP Stack, they only need to modify specific modules to customize their own Layer2. The following sections will provide a detailed introduction to each module of the OP Stack and the overall architecture of the OP Stack.

op-node

op-node is the most important module in the OP Stack. On the one hand, as a Sequencer, op-node contains the consensus client implementation of the blockchain, which can be compared to Lighthouse and Prysm in Ethereum, and sorts the transactions submitted by users. On the other hand, as a rollup driver, op-node is responsible for deriving the Layer2 chain from the data of the L1 block.

After the Sequencer collects and sorts user transactions, it will generate a batch with op-batcher. Before the batch is submitted to L1, in order to reduce the delay in the Rollup network, the Sequencer can generate Layer2 blocks in advance and propagate them in the Rollup network through P2P. The blocks generated directly in L2 are considered unsafe and need to wait for the batch to be submitted to L1 for derivation before they can be considered safe. However, under normal circumstances (no block reorganization, fraud, etc.), the blocks generated directly in L2 are the same as those derived from L1. Exchanges like Binance consider transactions to be confirmed after waiting for a certain number of Layer2 blocks, without waiting for the batch to be submitted to L1, which to some extent indicates a very low probability of error.

The process of deriving L2 blocks is handled by the driver, which continuously tracks the synchronization process between the L1 head block and the L2 chain. It retrieves deposit transactions and L2 transaction data from L1, along with their corresponding receipts, and generates LianGuaiyload attributes. These attributes are then passed to the execution engine to calculate L2 blocks. L2 blocks are fully dependent on blocks from the L1 chain, and the L2 chain extends whenever an L1 block containing L2 batches is generated. Additionally, if an L1 block undergoes reorganization, the L2 block will also be reorganized.

“op-geth”

op-geth is the execution client implementation of the OP Stack, which has made minor modifications to go-ethereum to adapt to the requirements of OP Stack. The consensus client, op-node, drives the execution client, op-geth, through the Engine API. By utilizing the LianGuaiyload attribute, op-geth can calculate the output information and generate L2 blocks.

“op-batcher”

Batcher, also known as batch submitter, mainly performs two tasks. One is compressing L2 sequencer data into batches, and the other is submitting the batches to L1 for the verifier to use for validation.

Batcher submits batcher transactions to the DA layer, which include one or more channel frames. A channel is composed of a series of sequencer batches to achieve higher compression rates. Currently, Batcher uses zlib for data compression. Since the size of a channel may exceed the upper limit of batcher transactions, the channel is divided into one or more channel frames. A batcher transaction can include one or more channel frames (which can come from different channels).

[Image: https://images.bitpush.news/cn/20231010/169686724991449092.jpg]

Source: Optimism

This design provides great flexibility for batcher. In the future, OP Stack will support batcher to utilize multiple signers to submit multiple channels in parallel.

“op-proposer”

Op-proposer is responsible for submitting the new state commitment (currently in the form of Output Merkle Root) generated after executing the L2 block by op-geth to L1. The Output Root does not take effect immediately and needs to wait until the dispute period is over to be considered finalized.

The above is the part of OP Stack that has been implemented. The following sections related to Fault Proof have not been completed and are only discussed based on the documentation specifications.

OP Fraud Proof consists of three components:

– Program: Given the commitment and dispute of Rollup Inputs (L1 Batch tx Data), it verifies the dispute in a stateless manner (by reproducing the same calculation process with the Inputs provided by PreImageOracle).
– VM: Given the stateless Program and Inputs, it traces any instruction (thus, it is stateful) and proves it on L1.
– Interactive Dispute Game: Binary dispute to a single instruction and solve this base case with VM.

“op-program”

Op-program is the reference implementation of Program, developed based on op-node and op-geth. It serves as a stateless middleware to verify the Claim about L2 state transitions.

To verify the Claim about L2 state, the program first applies L1 data to the finalized L2 state, reconstructing the latest L2 state. This process is similar to the work of op-node. The difference is that op-node retrieves data from RPC and applies state changes to disk, while Program retrieves data from the Pre Image Oracle and applies state changes to memory. The Program reads data from the Oracle in a streaming manner and performs streaming state changes until it reaches EOF or meets an early termination condition. After reconstructing the L2 state, it returns the verification result based on whether the state matches the claim.

Cannon

Cannon is an implementation of VM, consisting of two main components:

• Onchain MIPS.sol: EVM implementation to verify execution of a single MIPS instruction.

• Offchain mipsevm: Go implementation to produce a proof for any MIPS instruction to verify onchain.

In the onchain part, MIPS.sol implements the big-endian 32-bit MIPS instruction set, simulating the minimum subset of the Linux kernel to support Go programs, but does not include concurrency-related system calls.

In the offchain part, mipsevm uses Go language to simulate the execution process of MIPS.sol,

• It’s Go code

• …that runs an EVM

• …emulating a MIPS machine

• …running compiled Go code

• …that runs an EVM

In short, Cannon is running MIPS on EVM in the onchain part, which is the MIPS compilation of MINI Geth (MIPS version of GETH), namely the Golang version of ETH.

op-challenger

op-challenger is responsible for handling the processes related to the dispute game.

The challenge is to select a state root after the execution of a tx and raise a challenge, then the tx will be decomposed into multiple instructions, and each instruction will generate a new state, forming a sequence of states S1, S2, …, Sn.

To improve efficiency, the challengers need to take turns to execute steps, divided into Attack and Defend.

• Attack: The previous disputed state is taken as input, and the expected disputed state is the output. There needs to be a commitment to the previous state in the DAG.

• Defend: The disputed state is taken as input, and the next disputed state is the output. There needs to be a commitment to the next state in the DAG.

For example, assuming there are 1-9999 instructions, generating the sequence of states S1-S10000, first check the 5000th state, if it’s the same, go to the attack step and divide to the left; if it’s different, go to the defend step and divide to the right.

Finally, the dispute is narrowed down to the previous and next states of a single instruction through binary search, and then handed over to the VM to handle the state verification of a single instruction.

Workflow of the Modules

Normal Flow (excluding Challenge)

source: Cypher Capital

1. Users submit transactions, which can be submitted on L2 through L2 RPC or directly on L1 (can bypass op-batcher, with stronger anti-censorship capabilities, and can also serve as an emergency escape device).

2. RPC server started by op-node receives the transactions, sorts them, and sends them to op-batcher and op-geth.

3. op-batcher compresses the sequenced tx to generate a batch and submits it to the DA layer (L1).

4. op-geth executes the sequenced tx and passes the newly generated state to op-proposer.

5. op-proposer sends the L2 output root as a commitment to the L2 state to be stored on L1. When the challenge period ends, the state is considered finalized.

6. The driver in op-node retrieves transaction data and other information from L1 and derives the canonical L2 block. The L2 block derived from batch tx finalized on L1 is considered finalized, while the L2 block derived from batch tx confirmed but not finalized on L1 is considered safe. L2 blocks directly generated by L2 can be propagated in advance through P2P to reduce latency and are considered unsafe.

Challenge Process

source: optimism

1. Users initiate interactive dispute games.

2. Cannon (VM) runs op-program (written in Go) on the MIPS virtual machine to track the state changes of each step of execution.

3. op-program reproduces the calculation process of the L2 state by using the commitments of Rollup Inputs provided by the PreImageOracle, records the execution trace, and verifies the dispute without state.

4. op-challenger uses binary search to locate the dispute to a single instruction.

5. Cannon generates a proof for the state changes before and after executing that instruction and verifies it on the MIPS.sol smart contract on L1.

OP Stack+ZKP

Based on the above process introduction, we can easily find that the Challenge module has low coupling with other modules and has a low impact on the basic transaction process. It only needs to be involved when fraudulent behavior occurs (which has not yet occurred since the launch of OP Mainnet in December 2021).

In order to shorten the seven-day withdrawal confirmation time of the current Optimism and provide more modular choices for OP Stack, Optimism actively embraces ZKP technology and hopes to bring ZKP that can prove Optimism fault-proof programs and support well-known ISAs to OP Stack. The solution from O(1) Labs and Risc-0 team has passed the Foundation Mission (RFP) Application.

Solution from O(1) Labs

source: O(1) Labs

O(1) Labs, as the development team of Mina Protocol, plans to use Kimchi, which is adopted by Mina Protocol, as the proof system for MIPS VM, with only minor modifications.

Kimchi is a Halo2-like PLONKish system currently configured with an inner-product-argument style polynomial commitment scheme. It supports verifiable computation using traditional Turing machine-based instruction sets.

The backend of Kimchi is interchangeable. The current implementation is defined on LianGuaista curves using an inner-product-argument-based polynomial commitment scheme (LianGuaista-ILianGuai), which is incompatible with the cryptographic system used by EVM and has a higher verification cost on EVM. Therefore, O(1) Labs plans to change LianGuaista-ILianGuai to the KZG commitment scheme using the bn128 curves (bn128-KZG), which can use the precompile of EVM and has higher efficiency.

The input to the fault-proof MIPS system is now input into the bn128-kzg Kimchi system, which executes the ZK-Prove path. The pre-image system call continues to use Cannon in the OP Stack, and the final proof is sent to the smart contract on L1. After successful verification, the state is updated on L1.

Solution from RISC Zero

The RISC Zero team plans to use the Groth16 backend currently implemented to modify the zkVM based on the RISC-V ISA (augmented with accelerated co-processors for common cryptographic tasks including hashing and ECDSA signature verification). They will modify the Ethereum ZK Client based on Reth to further adapt it to Optimism and implement the L1-L2 derivation logic in zkVM to prove that the transaction sequence is generated by the Optimism sequencer.

The ZK Client consists of two parts: the zkVM guest program and the host library, similar to the op-program and Cannon in the OP Labs solution. The zkVM guest program is responsible for calculating state transitions, and the host library is responsible for obtaining the data needed for the calculation and coordinating the execution of the zkVM guest program, and generating the zkp for the transaction execution state transition.

Exploring the Possibilities of ZKP in OP Stack

Currently, a team called ZKM has implemented ZKMIPs for the EVM, which translates the EVM into the MIPS instruction set and performs zero-knowledge proofs. The feedback so far is that it is slow but usable. [Link to reference](https://ethresear.ch/t/zkmips-a-zero-knowledge-zk-vm-based-on-mips-architecture/16156)

Considering the relatively mature development and experience of Mina and Risc0, we have reason to believe that support for ZKP in OP Stack is only a matter of time. However, considering that OP Stack started ZKP development relatively late and does not have native support, the future performance is still unpredictable.

OP Stack, a Universal Architecture for Layer2

OP Stack has been adopted by many well-known teams due to its excellent code implementation, tolerant open-source protocol, and modular architecture design. The only criticism is that the deterministic time for the Optimistic Rollup technology used in OP Stack is too long, and its technical advancement is not as good as ZK Rollup. Now, with the help of third-party professional teams, OP Stack has begun to explore the future of ZKP. Considering that OP Stack does not currently support Fault Proof, it is possible for OP Stack to bypass the Fault Proof stage and directly use ZK Proof to achieve faster determinism and higher security.

For future Layer2 developers, OP Stack will become a universal Layer2 architecture. When developers start their own Layer2, they can flexibly choose between optimistic proofs or zero-knowledge proofs based on the security and efficiency requirements of their applications. It can be foreseen that Layer2 with optimistic proofs will be cheaper, while Layer2 with zero-knowledge proofs will be more secure.

reference: [Link to reference](https://blog.oplabs.co/building-a-fault-proof-system/)

We will continue to update Blocking; if you have any questions or suggestions, please contact us!