At RISC Zero we are committed to building innovative Open Source solutions on top of our zkVM and Bonsai. The OP Stack Zero Knowledge Proof RFP is an exciting step in this mission as we bring Zero Knowledge Proofs to the OP stack. Through our proposal we aim to build a system that introduces ZK security and scaling to Optimism while ensuring compatibility with the existing OP stack. This will enable long term upgradability and extensibility, creating the foundations for a ZK future for the OP stack.
Implementing a zero knowledge proof (ZKP) for OP Chains is a prerequisite to enable secure and low latency cross chain communication between L2 and L1, as well as directly between OP Chains. A ZKP for a well-supported instruction set architecture (ISA) that can prove the Optimism fault proof program acts as the foundation for a system that can prove any OP Stack based blockchain.
When the Mission was announced, we knew immediately that we wanted to participate:
When we released the zkVM early last year, we were the first to provide an open source ZK prover and verifierbased on a general purpose ISA (RISC-V). While other systems at the time focused on custom circuit languages and custom architectures, we focused on a general purpose, industry-standard architecture precisely because we wanted to make it easy to bring ZK into existing software ecosystems. The Mission asked for exactly that; how could we say no?
We were already investigating the possibility of building Zeth, our “Type 0” zkEVM. Because of Optimism’s noteworthy EVM compatiblity and the flexibility of core libraries like revm and Alloy, we were optimistic that we could easily expand Zeth to support the Op Stack.
So we submitted a proposal to do just that: expand Zeth to support Op blocks, and provide the additional tooling needed to integrate with the Op sequencer. A short while later, our proposal was accepted. Today we want to explain our proposal and why we’re excited to be working in the Op Stack.
Fault proofs, revisited
Optimism is a highly scalable Ethereum L2 powered by the Op Stack. As an L2, it has built-in interoperability with Ethereum: smart contracts running on Ethereum (resp. Optimism) can send and receive messages to smart contracts running on Optimism (resp. Ethereum). Among other things, this interoperability makes it easy to move (”bridge”) tokens between the chains.
This integration means that Optimism must periodically publish data about Op blocks on Ethereum. Security is provided by fault proofs:
In an Optimistic Rollup, state commitments are published to L1 (Ethereum in the case of OP Mainnet) without any direct proof of the validity of these commitments. Instead, these commitments are considered pending for a period of time (called the "challenge window"). If a proposed state commitment goes unchallenged for the duration of the challenge window (currently set to 7 days), then it is considered final. Once a commitment is considered final, smart contracts on Ethereum can safely accept withdrawal proofs about the state of OP Mainnet based on that commitment.
While fault proofs are an effective mechanism, they come with one major downside: the challenge window. The purpose of the challenge window is to ensure there is sufficient time for someone to recognize and challenge onchain shenanigans; the downside is that it might take several days for shenanigans to be detected and challenged, which in turn adds latency and complexity to withdrawals and interactions between smart contracts running on Ethereum and Optimism.
ZK proofs to the rescue
One way to reduce (or even remove!) the challenge window is to replace the dispute protocol with ZK proofs. Whereas traditional fault proofs require parties to engage in an interactive protocol to pinpoint the fault, ZK proofs make it possible to prove, once and for all, that a given block is valid.
Here, validity means three things:
The block must be semantically valid, i.e., the new state root (and other block data) are the result of applying a sequence of valid transactions to the parent block. This is exactly what Zeth does for Ethereum.
The parent block is consistent with the chain’s history (i.e., is the correct “parent block.”)
The block must be constructed using the sequence of transactions given by the Optimism Sequencer.
Once a proof has been verified on the L1, there is no room for dispute: the block is correct, full stop. This means the challenge window can be reduced from days to minutes (the time required to generate a proof). Given the rate of improvement in ZK proving technology seen in recent years, it’s possible that one day the challenge window can be removed entirely.
The Optimism Sequencer publishes its state to Ethereum. This means anyone with access to Ethereum’s history can reconstruct the “official” sequence of transactions used to produce Optimism blocks.
The Optimism Chain also publishes its state to Ethereum.
In theory, step (2) is unnecessary since anyone with access to the Sequencer can reconstruct the chain’s state. But in practice, this reconstruction is too expensive and unworkable for most use cases; therefore, it is convenient for the chain’s state to periodically be published directly to Ethereum, saving others from the work (and cost) of reconstructing the state.
Of course, a mechanism is required to ensure the state from (2) is consistent with the state from (1). Historically, this was done with fault proofs. But with ZK, it can be done with onchain proof verification.
To achieve this, we proposed a solution that involves 3 basic parts:
A way to prove that a given block was generated by applying a given sequence of transactions to a given “parent” block.
A way to prove that a given sequence of transactions came from the Optimism Sequencer. This can be done by reading the Sequencer’s state directly from Ethereum, parsing the data, and committing to the sequence of transactions held within.
A way to “roll up” (1) and (2) into a single proof.
(Of course, Optimism blocks are generated at a higher frequency than Ethereum blocks, so we also require the ability to “roll up” a sequence (or “epoch”) of Optimism block proofs into a single proof.)
To be secure, the final proof must commit to all of its onchain inputs (notably the Sequencer’s state, as well as the most recent Optimism block, as reported by Ethereum.) This data is all held on Ethereum, so in essence, it suffices to record which Ethereum blocks were used when reading this data.
When such a proof is submitted to Ethereum for verification, the onchain contract must then verify that the proof is correct and that the inputs are valid (i.e., the relevant blocks are contained in Ethereum’s history). Doing this correctly requires some care; for example, it’s important that the proof read data from all of the relevant blocks, so that the Sequencer state has been fully parsed and no transactions get skipped. With the right set of equality checks and Merkle inclusions, this can be done. Importantly, because all of the inputs are held on Ethereum, it’s possible to verify that the inputs are correct from within an Ethereum smart contract.
An easy project, thanks to good foundations
As our recent work with Zeth demonstrates, it’s easy to read and verify Ethereum data from within our zkVM. Popular libraries like Alloy provide all of the types and functions needed to read and verify Ethereum data from JSON-RPC, while crates like revm make it easy to produce EVM-compatible blocks.
The maturity of the Rust/Ethereum ecosystem, together with the versatility of Zeth and our zkVM, makes it easy to build ZK proof systems for L2s. We’re excited to showcase this with Optimism and look forward to sharing our progress in future posts.
Looking towards the future
Through ZK, we are able to advance the entire OP stack, shortening withdrawal periods, improving network security, and increasing interoperability across the Superchain. This is the future of rollups and the modular ecosystem, a synergistic combination of ZK Proofs and Optimistic Rollups, bringing the best of both worlds together.
