On October 10th, at 14:00, Ethereum Layer 2 solution Scroll successfully generated its first block on the mainnet, marking the official launch of Scroll’s mainnet. As of October 25th, over 7,600 ETH had entered the Scroll network via cross-chain bridges, and 24 decentralized trading platforms had gone live on the Scroll mainnet, with a total TVL of approximately $10 million.

On October 17th, Scroll reaffirmed its commitment to openness and decentralization as it announced the launch of its mainnet. In the next phase, Scroll will focus on building a decentralized proof network and sequencer. In this article, we will provide a detailed analysis of Scroll’s architecture and technology to help you understand the current state and future development direction of Scroll. We will also delve into Scroll’s zkEVM circuits and audit insights, enhancing security precautions for zk projects.

Who Is Scroll, the Catalyst for the Layer 2 Revolution?

Scroll is an Ethereum Layer 2 scaling solution based on zero-knowledge proof technology, aiming to enhance the transaction throughput and speed of the Ethereum network. In contrast to Optimistic Rollup, Scroll achieves scalability through zero-knowledge proof technology and hardware-accelerated zero-knowledge proof generation and verification. It is dedicated to achieving bytecode-level EVM compatibility, allowing developers to build smart contracts directly using Solidity and Ethereum-related development tools without any modifications for deployment on Scroll.

According to Scroll’s official website, the core team consists of ten members distributed across Asia, the Americas, and Europe. These team members bring extensive experience in zkRollup development and industry operations, with most of them graduating from renowned universities and holding doctoral degrees.

The Scroll ecosystem is currently thriving, encompassing projects related to wallets, development tools, security infrastructure, and more. These projects aim to provide comprehensive support for projects throughout their design, development, operation, and security audit lifecycles. Currently, there are over 180 ecosystem projects on the Scroll mainnet.

1. Wallets

Scroll currently supports nearly all mainstream wallets, including Metamask, TrustWallet, MathWallet, TokenPocket, WalletConnect, Binance Chain Wallet, SafePal Wallet, OKX Wallet, Versa Wallet, and more.

2. Cross-Chain Bridges

Scroll’s official cross-chain infrastructure includes Celer Network, Stargate, Orbiter Finance, Hop Protocol, LI.FI, Connext, and more. It also includes cross-chain liquidity protocols such as Synapse Protocol, Owlto Finance, a Layer 2 cross-chain bridge for Ethereum Layer 1 and Layer 2 — Pheasant Network, Symbiosis, Catalyst, and others.

3. DeFi

The Scroll ecosystem boasts a variety of established DeFi projects, including lending protocols like Aave, multi-chain DEX aggregator DODO, DEX SushiSwap, DEX aggregator OpenOcean, multi-chain DeFi protocol iZUMi Finance, DEX Syncswap, DeFi yield protocol Pendle Finance, lending protocol dForce, and innovative projects like MUX Protocol and GMX.

4. Other

In the realms of NFTs, gaming, and social platforms, the Scroll ecosystem includes projects like NFTScan, Web3 task platform QuestN, TaskOn, electronic signature platform EthSign, Galaxy Blitz, OmniKingdoms, and more.

What Sets Scroll’s Technology Apart?

1. Overall Architecture

Scroll’s architecture consists of three primary components:

Scroll Node: This component generates blocks on the Scroll network based on user transactions, submits these transactions to the Ethereum base layer, and handles message passing between Ethereum and Scroll.

Roller: The Roller is responsible for converting smart contracts into zkEVM circuits and subsequently generating proofs to demonstrate transaction correctness. Multiple Rollers exist in the Scroll network to process transactions in parallel and reduce proof generation time through hardware acceleration. Scroll’s compatibility extends to the bytecode level of the EVM, ensuring compatibility with the EVM’s bytecode processing.

Rollup and Bridge Contracts: These contracts provide data availability for Scroll transactions and verify the validity proofs generated by zkEVM. Scroll is connected to the Ethereum base layer through Rollup and Bridge contracts. Users can exchange messages between Ethereum and Scroll and transfer ERC-20 assets in either direction using gateway contracts.

Scroll’s Main Ethereum Deployed Contracts:

Gateway Routing Proxy Contract (ensures correct token mapping in cross-chain operations): 0xF8B1378579659D8F7EE5f3C929c2f3E332E41Fd6

Message Proxy Contract (for passing messages between L1 and L2): 0x6774Bcbd5ceCeF1336b5300fb5186a12DDD8b367

It’s worth noting that these contracts can be modified by the proxy admin and owner.

Furthermore, Scroll has implemented a whitelist function that can change gas fees for specific addresses within Scroll. The Scroll sequencer is currently centralized, allowing for the review of messages and transactions on the Scroll network, and there is a possibility to skip any message in the message queue and confirm a specific message directly.

2. Scroll zkEVM Workflow

After Scroll generates a block, it passes through a coordinator and multiple provers (Rollers) to generate aggregated proofs, which are then submitted to the Ethereum Rollup contract for verification. The detailed process is as follows:

The sequencer receives new transactions, and the virtual machine reads the bytecode associated with each transaction, generating an execution trace and sending it to the coordinator. Simultaneously, the sequencer submits transaction data to the Rollup contract.

Rollers convert the execution traces received from the coordinator into zkEVM circuits. Each step in the execution trace corresponds to a zkEVM circuit. For functions that are zk-unfriendly (e.g., hash and Keccak), Scroll constructs lookup tables to map the inputs and outputs of these functions in the execution trace to the lookup table, and additional circuits are used to verify the correctness of the lookup table. Rollers then generate proofs for these zkEVM circuits.

After generating the proofs, Rollers send them back to the coordinator. Every few blocks, the coordinator randomly assigns aggregation tasks to a Roller, which then aggregates proofs for multiple blocks into a single proof.

Finally, the coordinator submits the aggregated proof to the Rollup contract. The Rollup contract uses the aggregated proof to verify the correctness of the previously submitted state and transaction data, confirming the correctness of the block.

Scroll zkEVM Circuits and Audit

1. Key Circuits

zkEVM comprises numerous circuits, each responsible for checking a specific aspect of the EVM. These circuits are eventually aggregated or combined in some way to provide proof of transaction execution. The relationship between these circuits and the tables is shown in the following diagram:

There are some smaller sub-circuits, such as the ECDSA circuit and opcode-related sub-circuits, which do not interact with other tables and circuits in a way that affects the circuit’s combination. For clarity, they are not shown in the diagram.

EVM Circuit

The Ethereum Virtual Machine (EVM) is a state machine that defines the rules for valid state transitions within the Ethereum protocol. The EVM executes instructions (opcodes) to achieve these state transitions, producing an execution trace. The goal of the EVM circuit is to construct a constraint system that corresponds to the execution trace and can be proven using a zero-knowledge proof system.

The high-level design of the EVM circuit is somewhat similar to the design of the EVM itself, such as go-ethereum. In go-ethereum, the interpreter iterates through all the instruction opcodes on the execution trace. In each instruction, the interpreter helps to check relevant context information such as gas, stack, memory, and then sends the opcode to the JumpTable, which provides detailed instructions for the opcode’s execution.

Similarly, in the EVM circuit, Scroll constructs execution steps based on the steps in the execution trace and provides proofs for opcodes and execution context. For each execution step, a set of constraints is imposed to verify context information. For each opcode, a set of constraints is applied to verify the opcode’s behavior. In the execution trace, the same opcode should have the same constraints. Scroll uses selectors to “open” all steps with the same opcode in the execution trace and prove their behavior using the backend proof system.

State Circuit

During execution, all read and write operations of the EVM are recorded in the rw_table and ordered by the rw_counter variable. The purpose of the state circuit is to demonstrate the correct generation of the rw_table.

MPT Circuit

Merkle Patricia Tree is a key data structure used in the Ethereum storage layer. In Scroll’s zkevm-Circuits, the original MPT is modified to zkTrie, which is essentially a sparse binary Merkle Patricia Trie. In the zkevm-Circuits, Scroll uses the MPT table to track the state transitions of MPT operations step by step. The MPT table has the following layout:

The goal of the MPT circuit is to verify the correctness of the above MPT table, ensuring that each update recorded in the MPT table leads to a correct change. This means that for every update in the MPT table, the MPT circuit ensures that there is only one possible way to make changes. This prevents accidental or unauthorized changes and ensures the integrity and correctness of the MPT. Specifically, when the MPT changes due to updates to accounts or storage, the MPT circuit must prove that these updates are performed according to the specified rules and that the root hash correctly reflects the results of all changes.

Keccak Circuit

Scroll has implemented its own Keccak256 while adhering to NIST Keccak specifications and Keccak team specifications. The Keccak circuit is used to prove the correctness of the Keccak256 operation results. This circuit’s implementation is complex because the Keccak256 algorithm itself is zk-unfriendly.

Tx Circuit

The Tx circuit provides constraints for verifying transaction correctness. It mainly checks the following aspects of transactions:

1. Correctness of CallDataLength and cumulative CallDataGasCost: Verified by custom gates and looking up the last row of call data bytes in the tx table.

2. Correctness of TxSign and TxHash-related data: Verified by looking up RLP tables and Keccak tables.

3. Proof of “if tx_type is L1Msg, then msg_hash” correctness: Verified by looking up RLP tables.

4. Proper execution of tx signature through ECDSA and the ability to correctly recover the caller’s address from the ECDSA signature: Verified by looking up the sig table.

5. Correct transition behavior for tx id, cum_num_txs, call_data_length, and others.

6. Various basic constraints, such as boolean values for some indicator variables.

Bytecode Circuit

The EVM circuit needs to look up the bytecode information stored in the bytecode table. This ensures that the bytecode stored in the contract matches the bytes loaded from the table. The bytecode circuit’s purpose is to constrain the correctness of the bytecode table, including:

1. Constraints related to boundary behavior with tags (tag): Constraints for the first and last lines, transitions from tag == byte to header and vice versa, transitions from header to header, and more.

2. Constraints on code size: Calculating the length of bytecode based on the index of the last byte in the bytecode is constrained.

3. Constraints on code hash: Constraints for the behavior of bytes in the code hash, verified by looking up the Keccak table.

4. Ensuring the correctness of PUSH behavior: is_code = push_data_left == 0 (must be a boolean), and verifying the push data size for PUSH1-PUSH32 by looking up the push_table.

5. Ensuring the correct propagation of each line within bytecode.

2. Security Audit

Different blockchains have their own custom business modules that often modify the precompiled contracts and opcodes in the EVM. Scroll’s zkEVM, as a zero-knowledge proof-based Layer 2 scaling solution, uses circuits to reconstruct relevant opcodes and generate proofs based on execution traces, making the audit process significantly challenging. Beosin security experts have identified several main aspects of zkEVM security audits:

1. GAS: When zkEVM circuits generate proofs corresponding to execution traces, they simultaneously verify the correctness of gas consumption during transactions. If the circuit implementation frequently uses unconstrained free variables in opcode circuits, it may lead to proof generation failures or other unknown errors.

2. Memory Safety: Some zkEVM circuits are based on polynomial commitments, such as the KZG commitment used by Scroll. Polynomial calculations do not automatically align, so a lack of constraints in the circuit can lead to a discrepancy between the value range and the byte range in the computer program. In situations where some contract developers enable gas optimization, compact data alignment may result in memory safety issues, as seen with the BYTE_C4096 constant polynomial in Polygon zkEVM. Polynomials allow parameter values to exceed the maximum byte value of 255, which could potentially be exploited by malicious Sequencers on exchanges using an Automated Market Maker (AMM) model. Ultimately, these vulnerabilities arise from inconsistencies between the numerical validity range represented by the circuit and the variable value range in the program. For example, Beosin security researchers discovered a vulnerability (CVE-2023–33252) in the Snarkjs library.

3. Opcode Security: In the implementation of zkEVM opcodes, there are common issues related to under-constraining and precision, especially in precision problems. For example, when the underlying circuit compares two numbers and the precision of the comparison operation in the program is one byte, the circuit constraints must specify the value range; otherwise, the precision of the circuit’s operations will far exceed the program’s precision, leading to incorrect results.

4. Support for Secure EIPs: Support for security-focused EIPs such as EIP-2 and EIP-155.

5. Sequencer Centralization Issue: Currently, all proofs generated by Scroll rely on execution traces generated by the Sequencer. If the Sequencer behaves maliciously, zkEVM cannot guarantee the security of user assets.

6. Compatibility Issues: zkEVM generates circuit proofs based on execution traces and verifies them in contracts. Even minor upgrades by the Sequencer may lead to significant differences in execution traces generated at the low-level language level.

Scroll’s Future Prospects

1. Scroll currently uses a two-layer KZG version of the Halo2 proof system and employs GPU hardware acceleration to speed up proof generation. The current bottleneck has shifted to witness generation and data replication. Additionally, the centralization degree of Rollers and hardware operating costs are aspects that Scroll needs to consider when developing a multi-stage proof system in the future.

2. Because EVM execution traces are dynamic and may have various circuit constraints and scales, to accommodate dynamic execution traces, each execution trace step needs to satisfy the largest circuit scale, causing additional memory waste.

3. Scroll’s Rollers are currently expected to profit from network transaction fees. However, the current number of users and transaction fees on the Scroll network may not cover the operating costs of Rollers and sequencers. In the future, how Scroll’s network provides economic incentives to attract users and maintain network stability is a question that needs consideration.

Currently, Beosin also supports audits of zk projects. For more information on hardcore security research related to zk, you can refer to the following articles:

1. Beosin’s Research | Transaction Malleability Attack of Groth16 Proof
2. Exploring Tornado Cash In-Depth to Reveal Malleability Attacks in ZKP Projects

Contact

If you need any blockchain security services, welcome to contact us:

Official Website EagleEye KYT Twitter Telegram Linkedin