Original Title: "Former Arbitrum Technical Ambassador Interprets Arbitrum's Component Structure (Part 1)"

Original Author: Luo Benben, former Arbitrum Technical Ambassador, Geek Web3 Contributor

This article is a technical interpretation of Arbitrum One by Luo Benben, former technical ambassador of Arbitrum and co-founder of Goplus Security, an intelligent contract automation audit company.

Due to the lack of professional interpretation of Arbitrum and even OP Rollup in the Chinese community's articles or materials related to Layer2, this article attempts to fill this gap by popularizing the operating mechanism of Arbitrum. As Arbitrum's structure is too complex, the entire article exceeds 10,000 words on the basis of simplification as much as possible, so it is divided into two parts. It is recommended to be collected and forwarded as a reference material!

Rollup Sorter Overview

The principle of Rollup expansion can be summarized into two points.

Cost optimization: Transfer most of the computing and storage tasks to L1 off-chain, that is, L2. L2 is mostly a chain running on a single server, namely a sequencer/operator chain.

The sorter visually resembles a centralized server and sacrifices "decentralization" for the advantages of TPS and cost in the "Blockchain Impossible Triangle". Users can use L2 to replace Ethereum to process transaction instructions, which is much cheaper than trading on Ethereum.

(Source: BNB Chain)

Security Guarantee: The transaction content and post-transaction state on L2 will be synchronized to Ethereum L1, and the validity of state transitions will be verified through contracts. At the same time, Ethereum will retain the historical records of L2. Even if the sorter permanently crashes, others can restore the entire L2 state through the records on Ethereum.

Fundamentally speaking, the security of Rollup is based on Ethereum. If the sorter does not know the private key of an account, they cannot initiate transactions on behalf of that account or tamper with the account's asset balance (even if they do, it will be quickly detected).

Although the sorter, as the central hub of the system, has a centralized color, in mature Rollup solutions, the centralized sorter can only implement soft malicious behaviors such as transaction review or malicious shutdown, but in ideal Rollup solutions, there are corresponding means to restrain (such as mandatory withdrawal or sorting proof and other anti-review mechanisms).

(The forced withdrawal function set in the contract source code of Loopring Protocol on L1 for users to call)

The state verification method to prevent Rollup sorter from cheating is divided into two categories: Fraud Proof and Validity Proof. The Rollup scheme that uses Fraud Proof is called OP Rollup (Optimistic Rollup, OPR), while the Rollup that uses Validity Proof is often referred to as ZK Rollup (Zero-knowledge Proof Rollup, ZKR) due to some historical baggage, instead of Validity Rollup.

Arbitrum One is a typical OPR that deploys contracts on L1 and does not actively verify the data submitted, optimistically assuming that the data is correct. If there are errors in the submitted data, the validator nodes on L2 will actively initiate challenges.

Therefore, the OPR also implies a trust assumption: there is always at least one honest L2 validator node at any given time. On the other hand, the ZKR contract actively and cost-effectively verifies the data submitted by the sorter through cryptographic calculations.

(Optimistic Rollup operation mode)

(ZK Rollup Operating Mechanism)

This article will provide an in-depth introduction to the leading project in optimistic Rollup in Chinese crypto industry - Arbitrum One, covering all aspects of the system. After reading it carefully, you will have a profound understanding of Arbitrum and optimistic Rollup/OPR.

Arbitrum's Core Components and Workflow

Core Contract:

Arbitrum's most important contract packages include SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. Details will be provided later.

排序器 Sequencer：

Sequencer:

Receive user transactions, sort them, calculate the transaction results, and quickly (usually <1s) return the receipt to the user. Users can often see their transactions on the L2 chain within a few seconds, just like on a Web2 platform.

Meanwhile, the sorter will also broadcast the latest generated L2 Block in real-time under the Ethereum chain, and any Layer2 node can receive it asynchronously. However, at this time, these L2 Blocks do not have finality and can be rolled back by the sorter.

Every few minutes, the sorter compresses the sorted L2 transaction data and aggregates it into batches, which are then submitted to the SequencerInbox contract on Layer1 to ensure data availability and the operation of the Rollup protocol. Generally speaking, L2 data submitted to Layer1 cannot be rolled back and can have finality.

From the above process, we can summarize that: Layer2 has its own node network, but the number of nodes is scarce and generally lacks the consensus protocol commonly used in public chains, so security is poor and must rely on Ethereum to ensure the reliability of data publishing and the effectiveness of state transitions.

Arbitrum Rollup Protocol:

Define the structure of RBlock, the continuation method of the chain, the release of RBlock, and the challenge mode process of a series of contracts that define the Rollup chain. Note that the Rollup chain mentioned here is not the Layer2 ledger that everyone understands, but an abstract "chain-like data structure" independently set up by Arbitrum One to demonstrate the fraud proof mechanism.

The result of an RBlock can contain multiple L2 blocks, and the data can also vary. The data entity of the RBlock is stored in a series of contracts in RollupCore. If there is an issue with an RBlock, the Validator will challenge the submitter of that RBlock.

Validator:

ArbOS, Geth, WAVM：

Although the specific gas price calculation process is quite complex, users do not need to be aware of these details and can clearly feel that Rollup transaction fees are much cheaper than ETH mainnet. 

Transaction Inputs -> STF -> State Outputs. The inputs are already determined, and the STF is constant, so the output results are also determined. The fraud proof and Arbitrum Rollup protocol system publishes the output state root in the form of RBlock (aka assertion) to L1 and conducts optimistic proof.

There are input data published by the sorter and output states published by the validator on L1. Let's consider carefully whether it is necessary to publish the Layer2 state on the chain.

Because the input completely determines the output, and the input data is publicly visible, submitting the output result-state seems redundant? However, this idea ignores the fact that there needs to be a state settlement between the L1-L2 systems, that is, the withdrawal behavior from L2 to L1 direction requires proof of the state. 

When building Rollup, the most core idea is to put most of the computation and storage on L2 to avoid the high cost of L1. This also means that L1 does not know the state of L2, it only helps the L2 sequencer to publish the input data of all transactions, but is not responsible for calculating the state of L2.

而提现行为，本质上是依照 L2 给出的跨链消息，从 L1 的合约⾥解锁相应资金，划转到用户的 L1 账户中或完成其他事情。

The withdrawal behavior essentially unlocks the corresponding funds from the L1 contract and transfers them to the user's L1 account or completes other actions, based on the cross-chain message provided by L2.

At this point, the contract on Layer1 will ask: What is your status on Layer2 and how do you prove that you really own the assets you want to transfer? The user needs to provide the corresponding Merkle Proof, etc.

Therefore, if we build a Rollup without withdrawal function, it is theoretically possible to not synchronize the state with L1 and not require a fraud proof or other state proof systems (although it may bring other problems). However, in practical applications, this is obviously not feasible. 

In the so-called optimistic proof, the contract will not check whether the output state submitted to L1 is correct, and optimistically assume that everything is accurate and error-free. The optimistic proof system assumes that there is at least one honest validator at any time, and if an erroneous state appears, it will be challenged through fraud proof.

The advantage of this design is that there is no need to actively verify every RBlock published to L1, avoiding gas waste. In fact, for OPR, it is also unrealistic to verify each assertion, because each RBlock contains one or more L2 blocks. To re-execute each transaction on L1 for each RBlock is no different from directly executing L2 transactions on L1, which loses the meaning of Layer2 expansion.

There is no such problem with ZKR because ZK Proof has succinctness, which only requires verifying a very small proof without actually executing the many transactions behind the proof. Therefore, ZKR is not run optimistically, and every time a state is released, the Verifier contract performs mathematical verification.

Although fraud proof cannot have the high simplicity like zero-knowledge proof, Arbitrum uses a "multi-round partition-single-step proof" round-robin interactive process, and ultimately only needs to prove a single virtual machine opcode, which is relatively low cost.

Rollup Protocol

Let's first take a look at the entry points for initiating challenges and launching proofs, that is, how the Rollup protocol works.

Rollup protocol's core contract is RollupProxy.sol, which uses a rare double-proxy structure, where one proxy corresponds to two implementations: RollupUserLogic.sol and RollupAdminLogic.sol. This ensures consistent data structure and is currently not easily parsed by tools such as Scan.

Additionally, the ChallengeManager.sol contract is responsible for managing challenges, while the OneStepProver series of contracts are used to determine fraud proofs.

Sorry, I am unable to translate the given content as it does not contain any Chinese characters. Please provide me with the Chinese content that needs to be translated.

In RollupProxy, records a series of RBlocks (aka assertions) submitted by different Validators, represented by the blocks in the following figure: green-confirmed, blue-unconfirmed, yellow-falsified.

RBlock contains the final state after one or more L2 blocks have been executed since the previous RBlock. These RBlocks form a Rollup Chain in form, which is distinct from the L2 ledger itself. In an optimistic scenario, this Rollup Chain should not have any forks, as forking would imply that validators have submitted conflicting Rollup Blocks.

To make or endorse a claim, the verifier needs to stake a certain amount of ETH and become a Staker. In the event of a challenge/fraud proof, the loser's stake will be confiscated, which is the economic basis for ensuring the honesty of the verifier's behavior.

The blue block with number 111 in the bottom right corner of the picture will eventually be proven false, because its parent block with number 104 is incorrect (shown in yellow).

Additionally, Validator A proposed Rollup Block 106, which was challenged by B who disagreed.

After B initiates the challenge, the ChallengeManager contract is responsible for verifying the segmentation process of the challenged steps:

1. Segmentation is a process of mutual interaction between two parties, where one party segments the historical data contained in a Rollup Block, and the other party identifies which part of the data segment is problematic. It is similar to a binary search (actually N/K) process of progressively narrowing the range.

2. Afterwards, you can continue to locate which transaction and result have issues, and further narrow down to a disputed machine instruction within that transaction.

3. The ChallengeManager contract only checks whether the "data segment" generated by subdividing the original data is valid.

4. When the challenger and the challenged party locate the machine instruction to be challenged, the challenger calls oneStepProveExecution() to send a single-step fraud proof, proving that the execution result of this machine instruction is problematic.

Single-step proof

Single-step proof is the core of fraud proof for the entire Arbitrum. Let's take a look at what specific content the single-step proof proves.

This requires an understanding of WAVM, Wasm Arbitrum Virtual Machine, which is a virtual machine compiled jointly by the ArbOS module and the Geth (Ethereum client) core module. Due to the many stark differences between L2 and L1, the original Geth core must undergo lightweight modifications and work in conjunction with ArbOS.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia