How Scroll Blockchain Works: A Technical Overview

Developed in collaboration with the Privacy and Scaling Explorations group at Ethereum Foundation for over a year.

In this article, we'll look at the main technical principles of blockchain that influenced the design of the blockchain, and give an overview of the general architecture of Scroll.

We'll detail about Scroll, which consists of a centralized sequencing node (execution node, rollup node) and a decentralized network (roller net), show the architecture and the rollup working process.

It is assumed that you are already familiar with the terms zkp.

The technical principles that were fundamental and what influenced the design of the blockchain can be studied in detail in this article.

Settlement Layer

This layer is located in Ethereum and consists of two contracts — Bridge Contract and Rollup Contract.

Bridge Contract:

• allows users and dapps to send messages, assets, transactions (if dapps in L1) to the Scroll network (L2) and back to L1.

Rollup Contract:

• verifies grouped transactions (batch) sent from L2.
• provides data availability (ensures that any network participant can access information about transactions and blocks).
• orders transactions for the canonical Scroll chain (In the blockchain, transactions must be processed in a specific order to avoid double spending and other types of fraud. The computation layer ensures that transactions entering the canonical Scroll chain are processed in the correct and sequential order). ——————

Sequencing Layer

This layer consists of nodes — Execution Node and Rollup Node.

Execution Node:

First off, it's important to mention that as of now, this is a centralized node and one of the key components of the protocol.

It's responsible for:

• Verifying and executing transactions sent by users through the L2 network or via the L1 contract — bridge.
• Creating L2 blocks from transactions.

Rollup Node:

• Bundles transactions into batches.
• Publishes transaction data and block information on Ethereum to ensure data availability.
• Submits proofs of transaction correctness to Ethereum for the final confirmation of the transaction batch (finalization in L1).

Proving Layer

This layer consists of the Provers module and Coordinator.

Provers:

This is a pool of validators in a decentralized network.

They are responsible for creating zkEVM validity proofs, which verify the correctness of L2 transactions.

Coordinator:

The Coordinator, in turn, is a module that sends verification tasks to a random Prover and passes the proofs to the Rollup Node for finalizing transactions in Ethereum.

First, let's break down what the nodes consist of.

Execution Node contains the following modules:

• Sync service. Subscribes to Bridge contract events. As soon as this module detects a new transaction, it generates it into a special L1MessageTx format and adds them to the local L1 transaction queue.
• Mempool. Collects transactions that are sent directly to L2.
• Executor. Extracts transactions from both the local L1 transaction queue and the L2 Mempool, executes them to create a new L2 block.
  
  

Rollup Node contains the following modules:

• Relayer. Sends commit transactions and finalize transactions to the Rollup Contract to ensure data availability and finality.
• Chunk/Batch Proposer. Creates chunks / batches from transactions and sends either to the database, for subsequent submission to the Prover for proof generation, or to the Rollup contract, for preliminary fixation in the L1 network.

Thus, the Rollup process consists of three stages:

1. Transactions are checked and executed in the Execution Node
2. Transactions are packaged into batches and changes are fixed in L1
3. Proof generation and submission to the Rollup contract for transaction finalization.

Workflow

Now let's walk through each point in the scheme.

Transactions are checked and executed in the Execution Node

1. Users send transactions through the L1 bridge or directly to the L2 network.

2. Sync Service extracts the latest added L1 transactions from the Bridge contract.

3. L2 Sequencer (Execution Node) processes transactions from the queue that came from L1, as well as from the L2 mempool, and creates L2 blocks.

Transactions are packaged into batches and changes are fixed in L1

4. Rollup Node tracks the latest L2 blocks and extracts transaction data.

5. Rollup Node proposes a new chunk or batch and records it in the database. For more on how block, chunk, and batch creation occurs, I recommend checking here.

6. After creating a new batch, the Relayer collects transaction data in this package and sends a commit transaction to the Rollup Contract to ensure data availability. Thus, preliminary data fixation in L1 takes place.

Proof generation and submission to the Rollup contract for transaction finalization.

7. The Coordinator queries the new chunk or batch from the database:

8. Once the Coordinator receives chunk or batch proofs from the verifier (prover), it will record the proof in the database.

9. As soon as the rollup relayer sees a new batch in the database, it sends a Finalize transaction to the Rollup Contract to verify the proof.

Thus, as you might have noticed, there is a specific life cycle of transactions.

Transaction Life Cycle

1. Confirmed: Users send a transaction either to the L1 bridge contract or to the L2 sequencer (execution node). A transaction becomes Confirmed after it has been executed and included in an L2 block.
2. Committed: Indicates that the transaction data of this block have been published on Ethereum. This doesn't prove they were executed correctly but guarantees block data availability.
3. Finalized: Indicates that a validity proof has been sent and verified by the smart contract. The transaction has the status of Finalized. After this step, the transaction is considered final.

Transaction Batching

As shown in the picture, in Scroll, transactions are grouped at several levels.

1. A group of ordered transactions is packed into a block.
2. A series of adjacent blocks are grouped into a chunk. A chunk is the basic block for generating proof in the zkEVM scheme.
3. A series of adjacent chunks are grouped into a batch. A batch is the basic unit for data fixation (preliminary submission to L1) and proof verification at the L1 level. Batch proof is the cumulative proof of chunks in this batch.

Thus, transactions are initially packed into blocks, then blocks into chunks (for sending to proof generation in prover), and then, chunks are packed into batches (for data fixation in L1 or proof verification).

Development tools and differences of the Scroll blockchain from Ethereum have been discussed here.

Scroll's infrastructure is rapidly gaining momentum and already includes dozens of protocols: Bridges, DeFi, infrastructure protocols, and more. (See the current list here).

Pros

• EVM-compatible smart contracts (Except for some precompiled contracts and eips)
• You can use favorite development frameworks and tools, such as foundry, hardhat, remix.
• Standard Web3 API (also support for standard Ethereum wallets like MetaMask)
• Transaction processing speed — L2 transactions are confirmed immediately and on L1 after a short period of time
• Low transaction fees
• Rapidly developing infrastructure

Cons

• Requires testing directly in the Scroll network. As a result, more time is needed for more thorough testing and audit, even for already tested and audited contracts, because there are minor changes in precompiled contracts and supported eips
• The network is still quite centralized and managed by certain validators (Sequencers)
• As the network is in development and testing — it's necessary to constantly monitor to ensure nothing breaks in the already working code

The Scroll protocol looks very promising. Developing for Scroll is currently easier than for blockchains that are less compatible with EVM.

Links