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.
How Scroll Blockchain Works: A Technical Overview
Scroll is a second-layer blockchain (Layer 2 — L2) designed to scale Ethereum. It uses ZK-Rollups — rollups with zero-knowledge proofs (ZKP) to bundle transactions outside of the main network (L1), while only the cryptographic proof that the transactions have been processed correctly, and the compressed transaction data are sent to L1.
Technical Principles and Premises for Blockchain Creation
The technical principles that were fundamental and what influenced the design of the blockchain can be studied in detail in this article.
Architecture
Let's look at the high-level general architecture according to the picture below.
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.
Rollup Process
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:
- Transactions are checked and executed in the Execution Node
- Transactions are packaged into batches and changes are fixed in L1
- 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:
- If a new chunk has been created, the Coordinator will request the execution trace of all blocks in this chunk from the L2 sequencer (execution node), and then send the chunk verification task to a randomly selected verifier (prover).
- If a new batch has been created, the Coordinator will collect proofs of all chunks of this batch from the database and send the batch verification task to a randomly selected aggregator-verifier (prover).
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
- 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.
- 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.
- 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.
- A group of ordered transactions is packed into a block.
- A series of adjacent blocks are grouped into a chunk. A chunk is the basic block for generating proof in the zkEVM scheme.
- 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).
EVM-based Application Development
We build decentilized applications for EVM-compatible blockchains
Differences between zkEVM and EVM in Scroll
Development tools and differences of the Scroll blockchain from Ethereum have been discussed here.
Scroll Infrastructure
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 and Cons of Scroll
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
Conclusion
The Scroll protocol looks very promising. Developing for Scroll is currently easier than for blockchains that are less compatible with EVM.
Links
More articles about ZK-rollups
Which Rollup to Choose for Your Project: Arbitrum, Optimism, Base, ZK EVM, and Others
MetaLamp editorial team
Why ZKSync’s Native Account Abstraction Is Superior to ERC-4337
Roman Yarlykov
Solidity developer
How ZKP and ZK Rollups Address Scalability: Reviewing ZKSync
Roman Yarlykov
Solidity developer
5 Rules from the Founder: How an EdTech Project Can Attract Investments. The Case of the Online School “Logopotam”
Alexey Litvinov
CEO and founder of the online school Logopotam
Is it worth launching a project on Solana, despite the hype around memes?
MetaLamp editorial team
Mintless Jettons on TON: A New Feature Making TON Projects Even More Attractive
MetaLamp editorial team
3 reasons to choose a ready-made solution for mini-apps in Telegram instead of developing from scratch
Dmitriy Shipachev
CEO at Finch
Think of it like a hamster for traffic: how to attract an audience with a Telegram clicker game
Nico Bordunenko
Business Analyst at MetaLamp
Which Rollup to Choose for Your Project: Arbitrum, Optimism, Base, ZK EVM, and Others
MetaLamp editorial team
How We Adapted a Mobile RPG for Blockchain and Enabled NFT Sales
MetaLamp editorial team
How TON Payments Enable Fee-Free Micro-Transactions and Their Uses
MetaLamp editorial team
What You Need to Know Before Starting a Project on TON
MetaLamp editorial team
What is the Meaning and Benefits of MVP for Startups in 2024?
MetaLamp editorial team
RWA explained: Opportunities of Real-World Assets in 2024
MetaLamp editorial team
Creating a Crypto Transaction Widget for Google Sheets: The CPayToday Journey
MetaLamp editorial team
How Early-Stage Startups Can Stay on Track with Development
MetaLamp editorial team
How to Attract Investments: Insights from Successful 2023 Startups
Mykola Pryndiuk
Social Media Specialist
When and How to Find a Technical Partner for Your Startup
MetaLamp editorial team
Understanding the Necessity of Account Abstraction in the Crypto World
Pavel Naydanov
Solidity developer
Ways to Speed Up Development: Outstaffing Pros and Cons
MetaLamp editorial team
Freelancer, Agency, or Contract Employees: Who to Hire for Startup MVP Development
Yana Geydrovich
Partnership manager at MetaLamp
From Corporate Blog to Brand Media: The Birth of Metalamp Magazine
Mykola Pryndiuk
Social Media Specialist
La Migliore Offerta: The Impact of Cryptocurrency on Business and Economy in 2023
Roman Shtih
CEO Metalamp
How We Use Our Training Program to Recruit Plutus Engineers
Svetlana Dulceva
The Education Program Supervisor
Discover Why IT Companies Appreciate Our Junior Developers
Svetlana Dulceva
The Education Program Supervisor
How We Designed a No-Cost Education Program for Web Development
Sergey Cherepanov
CTO MetaLamp
Articles