On October 10th, at 14:00, the Ethereum Layer 2 solution Scroll mainnet generated its first block, marking the successful launch of Scroll’s mainnet. As of October 25th, over 7600 ETH has been bridged into the Scroll network through cross-chain bridges, and 24 decentralized trading platforms have gone live on the Scroll mainnet, with a total TVL of approximately $10 million.

On October 17th, Scroll officially announced the launch of its mainnet while continuing to uphold its commitment to open source and decentralization. In the next phase, Scroll will focus on building a decentralized proof-of-stake network and sorter. In this article, we will provide a detailed analysis of Scroll’s architecture and technology to help everyone understand the current network status and future development direction of Scroll. We will also explain Scroll’s zkEVM circuit and audit knowledge to strengthen the security measures for zk projects.

Who is Scroll, the driving force of the Layer2 wave?

Scroll is an Ethereum Layer 2 scaling solution based on zero-knowledge proof technology, aimed at improving the transaction throughput and speed of the Ethereum network. Compared to Optimistic Rollup, Scroll achieves scalability through zero-knowledge proofs and accelerates the generation and verification of zero-knowledge proofs through hardware acceleration. It is committed to achieving bytecode-level EVM compatibility. This means that developers can directly use Solidity and Ethereum-related development tools to build smart contracts and deploy them on Scroll without any modifications.

According to the official website of Scroll, there are currently 10 core members in the Scroll team, distributed across Asia, America, and Europe. The team members have rich experience in zkRollup development and industry operations, with most of them graduating from prestigious universities and holding PhD degrees.

Currently, the Scroll ecosystem is very rich, with infrastructure projects including wallets, development tools, security facilities, and more. The goal is to provide comprehensive support to projects throughout the entire lifecycle, from design, development, operation, to security auditing. Currently, there are over 180 ecosystem projects on the Scroll mainnet.

1. Wallet
   Scroll currently supports almost all mainstream wallets: Metamask, TrustWallet, MathWallet, TokenPocket, WalletConnect, Binance Chain Wallet, SafePal Wallet. In addition, the Scroll ecosystem wallet also includes OKX Wallet, Versa Wallet, and so on.

2. Cross-Chain Bridge
   Scroll’s official cross-chain infrastructure includes Celer Network, Stargate, Orbiter Finance, Hop Protocol, LI.FI, Connext, etc. Additionally, it also includes cross-chain liquidity protocol Synapse Protocol, Owlto Finance focusing on Layer 2 cross-chain bridges, Ethereum Layer 1 and Layer 2 cross-chain bridge Pheasant Network, Symbiosis, Catalyst, etc.

3. DeFi
   In the Scroll ecosystem, there are several well-established DeFi projects, including lending protocol Aave, multi-chain DEX aggregator DODO, DEX SushiSwap, DEX aggregator OpenOcean, multi-chain DeFi protocol iZUMi Finance, DEX Syncswap, yield protocol Pendle Finance, lending protocol dForce, and leverage trading aggregator MUX Protocol. There are also innovative projects like GMX that have not been widely adopted.

4. Others
   In terms of NFT, gaming, and social aspects, other projects in the Scroll ecosystem include NFTScan, Web3 task platform QuestN, TaskOn, electronic protocol signing platform EthSign, Galaxy Blitz, OmniKingdoms, and other online blockchain games.

What sets Scroll technology apart from others?

1. Overall Architecture

Scroll’s architecture consists of three components:

Scroll Node: It 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 then generates proofs to prove the correctness of transactions. There are multiple Rollers in the Scroll network, which process transactions in parallel and accelerate proof generation through hardware. Scroll achieves bytecode-level compatibility with EVM by directly proving the correctness of EVM bytecode processing.

Rollup and Bridge Contract: These contracts provide data availability for Scroll transactions and verify the validity proofs generated by zkEVM. It can be said that Scroll is connected to the Ethereum base layer through Rollup and Bridge contracts. Through these contracts, users can exchange arbitrary messages between Ethereum and Scroll, and transfer ERC-20 assets in either direction with the help of gateway contracts.

source: https://scroll.mirror.xyz/nDAbJbSIJdQIWqp9kn8J0MVS4s6pYBwHmK7keidQs-k

Scroll is the main contract deployed on the Ethereum blockchain：

Gateway Routing Proxy Contract (Ensuring correct mapping of tokens in cross-chain operations)：0xF8B1378579659D8F7EE5f3C929c2f3E332E41Fd6

Message Proxy Contract (Transmitting messages between L1 and L2)：0x6774Bcbd5ceCeF1336b5300fb5186a12DDD8b367

It is worth noting that these contracts can be modified by the proxy admin and owner. Additionally, Scroll has incorporated a whitelist function that enables the adjustment of gas fees for specific addresses within Scroll. Currently, the Scroll sequencer operates in a centralized manner, which permits the review of messages and transactions on the Scroll network. Moreover, there is a possibility to bypass any message in the message queue and directly confirm a specific message.

2. Scroll zkEVM workflow

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

1、The sequencer receives new transactions. 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.

2、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 not zk-friendly (such as hash and Keccak), Scroll constructs lookup tables to map the inputs and outputs of these functions in the execution trace to the lookup table. Additional circuits are used to verify the correctness of the lookup table. Rollers then generate proofs for these zkEVM circuits.

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

4、Lastly, the coordinator submits the aggregated proof to the Rollup contract. The Rollup contract uses this proof to verify the correctness of the previously submitted state and transaction data, thereby confirming the correctness of the block.

Scroll zkEVM Circuits and Audit

1. Main Circuits

zkEVM consists of multiple circuits, each tasked with verifying a specific aspect of the EVM (Ethereum Virtual Machine). These circuits are eventually combined or aggregated to generate proof of transaction execution. The diagram below illustrates the relationship between these circuits and the tables.

There are smaller sub-circuits, such as the ECDSA circuit and opcode-related sub-circuits, that do not interact with other tables and circuits in a way that affects the circuit’s combination. These sub-circuits are omitted from the diagram for clarity.

EVM Circuit

The Ethereum Virtual Machine (EVM) is a state machine that establishes the rules for valid state transitions within the Ethereum protocol. It executes instructions (opcodes) to achieve these transitions and generates an execution trace. The objective of the EVM circuit is to create a constraint system that represents the execution trace and can be verified using a zero-knowledge proof system.

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

Similarly, in EVM circuits, Scroll constructs execution steps based on the execution trace and provides proofs for opcodes and execution contexts. For each execution step, a set of constraints is applied to check the contextual information. For each opcode, a set of constraints is applied to verify its behavior. Within 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 uses the backend proof system to prove their behavior.

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 accurate generation of the rw_table.

MPT Circuit

The Merkle Patricia Tree (MPT) is a key data structure used in the Ethereum storage layer. In Scroll’s zkevm-Circuits, the MPT is modified to zkTrie, which is essentially a sparse binary Merkle Patricia Trie. In zkevm-Circuits, Scroll utilizes 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 accuracy of the MPT table mentioned above. It ensures that each update recorded in the MPT table results in a correct change. This means that for every update, the MPT circuit guarantees that there is only one possible way to make changes. This prevents accidental or unauthorized modifications and ensures the integrity and accuracy of the MPT. Specifically, when the MPT undergoes changes due to updates in accounts or storage, the MPT circuit must prove that these updates are carried out according to the specified rules. Additionally, it must demonstrate that the root hash accurately reflects the results of all the changes.

Keccak Circuit

Scroll has implemented their own version of Keccak256, following the NIST Keccak specification and the Keccak team’s specification.

And the Keccak circuit is used to prove the correctness of the Keccak256 operation. The implementation of this circuit is complex, mainly because the keccak256 algorithm itself is zk-unfriendly.

Tx Circuit

The Tx circuit provides constraints to validate the correctness of a transaction. It primarily checks the following aspects of the transaction:

1. The correctness of CallDataLength and cumulative CallDataGasCost: Determine the custom gate and find the last row of call data bytes in the tx table;

2. The correctness of TxSign and TxHash related data: Search the RLP table and Keccak table;

3. Prove the correctness of “if tx_type is L1Msg, then msg_hash”: Verify by searching the RLP table;

4. Execute tx signature correctly using ECDSA and recover the caller’s address correctly from the ECDSA signature: Verify by searching the sig table;

5. The correct transitional behavior of tx id, cum_num_txs, and call_data_length;

6. Some basic constraints, such as Boolean values of certain indicator variables.

Bytecode Circuit

EVM circuits need to search for a bytecode table that contains the correct bytecode information. This ensures that the bytes stored in the contract match the bytes loaded from the table. The purpose of the bytecode circuit is to enforce the correctness of the bytecode table. This includes:

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

2. Constraints on code size: Including the calculation of the bytecode length through the constraint of the index of the last byte of the bytecode;

3. Constraints on code hash: Correctly constraining the RLC behavior of bytes in the code hash and verifying the code hash by looking up the Keccak table;

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

5. Ensuring correct propagation in each line of a bytecode.

2. Security Audit

Different chains have their own custom business module functions, which usually modify the precompiled contracts and opcodes in the EVM. Among them, Scroll zkEVM is a second-layer scaling solution based on zero-knowledge proofs. This solution reconstructs the relevant opcodes using circuits and generates proofs based on execution traces. This complex implementation greatly increases the difficulty of auditing. After evaluation by Beosin security experts, the security audit of zkEVM mainly focuses on the following aspects:

1. GAS：When generating proofs for the execution trace of the zkEVM circuit, it also verifies the correctness of gas consumption for transactions. If unconstrained free variables are frequently used in the implementation circuit of the opcodes, it may result in proof generation failure or other unknown errors.

2. Memory Safety: Some zkEVM circuits are based on polynomial commitments, such as the KZG commitment used by Scroll. However, polynomial calculations do not automatically align, so if the circuit lacks constraints, it can result in a value range inconsistent with the byte range in computer programs. In some cases, when contract developers enable gas optimization, the compact arrangement of data can lead to memory safety issues, such as the BYTE_C4096 constant polynomial in Polygon zkEVM. Polynomials allow parameter values to exceed the maximum byte value range of 255, which can potentially enable malicious sequencers to manipulate parameters for profit in some exchange platforms that adopt the AMM model. Essentially, these types of vulnerabilities arise from inconsistencies between the numerical validity range represented by the circuit and the variable value range of the program. An example is the vulnerability CVE-2023-33252 discovered by Beosin security researchers in the Snarkjs library.

3. Opcode Security: When implementing zkEVM opcodes, there are common security issues, especially regarding precision. For example, when comparing two numbers in the underlying circuit, if the precision of the comparison operation in the program is 1 byte, the circuit constraints need to specify the value range. Otherwise, the precision of the operations in the circuit will 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. Centralization issue in Sequencer: Currently, all proofs generated by Scroll depend on the execution trace generated by Sequencer. If Sequencer behaves maliciously, zkEVM cannot guarantee the security of user assets.

6. Compatibility issue: zkEVM generates circuit proofs based on the execution trace and verifies them in the contract. Even minor upgrades in Sequencer may result in significant differences in the execution trace generated at the underlying language level.

Scroll’s Future Outlook

1. Scroll currently adopts a two-layer KZG version of the Halo2 proof system, using GPU hardware acceleration to speed up proof generation. The bottleneck has now shifted to witness generation and data replication. In addition, the centralization level and hardware operating costs of Roller are also aspects that Scroll needs to consider for the future development of multi-stage proof systems.

2. Because the EVM execution trace is dynamically changing, there are various circuit constraints and scales. Currently, to accommodate the dynamically changing execution trace, each step of the execution trace needs to satisfy the largest circuit scale, resulting in additional memory waste.

3. Scroll’s Roller is currently expected to profit from network transaction fees. However, the current number of users and transaction fees in the Scroll network cannot cover the operating costs of Roller and the sequencer. In the future, how the Scroll network provides economic incentives to attract users and maintain stable network operation is a question that needs to be considered.

Currently, Beosin also supports the audit of the zk project. For hardcore security research on zk, you can read the following articles: 1. Transaction Malleability Attack of Groth16 Proof; 2. Exploring Tornado Cash In-Depth to Reveal Malleability Attacks in ZKP Projects.

Beosin, as a globally leading blockchain security company, has established branches in more than 10 countries and regions worldwide. Our services cover code security audits before project launch, security risk monitoring, early warning and prevention during project operation, asset recovery for stolen virtual currencies, and secure compliance services such as KYT/AML. We provide a one-stop solution for blockchain security products and services. Currently, we have provided security technology services to over 3000 blockchain enterprises globally and audited more than 3000 smart contracts. Feel free to contact us.

Disclaimer：

1. This article is reprinted from [Beosin]. All copyrights belong to the original author [Beosin]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.