The Odd Couple: ZK and Optimistic Rollups on a Scalability Date | RISC Zero
The Odd Couple: ZK and Optimistic Rollups on a Scalability Date
Steven Li
In this post, we present a joint partnership between AltLayer and RISC Zero that aimsto bring “on-demand” ZK Fraud Proofs to optimistic rollups by merging ZK rollups and fault proofs together.
Bit of Background
There are two popular flavours of rollups today: Optimistic and ZK. Examples of optimistic rollups include Arbitrum and Optimism, while, ZKSync, Polygon zkEVM among others, have implemented the ZK version.
ZK rollups rely on cryptographic proofs of correct execution (aka validity proofs), that is to say, every new state proposed by a ZK rollup comes with a proof of correct execution of the underlying state transition function on a given set of transactions. On the other hand, optimistic rollups assume that a state proposed by the rollup is valid until it’s not.
Unlike ZK rollups that are secured by cryptographic proofs, optimistic rollups are secure under the assumption that there exists at least one honest party that can detect an incorrect state. This party, often called a challenger upon noticing an invalid state, engages with the rollup operator via what is called a bisection protocol – an off-chain interactive protocol between the challenger and the rollup operator with the goal to prove the fault on-chain (via fault proofs).
Fault Proof vs. Validity Proofs
Fault proofs and validity proofs are the core mechanisms that make a rollup secure. As mentioned above, fault proofs rely on a specific adversarial model around the existence of honest protocol participants, while validity proofs rely on cryptographic assumptions.
The bisection protocol in the case of fault proofs, however, requires that each party involved in the protocol remains online throughout the course of the protocol. Furthermore, each party should have sufficient time to exchange messages of which some have to be on-chain. This introduces a long period, often 7 days, to ensure that messages do not get censored by validators operating the base chain. This long challenge period becomes particularly painful if users have to move any asset from the rollup to the base chain. Note that the base chain needs to wait for the challenge period to elapse to be able to accept any incoming message from the rollup to the base chain.
It’s clear that both models currently have their own pros and cons. But, what if we could get the best of both worlds?
Bringing ZK to Optimistic Rollups via On-Demand ZK Proofs
The idea is rather intuitive: Can we upgrade fault proofs in optimistic rollups with cryptographic ZK proofs, whereby proofs are generated only when there is a challenge? Unlike a full ZK rollup, where the operator needs to generate a ZK proof for every single state transition, the on-demand model will only require a ZK proof when there is a challenge.
This design of a rollup is still optimistic as a state produced by the rollup is considered valid unless someone challenges it. If no one challenges the state, the rollup operator does not need to produce any cryptographic proof. However, in case, anyone does create a challenge, the operator will have to produce a proof of correctness for all transactions in the challenged block.
This ZK fraud proof architecture can be generalised and implemented across a wide variety of optimistic rollup SDKs.
Implementation by AltLayer using RISC Zero
The AltLayer and the RISC Zero team have been collaborating to implement this new ZK optimistic rollup model. The implementation comes in two variants:
Variant 1 (ZK fraud proof for a single disputed instruction): In this variant, the bisection protocol is kept mostly intact. The challenger engages with the rollup operator in a bisection protocol. At the end of the protocol, the operator and the challenger identify a single disputed VM instruction. Now, instead of executing this single instruction on-chain, the rollup operator generates a ZK proof of correct execution of this single instruction. The ZK proof is then verified on-chain.
Variant 2 (A full ZK validity proof in lieu of the bisection protocol): In this version, the bisection protocol is replaced entirely by a proof of correct execution or a proof of validity.
Leveraging RISC Zero’s zkVM
Both variants of this ZK optimistic rollup model are built on top of the RISC Zero zkVM which enables ZK proofs across a wide variety of general purpose languages such as Rust, WASM, and RISCV. Additionally, proof generation is highly parallelizable thanks to continuations and Bonsai which allows the ZK system to achieve industry leading performance and complexity. Combined, this serves as a platform which is highly upgradable and extensible, ready for the next generation of Optimistic rollups.
Benefits and Limitations
Variant 1 can be seen as the first step towards introducing cryptographic proofs in an optimistic rollup. Even though the performance benefits of this variant are somewhat limited as the operators still have to engage in an off-chain bisection protocol, there are several advantages of this variant to optimistic rollup builders who wish to adopt validity proofs:
It requires minimal changes to the existing rollup design, is highly extensible and upgradable, and is backward compatible with existing fault proof methods.
Allows parties to perform bisection over any underlying instruction set as long as the execution proof of the single contested instruction can be verified on the base chain. For instance, one could do bisection over WASM even if the base chain does not have a direct ability to run WASM instruction. As a result, the rollup does not need to emulate a corresponding interpreter in a contract on the base chain.
Variant 2 however does lead to security benefits as there is no need to perform the complex bisection protocol where both parties need to stay online. This variant can further reduce a long 7 day withdrawal period to hours. It also acts as a stepping stone enabling Optimistic rollups to transition into full ZK rollups removing the need to detect frauds and eventually reducing the withdrawal period to mere minutes.
It’s important to note that there are a few caveats with both the variants. As with any optimistic rollup, these modified rollups still require the existence of at least one honest participant and that this participant needs to have a long-enough time window to detect the fault and report it on the base chain. To this end, Altlayer and most optimistic rollups today have different types of validators that are tasked to watch the network and report any fault. In the future, these ZK systems will enable Optimistic rollups to transition to full ZK rollups completely removing the fraud dispute period.
Implementation Setup
Altlayer has implemented both these variants using an optimistic rollup implementation in Rust with fault proof over WASM. The system runs Sputnik VM (a Rust implementation of EVM) as the execution engine. The rollup client compiles Sputnik VM (in Rust) to WASM instructions and then runs bisection protocol over WASM. The ZK proof is then done over WASM via RISC Zero’s Bonsai proving service that in turn uses RISC Zero zkVM for proving. zkVM comes with recursive proofs, a general-purpose circuit (with a bespoke circuit compiler) and state continuations.
Concluding Remarks
This work introduces the idea of bringing ZK proofs to optimistic rollups by replacing fault proofs with on-demand ZK Fraud Proofs proofs. Altlayer has a working implementation that implements the two variants described in the article and utilises a rollup instrumented by the AltLayer framework and the Bonsai proving service. The observed performance shows the viability of the solution. Altlayer’s future work is to integrate it into all major rollup SDKs such as OP Stack and Arbitrum Orbit and make it available to all instantiations of optimistic rollups as an option.
