Scroll

Scroll zk-EVM L2

Summary

Scroll (opens in a new tab) is a L2 rollup that utilises a zk-EVM to generate execution proofs that are posted to L1 Ethereum.

High level overview

Scroll is EVM compatible. It implements its account and storage tries using their in-house built zkTrie (opens in a new tab) => "a sparse binary Merkle tree with the Poseidon hash, a zk-friendly hash function". It is open source (opens in a new tab).

Transactions are batched and submitted (Committed) to the L1 ScrollChain rollup contract. Validity proofs are then generated and submitted (Finalized) to L1 alongside the new state root against which we can verify storage proofs.

Chunks are the unit of zkEVM proving. Chunks are aggregated into batches and proven. It is the aggregate proof that is submitted to L1.

The undocumented ScrollChainCommitmentVerifier (opens in a new tab) has getter functions for the addresses of the Scroll rollup/Poseidon hash contract on L1. Poseiden hashes are used for node keys in the context of the zkTrie due to it being more efficient to prove in the zk circuit.

Context

The context for a scroll VM request is the lastFinalizedBatchIndex returned from the ScrollChain rollup contract.

Whilst this value is available on chain in the Scroll rollup contract, we fetch it from Scrolls API noting that mapping the batch index to the data contained within is dependent on this centralised API (opens in a new tab) at the present time.

Commit

The lastFinalizedBatchIndex is included in the commit body alongside block data for the last L2 block included in the latest finalized batch on L1.

Verification

The Unruggable gateway Typescript prover implementation used by the ScrollRollup.ts is EthProver.ts.

The Scroll Geth fork (opens in a new tab) implements the eth_getProof method and returns the same key structure for both account (accountProof) and storage proofs (storageProof). Internally Scroll uses its zkTrie implementation to return appropriate proofs and we provide helper functions within the ScrollTrieHooks library to appropriately handle verification of the proofs returned.

Notes

Proof Overflow

As outlined here (opens in a new tab):

"With Scroll’s current zkEVM circuits, it is possible to construct transactions and blocks that cannot be proven because they do not fit into the zkEVM circuit. We call this proof overflow."

Reliance on centralised APIs

As noted above the Scroll architecture (as is - 19/08/24) still has centralised elements.