Scroll co-founder Zhang Ye: What are the design architecture and challenges of Scroll?
How did Scroll build zkEVM from scratch?Source: Scrollh Chinese Community
Recently, Zhang Ye, co-founder of Scroll, was invited to participate in the Stanford Blockchain Seminar, where he shared the architectural design and challenges of Scroll. In the first half of the speech, he introduced the overall architecture of Scroll and highlighted some of its special design choices.
In the second half, he described how to build zkEVM from scratch and demonstrated the process using specific examples. Finally, he briefly discussed various research challenges that Scroll faces in the fields of cryptography and protocol design.
Background and Original Intent
Scroll is a Layer 2 scaling solution for Ethereum. To maximize compatibility with Ethereum, Scroll is building a bytecode-compatible "zkEVM" that can prove the validity of EVM computations. The original intent of Scroll's design is to be developer-friendly and maximize composability. The challenge of building zkEVM lies in the high difficulty of construction and the high cost of generating zero-knowledge proofs. Fortunately, some technological breakthroughs in recent years have made it gradually feasible, such as polynomial commitments that can prove arbitrary degrees, lookup tables that can implement storage read constraints, hardware acceleration that can speed up proof generation, and recursive proofs that can further compress proofs to reduce costs.
For more details, please refer to Scroll Blog Series #1: Introduction to Ethereum Native zkEVM Rollup
Scroll Architecture
Scroll nodes are the primary means for applications and users to interact with Scroll. It consists of three modules: Sequencer, Coordinator, and Relayer.
The Sequencer provides a JSON-RPC interface and receives L2 transactions. Every few seconds, it retrieves a batch of transactions from the L2 memory pool and executes them to generate new L2 blocks and new state roots. Scroll's Sequencer implementation is based on Go-Ethereum (Geth), one of the most mainstream Ethereum node implementations. By forking Geth, we can achieve optimal compatibility and inherit time-tested security.
Once a new block is generated, the Coordinator is notified and receives the execution trace of this block from the Sequencer. It then dispatches the execution trace to a randomly selected Roller from the Roller pool to generate proofs.
The Relayer monitors the Rollup and Bridge contracts deployed on both Ethereum and Scroll. It has two main responsibilities. First, it monitors the Rollup contract to track the status of L2 blocks, including their data availability and validity proofs. Second, it monitors deposit and withdrawal events of the Bridge contracts deployed on both Ethereum and Scroll, relaying messages from one layer to another.
Each L2 block will go through the following three stages until final confirmation.
Pre-committed means that a block has been proposed by a Sequencer and sent to the Rollers. Although Pre-committed blocks are not yet an official part of Scroll L2, as they have not been published on the Ethereum base layer, users who trust the Sequencer can proceed with the next steps as expected. Currently, the estimated time for the Pre-committed stage is only 1-2 seconds.
Committed means that the transaction data of the block has been published on the Rollup contract on Ethereum. This ensures that the block data is available, but does not prove that it has been executed correctly. Currently, the estimated time for the Committed stage is several minutes.
Finalized means that the correctness of the transactions in this block has been verified by validating the validity proof on the Ethereum chain. Blocks that have been finalized are considered an official part of the Scroll L2 chain. Currently, the estimated time for the Finalized stage is over 10 minutes.
Due to insufficient computing power of the provers in the Pre-Alpha testnet phase, the overall process time is greater than the estimated time.
For more details, please refer to Scroll Blog Series #6: Overview of Scroll's Architecture
The Essence of zkEVM
The essence of zkEVM is to generate proofs for the execution traces produced by EVM virtual machine computations. In Scroll's zkEVM design, the first layer includes directly proving the logic of the EVM, including EVM circuits, RAM circuits, Storage circuits, and other circuits, such as the Signature circuit for verifying ECDSA signatures; the second layer performs aggregated proofs of the first layer's proofs. Considering the dynamic execution traces, Scroll adopts the latest Plonkish protocol for the front end of the proof system. Compared to standard Plonk, which uses permutation constraints, Plonkish uses lower-degree custom gates, allowing for flexible setting of constraints at each step.
In terms of hardware acceleration, Scroll has a unique PipeZK acceleration solution. For the first layer EVM circuits, the accelerated GPU can achieve a 9x speedup, completing proofs within 30 seconds. For the second layer aggregation circuits, the accelerated GPU can achieve a 15x speedup, completing proofs in about 2.5 minutes. Due to the current Pre-Alpha testnet having only about 10 provers, the actual speed may be slightly slower than the experimental data.
For more details, please refer to Scroll Devcon 6 Series #1: Proof System Choices for zk-Rollups
Interesting Research Directions (Protocols and Cryptography)
Currently, Scroll's research team is also conducting interesting explorations in the areas of protocols and cryptography.
The first research direction is the decentralization of provers and sequencers. The first proposal put forward by Scroll is to assign the tasks of the sequencer and prover to one node, handling transactions and generating proofs simultaneously, at the cost of potentially increasing the burden on the node and creating a certain degree of centralization. The second proposal is that sequencer nodes produce blocks by consensus, while prover nodes can freely submit proofs. The downside is that the system will rely on the fastest validators, and other underpowered provers will have no incentive to continue submitting proofs, leading to their exit from the system, which could result in the proof system being hijacked by the fastest validators. To address the second proposal, Scroll suggests setting a time window, where those who submit proofs within the specified time will receive proof rewards.
The second research direction is the significance of L3. L3 was first proposed by StarkNet, but the controversial point is that if data availability is placed on L1, it does not save much cost; if data availability is not placed on L1, similar functionality can be achieved on L2. L3 is more likely to cater to custom application needs, such as unique sequencers, custom execution environments, or lower deposit and withdrawal fees, as well as the composability required between L3s. For more discussions on L3, please refer to Vitalik: What Kind of Layer 3 is Meaningful?
The third research direction is liquidity allocation between L2 layers. For example, Uniswap may need to deploy liquidity pools separately on different L2 layers. How to connect liquidity pools between different L2 layers will greatly enhance user experience.
The fourth research direction is the resource pricing issue of zkEVM. The cost of computation mainly consists of verification and proof transactions, while the cost of storage mainly involves the storage of historical transactions and calldata. The ideal state is to maintain the current resource pricing scheme of the Ethereum mainnet, but due to the increased costs brought by zk-unfriendly computations like Keccak, adjustments to the resource pricing scheme of zkEVM are still necessary.
Other research directions include the randomness of circuits in zero-knowledge proofs and arithmetic. Scroll's proof system is divided into two layers, so the hardware acceleration algorithms for provers are also designed around these two layers. Currently, Scroll has chosen the Halo2 protocol for both the first and second layer proof systems, but is also actively exploring the composability between different proof systems.
Of course, the zk system is still under development and has not yet undergone auditing and practical testing, so it cannot guarantee that these codes are flawless in the foreseeable long term. A significant amount of auditing work is still needed at the code level. For more details, please refer to Scroll Rollup Day #1: Vitalik Introduces Strengthening Rollup Security with Multiple Proofs
