Scroll - research notes for the EPF project

Website: https://scroll.io
Docs: https://docs.scroll.io/en/home/

Roadmap:
Launched their beta testnet on Sepolia mid-August 2023.

Scroll’s architecture summary:
https://scroll.io/blog/architecture

zkEVM: type-2 - full EVM-equivalence (in its current state rather type 2.5)
Zk-proof: ZK-SNARKs
DSL: Halo2, Plonkish/R1CS
PCS: KZG

Scroll is able to execute native EVM bytecode on L2 while inheriting strong security guarantees from base layer Ethereum.

L2Scan - Scroll Sepolia: (the below data reflects the state as of 12/09/2023)
https://scroll.l2scan.co

• L2 TPS: 1.13
• Transactions - total: 3.39M
• Avg gas price: ~1.1967 Gwei
• Number of finalized blocks: 700K+
• Avg block time: ~3 sec
• Unique wallet addresses: 673K+

Additional charts: https://scroll.l2scan.co/charts

Architecture:
Source: https://docs.scroll.io/en/technology/

• Settlement Layer: provides
  • data availability and tx ordering for the canonical Scroll chain,
  • verifies validity proofs, and
  • allows for sending messages and assets between Ethereum and Scroll.
• Sequencing Layer: consists of two elements
  • Execution Node:
    • executes the transactions submitted to the L2 mempool and the L1 bridge contract
    • produces L2 blocks,
  • Rollup Node:
    • batches txs,
    • posts tx data and block information to L1 for data availability, and
    • submits validity proofs to L1 for finality.
• Proving Layer: consists of
  • a pool of provers: generating the zkEVM validity proofs that verify the correctness of L2 txs, and
  • a coordinator:
    • dispatches the proving tasks to provers and
    • relays the proofs to the Rollup Node to finalize on the Ethereum.

State and data structure:

The state of a blockchain: all the account data contained in the tree. Instead of the Patricia Merkle Trie (with Keccak hash) Scroll uses zkTrie for both state trie and storage trie:

• binary Merkle tree with the Poseidon hash, a zk-friendly hash function.

Transaction life cycle: three phases until finalization.

• Confirmed: Users submits a transaction to either the L1 bridge contract or L2 sequencer. The transaction becomes Confirmed after it gets executed and included in a L2 block.
• Committed: The transactions are included in a batch and a commit transaction that contains the data of this batch is submitted to L1. After the commit transaction is finalized in the L1 blocks, the transactions in this batch becomes Committed. (Periodically the rollup node sends a Commit Transaction that posts the data of a batch of transactions to the L1 ScrollChain contract.)
• Finalized: The validity proof of this batch is generated and verified on the L1. After the finalize transaction is finalized on L1, the status of the transaction is Finalized and becomes a canonical part of the Scroll L2 chain.

Transaction Batching

In Scroll, the transactions are batched in multiple tiers.

1. A group of ordered transactions are packed into a block.
2. A series of contiguous blocks are grouped into a chunk. The chunk is the base unit for proof generation of the zkEVM circuit.
3. A series of contiguous chunks are grouped into a batch. The batch is the base unit for data commitment and proof verification on the L1. The proof for a batch, or a batch proof, is an aggregated proof of the chunk proofs in this batch.

Multi-layer batching schema:

• reduces the gas cost of on-chain data commitment and proof verification.
• reduces the data to be stored in the contract and amortizes the proof verification cost to more L2 transactions.

Tx workflow - rollup process

The L2 sequencer contains three modules: can anyone run the Execution node and build blocks?

• Sync service subscribes to the event issued from the L1 bridge contract and add it to the local L1 transaction queue.
• Mempool collects the transactions that are directly submitted to the L2 sequencer.
• Execution node pulls the transactions from both the L1 transaction queue and L2 mempool, executes them to construct a new L2 block.

The Rollup node contains three modules:

• Relayer submits the commit transactions and finalize transactions to the rollup contract for data availability and finality.
• Chunk Proposer and Batch Proposer proposes new chunks and new batches following the constraints described in the Transaction Batching.

The rollup process has three phases:

1. transaction execution (L2 Sequencer - execution node),
2. batching and data commitment (rollup node),
3. proof generation and finalization (Coordinator, prover/aggregate prover).

Rollup contract txs:
The Commit Transaction submits the block information and transaction data to L1 for data availability. The transaction includes the parent batch header, chunk data, and a bitmap of skipped L1 message.

The Finalize Transaction finalizes the previously-committed batch with a validity proof. The transaction also submits the state root and the withdraw root after the batch. Here is the function signature of finalizeBatchWithProof.

Execution Node
Core component, forked geth, that inherits most of Ethereum’s functionality

• Functions:

  • Collect txs from L2 and L1.
  • Validate txs and build L2 blocks.
  • Execute blocks and maintain the L2 blockchain state.
  • bridging messages and tokens from L1 to L2
  • (also RPC and some other APIs)

• Submodules: Storage: Ledger and state storage implemented using LevelDB; EVM: The state transition rules of Ethereum; Worker: Responsible for creating new L2 blocks; L1 SyncService: Sync and store L1 messages in l2geth local database; API layer: Standard Ethereum RPC and p2p interfaces; Transaction pool: Mempool for L2 transactions; Circuit capacity checker: checks if a transaction or a block exceeds the circuit capacity limit.

• Circuit capacity checker: 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. This is called proof overflow.

  • To avoid this, Scroll implemented a circuit capacity checker as part of l2geth. It is used both during block creation and block validation.

• Transaction fees

  • L2: sent to a Scroll-maintained L2 fee vault contract.
  • L1 fee: In addition to the L2 gas fee that covers L2 block space and execution costs, there is an L1 fee that covers the costs of committing the transaction to L1. This fee is proportional to the size of the RLP-encoded transaction. The actual cost depends on the current settings stored in the L1GasOracle contract on L2. This fee is deducted from the sender balance directly (and not from the gas allowance).

Rollup node:

• Main components: Chunk proposer, batch proposer, relayer

Limits the rollup node must enforce during chunk and batch creation

1. Constraints on chunks:
   a. No proof overflow: Using the circuit capacity checker, Scroll makes sure to include as many blocks in a chunk that it would still not lead to proof overflow.
   b. L1 payload: Inherited constraints from batch proposer, transaction payload cannot exceed 128KB.
2. Constraints on batches:
   a. L1 payload: Ethereum has a hardcoded 128KB limit on transaction payload size.
   b. L1 commit gas: The gas cost of committing a batch is proportional to the number of blocks and transactions in it. Scroll ensures that this cost does not exceed the L1 block gas limit.

Prover-sequencer separation being considered by Scroll: talk by Toghrul

• Sequencer does ordering and keeps most of MEV - demotivates provers
• Prover sequencer separation - PSS: Ensures that revenue is fairly distributed to the provers as well
  • Enshrined:
    • pros:minimal overhead, couple of sequences are enough
    • cons: sequencers may outsource block building to external parties, which leaks value to outside the protocol
    • Steps:
    • sequencers bid in an auction
    • Provers select highest paying bid
    • Bidder reveals the block content
    • Sequencers reach consensus on the ordering of transactions
  • External PSS:
    • Pros: sequencers are outside the protocol in this case; simpler design, only one in-protocol role; but
    • Cons: this comes with a lot of overhead related to provers reaching consensus
    • sequencers bid in an auction
    • Provers select highest paying bid
    • Bidder reveals the block content
    • Provers reach consensus on the ordering of transactions

---

–- Earlier blog article about the architecture –-

Prover network
Source: https://scroll.io/blog/architecture

Provers are responsible for generating validity proofs for the zkRollup.

• expected to utilize accelerators such as GPUs, FPGAs (Field programmable gate array), and ASICs (application specific circuits) to reduce the proving time and proving cost.

How does a Prover generate the validity proof for each block? The process consists of the following steps:

• converts the execution trace received from the Coordinator to circuit witnesses.
• It generates proofs for each of the zkEVM circuits.
• Finally, it uses proof aggregation to combine proofs from multiple zkEVM circuits into a single block proof.

Rollup and Bridge Contracts

Scroll connects to the base layer of Ethereum through the Rollup and Bridge smart contracts. Together, these

• ensure data availability for L2 transactions and
• allow users to pass assets and messages between L1 and L2.

The Rollup contract receives L2 state roots and blocks from the Sequencer. It stores state roots in the Ethereum state and L2 block data as Ethereum calldata. This provides data availability for Scroll blocks and leverages the security of Ethereum to ensure that indexers including the Scroll Relayer can reconstruct L2 blocks. Once a block proof establishing the validity of an L2 block has been verified by the Rollup contract, the corresponding block is considered finalized on Scroll.

The Bridge contracts deployed on the Ethereum and Scroll allow users to pass arbitrary messages between L1 and L2. On top of this message passing protocol,Scroll has also built a trustless bridging protocol to allow users to bridge ERC-20 assets in both directions. To send a message or funds from Ethereum to Scroll, users call a sendMessage transaction on the Bridge contract. The Relayer will index this transaction on L1 and send it to the Sequencer for inclusion in an L2 block. Sending messages from Scroll back to Ethereum uses a similar process on the L2 Bridge contract.

How does Scroll’s zkRollup work?

L2 blocks in Scroll are generated, committed to base layer Ethereum, and finalized in the following sequence of steps:

1. The Sequencer generates a sequence of blocks. For the i-th block, the Sequencer generates an execution trace T and sends it to the Coordinator. Meanwhile, it also submits the transaction data D as calldata to the Rollup contract on Ethereum for data availability and the resulting state roots and commitments to the transaction data to the Rollup contract as state.
2. The Coordinator randomly selects a Roller (Prover) to generate a validity proof for each block trace. To speed up the proof generation process, proofs for different blocks can be generated in parallel on different Rollers.
3. After generating the block proof P for the i-th block, the Roller sends it back to the Coordinator. Every k blocks, the Coordinator dispatches an aggregation task to another Roller to aggregate k block proofs into a single aggregate proof A.
4. Finally, the Coordinator submits the aggregate proof A to the Rollup contract to finalize L2 blocks i+1 to i+k by verifying the aggregate proof against the state roots and transaction data commitments previously submitted to the rollup contract.