Overview: Scroll Euclid Architecture

Scroll’s zkvm-prover architecture consists of three proof layers, namely, chunk, batch and bundle. Each layer has its own guest program that codes validation logic for that layer. These guest programs are available in:

• chunk: https://github.com/scroll-tech/zkvm-prover/tree/4f25eb6d9ac4edadd5f833d05e7da4872db4a186/crates/circuits/chunk-circuit
  • A chunk represents a list of Scroll L2 blocks and the chunk circuit is essentially the zkEVM implementation using Scroll’s fork of revm under the hood. The purpose is to validate that the correctness of the claimed L2 state transition as a result of applying each L2 tx over all the blocks.
  • The chunk circuit’s proof is a STARK proof
• batch: https://github.com/scroll-tech/zkvm-prover/tree/4f25eb6d9ac4edadd5f833d05e7da4872db4a186/crates/circuits/batch-circuit
  • Since verifying each chunk’s proof on-chain (L1) would incur large proving costs, we introduced a layer on top of the chunk, we call it a batch. A batch represents a list of contiguous chunks. The batch is also the unit of Data Availability (DA) for Scroll, by that we mean that L2 data is made available on L1 for each batch.
  • The batch circuit in its logic also verifies the chunk proof for each chunk in the batch.
  • Since DA is published via EIP-4844 blobs, the batch circuit’s guest program also verifies the KZG proof and re-computes the blob versioned hash (blobhash) to match with what’s available on-chain (L1).
  • The batch circuit’s proof is a STARK proof
• bundle: https://github.com/scroll-tech/zkvm-prover/tree/4f25eb6d9ac4edadd5f833d05e7da4872db4a186/crates/circuits/bundle-circuit
  • Multiple batches are then bundled together into a single Scroll bundle which is the unit of L2 state finalisation from L1’s perspective, i.e. a bundle proof is a Halo2 SNARK that is verified on-chain (L1).
  • Doing so allows us to fine tune finalisation latency and amortise L1 proof verification costs by bundling higher number of batches together.
  • The bundle circuit’s proof is an EVM verifiable SNARK proof

Overview: OpenVM

Build and Transpile

OpenVM guest programs are essentially the code/logic that runs within OpenVM zkVM. The guest program (a Rust program) is first built into an elf and then transpiled into an executable exe that can be interpreted by OpenVM zkVM. That is, we have a 2-step process to build and transpile.

OpenVM Config (openvm.toml)

Each guest program must also define a TOML config, that we call app-config (generally named as openvm.toml in the guest program’s project directory). The app-config defines which OpenVM modules or extensions must be enabled in order to build the guest program. For instance, in our batch-circuit since we make use of OpenVM’s pairing extension to do certain elliptic curve operations, one can see that those modules are enabled and configured from the batch-circuit's app-config here: https://github.com/scroll-tech/zkvm-prover/blob/4f25eb6d9ac4edadd5f833d05e7da4872db4a186/crates/circuits/batch-circuit/openvm.toml.

Committed EXE

The next step is to commit to the executable exe to get a committed exe (OpenVM ref) that includes the executable as well as a commitment to the executable.

Our goal is to finally construct an AppExecutionCommit (OpenVM ref) that essentially wraps two commitments:

1. exe_commit: Commitment to the executable exe built and transpiled from the guest program
2. leaf_commit: Commitment to the leaf VM verifier program which commits the config

<aside> 💡

We construct this in the linked snippet, specifically here.

</aside>

What to do with Commitments?

An OpenVM proof also contains the above commitments to the guest program and the config that were used for proof generation. The verifier’s duty is to independently build and generate these commitments and while verifying the correctness of the proof itself, they MUST also verify that the commitments specified in the proof are in fact the same as the commitments they built independently from the guest programs. Only then the verifier is certain that the proof does prove the execution of the claimed guest program.

Where are these Commitments?