Scroll Technology Analysis Can the unique zkEVM circuit drive the wave of Layer2?

Exploring Scroll Technology Evaluating the Impact of zkEVM Circuit on Driving the Layer2 Revolution

On October 10th at 14:00, the Ethereum Layer 2 solution Scroll generated its first block on the mainnet, marking the successful launch of Scroll’s mainnet. As of October 25th, over 7600 ETH have entered 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, while announcing the launch of the mainnet, Scroll reaffirmed its commitment to open source and decentralization. In the next phase, Scroll will focus on building a decentralized proof-of-stake network and orderer. In this article, we will analyze Scroll’s architecture and technology in detail, helping everyone understand the current network status and future development direction of Scroll. We will also explain Scroll’s zkEVM circuits and auditing knowledge to enhance the security measures of zk projects.

(Image: Scroll Technical Analysis: Can the unique zkEVM circuit drive the Layer2 wave? – Link to image)

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

• Interview with Cartridge Co-founder How to create an ‘on-chain Steam’?
• Why is it said that the abstraction of the entire chain account is the final piece of the puzzle for EIP-4337?
• DTCC pours cold water on the hot speculation, Bitcoin spot ETF still subject to SEC’s decision.

Scroll is an Ethereum Layer 2 scaling solution based on zero-knowledge proof technology, aiming to improve the transaction throughput and speed of the Ethereum network. Compared to Optimistic Rollup, Scroll achieves scalability through zero-knowledge proofs and hardware-accelerated generation and verification of zero-knowledge proofs. It is committed to achieving bytecode-level EVM compatibility, which means 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 Scroll website, the core team consists of 10 members distributed across Asia, the Americas, and Europe. The team members have extensive experience in zkRollup development and industry operations, with most of them graduating from well-known universities and possessing doctoral degrees.

Currently, the Scroll ecosystem is highly diverse, with infrastructure projects covering wallets, development tools, security facilities, and more. The aim is to provide comprehensive support for projects in design, development, operation, and security auditing throughout their lifecycle. Currently, the Scroll mainnet has over 180 ecosystem projects.

1. Wallets
Scroll currently supports almost all mainstream wallets, including Metamask, TrustWallet, MathWallet, TokenPocket, WalletConnect, Binance Chain Wallet, SafeLianGuail Wallet. In addition, there are also Scroll ecosystem wallets such as 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, etc. It also includes cross-chain liquidity protocols such as Synapse Protocol, Owlto Finance focusing on Layer 2 cross-chain bridges, Pheasant Network, Symbiosis, Catalyst, providing Ethereum Layer 1 to Layer 2 cross-chain bridges.

3. DeFi
The Scroll ecosystem includes many 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, leveraged trading aggregator MUX Protocol, and innovative projects like GMX that have not been widely adopted yet.

4. Other

In terms of NFTs, gaming, and social media, Scroll’s other projects include NFTScan, Web3 task platform QuestN, TaskOn, electronic protocol signing platform EthSign, Galaxy Blitz, OmniKingdoms, and other online blockchain games.

What sets Scroll apart in terms of technology?

1. Overall Architecture

Scroll’s architecture consists of the following three main components:

Scroll Node: It generates the blocks of the Scroll network based on user transactions, submits these transactions to the Ethereum base layer, and handles messaging between Ethereum and Scroll.

Roller: The Roller component converts smart contracts into zkEVM circuits, generates proofs to validate the correctness of transactions. Multiple Rollers exist in the Scroll network, processing transactions in parallel and utilizing hardware acceleration to reduce proof generation time. Scroll achieves compatibility with EVM at the bytecode level by directly proving the correctness of EVM bytecode execution.

Rollup and Bridge Contracts: These contracts provide data availability for Scroll’s transactions and verify the validity proofs generated by zkEVM. Scroll connects to the Ethereum base layer through Rollup and Bridge contracts. Using these contracts, users can exchange arbitrary messages between Ethereum and Scroll and transfer ERC-20 assets in either direction through gateway contracts.

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

Main contracts deployed by Scroll on Ethereum:

Gateway Router Proxy Contract (ensuring correct mapping of tokens in cross-chain operations): 0xF8B1378579659D8F7EE5f3C929c2f3E332E41Fd6

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

It is worth noting that the above contracts can be modified by the proxy administrator and the owner. In addition, Scroll has a whitelist feature that allows changing the gas fees for specific addresses in Scroll. The Scroll sorter is currently centralized, enabling the review of messages and transactions in the Scroll network, and it may be possible 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 the coordinator and multiple verifiers (Rollers) to generate an aggregate proof, which is then submitted to the Rollup contract on Ethereum for verification. The detailed process is as follows:

1. After the sorter obtains a new transaction, the virtual machine will read the bytecode related to that transaction, generate the corresponding execution trace, and send it to the coordinator. At the same time, the sorter also submits the transaction data to the Rollup contract.

2. The roller first converts the execution trace received from the coordinator into zkEVM circuits. Each step of the execution trace has a corresponding zkEVM circuit. For functions that are not zk-friendly (such as hash, Keccak), Scroll constructs a lookup table to map the inputs and outputs of such functions in the execution trace to the lookup table. Additional circuits are used to verify the correctness of the lookup table. Then, the roller generates corresponding proofs for these zkEVM circuits.

3. After generating the proofs, the roller sends them back to the coordinator. After several blocks, the coordinator randomly assigns aggregated tasks to a roller, and then the roller aggregates the proofs of several blocks into a single proof.

4. Finally, the coordinator submits the aggregated proof to the Rollup contract, which verifies the correctness of the previously submitted state and transaction data to the Rollup contract based on the aggregated proof.

Scroll zkEVM Circuits and Audit

1. Main Circuits

zkEVM consists of many circuits, each responsible for checking a certain aspect of EVM. These circuits are eventually aggregated or combined in some way to complete the proof of transaction execution. The following diagram shows the relationship between these circuits and tables:

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 combination of circuits. Therefore, 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 in the Ethereum protocol. This means it defines a deterministic function that calculates the next valid EVM state based on the current EVM state. The execution part of the EVM uses opcodes to achieve these state transitions, resulting in 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 backend zero-knowledge proof system.

The high-level design idea of the EVM circuit is somewhat similar to the design of the EVM itself (e.g., go-ethereum). In go-ethereum, the interpreter loops through all the instruction opcodes on the execution trace. In each instruction, the interpreter helps check the relevant contextual information, such as gas, stack, memory, and then sends the opcode to the JumpTable to obtain the detailed operation to be executed for that opcode.

Similarly, in the EVM circuit, Scroll constructs execution steps based on the steps in the execution trace and provides proofs for the opcodes and execution context. 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 check the behavior of the opcode. In the execution trace, the same opcode should have the same constraints. Scroll uses selectors to “open” all the steps of the same opcode in the execution trace and proves their behavior using the backend proof system.

State Circuit

During the execution process, all read and write operations of the EVM are recorded in the rw_table and sorted according to the counter variable rw_counter. The purpose of the state Circuit is to prove the correct generation of the rw_table.

MPT Circuit

Merkle Patricia Tree (MPT) is one of the key data structures 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 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 aforementioned MPT table, ensuring that every update recorded in the MPT table results in the correct change. To achieve this goal, the MPT circuit uses a constraint system to enforce the unique changes of the MPT. This means that for every update in the MPT table, the MPT circuit ensures only one possible way of change. This prevents accidental or illegal changes and ensures the integrity and correctness of the MPT. Specifically, when the MPT undergoes a change due to account or storage updates, the MPT circuit must prove that this update will result in the correct root change. This means that the MPT circuit needs to verify if the update operation follows the specified rules and ensure that the root hash correctly reflects the results of all changes.

Keccak Circuit

Scroll has implemented their own Keccak256 while adhering to the NIST Keccak specification and the Keccak team’s specification. Keccak circuit is used to prove the correctness of the Keccak256 operation result. The implementation of this part of the circuit is complex mainly because the keccak256 algorithm itself is zk-unfriendly.

Tx Circuit

The Tx circuit provides the constraint conditions to verify the correctness of a transaction. It primarily checks the following aspects of a transaction:

1. The correctness of CallDataLength and accumulated CallDataGasCost: by using custom gates and looking up the last row of call data bytes in the tx table;

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

3. The proof of “if tx_type is L1Msg, then msg_hash”: by looking up the RLP table for verification;

4. Performing ECDSA signature verification correctly and being able to recover the caller address from the ECDSA signature: by looking up the sig table for verification;

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

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

Bytecode Circuit

The EVM circuit needs to look up the bytecode table that stores 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 constrain the correctness of the aforementioned bytecode table. This includes:

1. Constraints related to the behavior at the boundaries of labels (tags): constraints on the first and last rows, transitions from tag==byte to header, and vice versa, transitions from header to header;

2. Code size constraint: including calculating the length of bytecode by constraining the index of the last byte of bytecode;

3. Code hash constraint: correctly constrain the RLC behavior of bytes in the code hash and verify the code hash by looking up the Keccak table;

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

5. Ensure the correct propagation of each line in a bytecode.

2. Security Audit

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

1. GAS: When the zkEVM circuit generates the proof corresponding to the execution trace, it also verifies the correctness of gas consumption. If unconstrained free variables are used frequently in the implementation circuits of opcodes, it may cause proof generation failure or other unknown errors.

2. Memory safety: Some zkEVM circuit implementations are based on polynomial commitments, such as the KZG commitments used by Scroll. Polynomial calculations do not automatically align, so if the circuits lack constraints, the value range may be inconsistent with the byte range in computer programs. In the case of some contract developers enabling gas optimization, the compact arrangement of data may result in memory safety issues, such as the BYTE_C4096 constant polynomial in Polygon zkEVM. Polynomial allows the value range of parameters to exceed the maximum value range of bytes 255, which may allow malicious sequencers to forge parameters for profit in some exchanges adopting the AMM mode. Essentially, this class of vulnerabilities is caused by the inconsistency between the value range represented by the circuit and the variable value range of the program, such as the vulnerability CVE-2023-33252 discovered by Beosin security researchers in the Snarkjs library.

3. Opcode security: When implementing zkEVM opcodes, there are generally under-constrained and other security issues, especially precision issues. For example, when the underlying circuit compares two numbers, if the precision of the comparison operation in the program is one byte, the circuit constraints need to specify the value range, otherwise the precision of the computation in the circuit will far exceed the program’s precision, resulting in incorrect results.

4. Support for secure EIPs: Support for security-oriented EIPs such as EIP-2, EIP-155.

5. Sequencer centralization issue: Currently, all proofs generated by Scroll rely on the execution traces generated by the Sequencer. If the Sequencer behaves maliciously, zkEVM cannot protect user asset security.

6. Compatibility issues: zkEVM generates circuit proofs based on execution traces and verifies them in contracts. Even minor upgrades to the Sequencer can cause significant differences in the execution traces generated at the lower-level language.

The Future Outlook of Scroll

1. Scroll currently uses the two-layer KZG version of the Halo2 proof system, utilizing GPU hardware acceleration to speed up proof generation. The current bottleneck lies in witness generation and data replication. Additionally, the level of centralization and hardware operational costs of Roller are also factors that Scroll needs to consider in its future development of multi-stage proof systems.

2. Due to the dynamic nature of EVM execution traces, there are various circuit constraints and scales to consider. Currently, to accommodate the dynamic changes in execution traces, each step of the trace must meet the maximum 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 on the Scroll network are unable to cover the operational costs of Roller and the sorter. In the future, how Scroll network can provide economic incentives to attract users and maintain network stability is a question that needs careful consideration.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!