[Rollup Series] Part 1: Scroll, the Dream of a Native zkEVM
Scroll is a general-purpose zkEVM-based ZK-Rollup aiming for the highest level of EVM compatibility for existing applications and tools.
Review: Steve Kim (@steve_nw_kim)
This is Part 1 of the Rollup Series. If you would like to read the other parts, please check out the list below:
Part 1: Scroll, the Dream of a Native zkEVM
Part 2: Classification of zkEVMs and Taiko
Part 3: Beyond Equivalence to EVM-Native, Specular
Part 4: Exploring Coinbase’s L2 Network, Base
TL;DR
1) There is no general-purpose zero-knowledge (ZK) rollups at present because it is technically very challenging to generate zero-knowledge proofs for EVM computations. However, various projects such as Starkware, zkSync, and Polygon have taken on this challenge.
2) Among them, Scroll is a ZK-Rollup project aiming for the highest EVM compatibility level.
3) In this article, we will take a deep look at why Scroll’s zkEVM development was possible and the network’s structure.
1. Introduction
1.1 Overview of the series
When Vitalik Buterin published “An Incomplete Guide to Rollups” on January 5, 2021, the total TVL (total value locked) in Ethereum Layer 2 (L2) solutions was relatively low at about 75,000 ETH ($78M). At the time, the L2 market seemed to have a long way to go. However, there are about 26 L2 projects now, and the current L2 total TVL is about 3.2M ETH ($5B), a 42-fold growth in ETH and 64-fold growth in terms of dollars. In particular, Arbitrum and Optimism, two major optimistic roll-up projects, have grown to rank 5th and 7th in overall network TVL rankings. Now, the L2 market has become so prevalent that many users feel quite a level of inconvenience if L2 projects were to disappear.
As the L2 market grew, numerous L2 projects were created, and many projects, such as Arbitrum, Optimism, dYdX, zkSync, and Starknet, made their names known. Even now, despite a large number of networks already existing on Ethereum, many L2 projects are still being created, perhaps because of the advantage of quick process calculations while benefiting from the strong security of Ethereum. In this Rollup Series, we are going to deal with relatively less-known projects that have appeared recently, in addition to well-known Rollup projects. The first project in the series is Scroll.
1.2 zkEVM
Why are zero-knowledge rollups getting so much less attention in the current market than optimistic rollups? There may be various reasons, but the biggest reason by far is its general-purpose use. In the case of optimistic rollups, it is not technically difficult to create an EVM-like computational environment because it assumes that all transactions in L2 are valid and then uses fraud proofs to determine the validity. Therefore, the code used in the existing Ethereum network could be easily uploaded on top of the optimistic rollup networks, various dApps could be easily deployed, and the ecosystem could grow extensively.
On the other hand, it is very difficult to build an EVM environment in zero-knowledge rollups, which use zero-knowledge proofs (ZKPs) to prove the validity of a computation. To generate a zero-knowledge proof for a specific computation, it is essential to convert it to the form of QAP (Quadratic Arithmetic Program). The first step in converting a computation into a QAP is constructing a algebraic circuit made of logic gates. In order to build zkEVM in the same environment as EVM, the EVM execution process itself (more precisely, EVM execution trace) must be configured as a circuit so that a zero-knowledge proof can be created from it. However, this was a very difficult task because it required a lot of resources for computation.
That is why zk-rollup projects have only been specialized in specific applications, such as dYdX, specializing in trading, and ImmutableX in NFT. Due to technical difficulties, general-purpose networks where various DApps can be deployed could not be developed. This is also why zk-rollups have performed poorly in terms of TVL and the number of users compared to the optimistic rollups.
However, as Vitalik Buterin pointed out, zero-knowledge rollups can be a superior solution to optimistic rollups in the medium and long term, and various projects have been working to develop general-purpose zk-rollup networks. These projects can be classified according to compatibility with EVM. The first is Starknet and zkSync, which are compatible at the language level. As mentioned above, it is very difficult to build zkEVM from the scratch, so these two projects do not use EVM, but rather use their custom virtual machines. Solidity can be used, but EVM compatibility is the lowest because there is the process of transpiling Solidity to a zero-knowledge-friendly language instead of directly putting it into the compiler. However, since both the opcode and the execution environment are zero-knowledge friendly, it is the most advantageous in terms of performance.
The second is the Polygon zkEVM, compatible at the bytecode level. Using a custom VM is the same as the previous two projects. However, by matching the opcodes used in the EVM with the zero-knowledge-friendly zkASM opcodes, it ensures compatibility with Ethereum while enhancing performance to some extent. You could call it Ethereum-compatible from this stage, but not being EVM-equivalent yet.
The third is Scroll, which aims to build a native zkEVM. Since it is very difficult to build zkEVM directly, that is not Scroll’s immediate goal. Currently, it is in a similar situation as Polygon zkEVM, but Scroll does aim to build zkEVM as a long-term goal and is pursuing development accordingly. Scroll shows the highest level of Ethereum compatibility, but it has the lowest performance because a lot of overhead (additional computing resources) occurs in the process of configuring the circuit. Let’s take a closer look at Scroll.
2. Scroll
2.1 Overview
Scroll is a general-purpose zk-rollup project aiming to be an EVM-equivalent zkEVM. EVM-equivalent goes further than EVM-compatible with an environment that runs the same as the specifications presented in Ethereum Yellow Paper. To this end, Scroll is collaborating with the Ethereum Foundation’s Privacy and Scaling Explorations (PSE) group. In an EVM-equivalent environment, not only can Solidity be used for smart contracts, but various other tools (Etherscan, Foundry, Hard Hat, Metamask, etc.) can be used in the Ethereum without much friction. Because it requires the highest level of Ethereum compatibility, it is very difficult to build an EVM-equivalent zkEVM. Is this project even possible?
The idea of building zkEVM has become more tangible because a lot of research has been conducted in the field of zero-knowledge proofs for the past two years. First of all, there is the use of polynomial commitment. Polynomial commitment is one of the methods of summarizing a specific polynomial into a commitment value. (Reference: [Research] KZG Ceremony — Contribute to Ethereum Now!) There are various methods of polynomial commitment, such as IPA and FRI, but Scroll uses the KZG polynomial commitment method. As shown in the figure above, the computation on a zk-rollup can be converted into a two-dimensional matrix through a process called witness generation, which can then be converted into a list of polynomials. For the validity of the operation, we need to confirm that these polynomials satisfy certain conditions: (e.g. a(x)*b(x)-c(x)=0). Using the KZG polynomial commitment, one can easily check that the condition (e.g. a(s)*b(s)-c(s)=0) is satisfied at a specific random value “s,” thereby reducing the overhead in configuring the circuit. In addition, with the advent of Halo in 2019, it is easy to generate recursive proofs. Also, hardware acceleration is possible through GPU, FPGA, and ASIC when generating ZKP, making the idea of building zkEVM more and more of a reality.
2.2 Structure
Now let’s look at the network structure of Scroll zk-rollup. The Scroll Network consists of three main parts: 1) Scroll Node 2) Roller Network and 3) Rollup and Bridge Contracts.
2.2.1 Scroll node
The Scroll node collects transactions from users to construct blocks of the rollup network, submits the created blocks to Ethereum, and plays a role in messaging between Ethereum and Rollup. A Scroll node consists of a sequencer, coordinator, and relay, and their roles are as follows:
- Sequencer: Uses a Geth-forked client, receives transactions from users, composes blocks, and executes them.
- Coordinator: Detects when a new block is created, receives the execution trace of the block from the sequencer, and selects a random roller in the roller network to send it. The roller takes the role of generating ZKP by receiving the execution trace.
- Relayer: Plays a role in continuously observing the bridges and rollup contracts that exist in the Scroll network and the Ethereum network, monitors whether rollup blocks and validation proofs are being submitted to Ethereum, and detects deposit and withdrawal events in the bridge contract when users transfer funds.
2.2.2 Roller network
The roller network is a network composed of rollers that serve as provers to generate ZKPs. Rollers use hardware such as GPUs, FPGAs, and ASICs to create ZKPs. The roller receives the execution trace from the Coordinator in the Scroll node, converts it into a circuit witness, and generates ZKP for each zkEVM circuit. The generated ZKPs are gathered through an aggregation circuit to create a block proof representing the validity of one block.
2.2.3 Rollup and Bridge Contracts
The Rollup contract receives state roots summarizing the state of the scroll network and a block from the sequencer, and stores the state roots in the state of Ethereum and the block data in the form of calldata. It also plays a role in verifying the validation received from the rollers. The bridge contract is responsible for the transfer of funds between Ethereum and Scroll, and the relayer existing in the scroll node monitors the deposit and withdrawal events occurring in the bridge contract.
2.2.4 Conclusion
The role groups and processes described above are combined into a structure as shown in the figure above. The sequencer continues to generate blocks, and the execution trace T for this is provided to the coordinator, and the block data D is submitted to the Rollup contract existing in the Ethereum network. The coordinator selects a random roller existing in the roller network and transmits T, and the selected roller generates P, the ZKP for T. The process of generating P is also advantageous in terms of scalability because each roller can process it in parallel. The generated P is sent back to the coordinator, and the coordinator collects P at regular intervals and sends it to another roller to create A, a summary of it. Finally, the coordinator receives A and submits it to the Rollup contract existing in Ethereum, and the Rollup contract verifies it and grants finality to the corresponding block.
When a block is created, finality is granted through several stages, so the state of the block varies depending on which process it is located in:
- Precommitted : The state in which a block is proposed by the sequencer and T is passed to the roller. The block has not yet been submitted to Ethereum, and if the sequencer can be trusted, the block can be used in the Precommitted state as it is.
- Committed: The state in which the data of the block has been submitted to the Rollup contract existing in Ethereum. This means that the block data is available on the Ethereum network, but the validity of the operation cannot be guaranteed because the validation has not yet been confirmed.
- Finalized: The state in which the entire process described above has been completely completed and has been verified on the Ethereum network up to A, the aggregated ZKP. Since the validity of the operation has been proven on the Ethereum network, it is a complete state that anyone can safely trust.
2.3 Decentralization
Rollup networks can prove the validity of transactions in the Ethereum network by fraud or validity proofs, so there would be no big issues even if the entities that create blocks are centralized. However, minor issues such as censorship and MEV would mean it would be desirable to decentralize it ultimately (Reference: [Research] Efforts to decentralize Rollup). Scroll also has plans to decentralize the sequencer and the roller roles. As we saw earlier, since rollers can process ZKP generation in parallel, decentralizing rollers directly contributes to the scalability of the network. The Scroll team is planning to build a solution using GPU in the beginning and make it open-source so that anyone can easily participate as a roller. Going further, it plans to collaborate with hardware companies to build ASIC and FPGA solutions.
2.4 Roadmap
Scroll is currently in the stage of pre-alpha testnet. Anyone on the pre-alpha testnet can receive testnet tokens through Faucet and try out a simple bridge and swap, so we do recommend that interested readers try it out. After the pre-alpha testnet stage, there will be an alpha testnet stage before the zkEVM mainnet is released. The decentralization of the prover and sequencer mentioned above is scheduled for after the mainnet launch.
3. Closing
Numerous projects such as Starknet, zkSync, Polygon, and Scroll have announced the development of zkVM and zkEVM, and although there are no products on the mainnet yet, the competition is gradually intensifying. Since Scroll aims for the highest level of EVM compatibility among them, its full product may be released the latest. However, given that you will be able to use the code, tools and infrastructure used in Ethereum, it is worth keeping an eye out for it.
4. References:
Disclaimer: This post is for informational purposes only, and the author is not liable for the consequences arising from any investment or legal decisions based on the information contained in this post. Nothing contained in this post suggests or recommends investing in any particular asset. Making any decisions based only on the information or content of this post is NOT advised.
All for Validity
