Former Arbitrum Tech Ambassador Explains Arbitrum's Component Architecture (Part 1)
TechFlow Selected TechFlow Selected
Former Arbitrum Tech Ambassador Explains Arbitrum's Component Architecture (Part 1)
A Guide to Understanding How Arbitrum Works
Navigating Web3 tides with focused insightsAuthor: Luo Benben, Former Technical Ambassador of Arbitrum and Web3 Geek Contributor
This article is a technical deep dive into Arbitrum One by Luo Benben, former Technical Ambassador of Arbitrum and co-founder of Goplus Security, an automated smart contract auditing company.
Due to the lack of professional explanations on Arbitrum and even OP Rollups within Chinese-language content about Layer2, this article attempts to fill that gap by popularizing the operational mechanics of Arbitrum. Given Arbitrum's inherent complexity, even with maximum simplification, the full text exceeds 10,000 words—thus divided into two parts—and is recommended as a reference for saving and sharing!
Brief Overview of Rollup Sequencers
The scalability principle of Rollups can be summarized in two points:
Cost Optimization: Offload most computation and storage tasks off-chain from L1 to L2. L2 typically operates as a chain running on a single server—the sequencer (Sequencer/Operator).
Visually, the sequencer resembles a centralized server, sacrificing "decentralization" in the blockchain trilemma to gain advantages in TPS and cost efficiency. Users can let L2 handle their transaction instructions at a much lower cost than transacting directly on Ethereum.
Security Assurance: The contents of transactions on L2 and the resulting state are synchronized to Ethereum L1, where contracts verify the validity of state transitions. Additionally, Ethereum retains historical records of L2. Even if the sequencer permanently goes offline, anyone can reconstruct the entire L2 state using data stored on Ethereum.
Fundamentally, Rollup security is anchored in Ethereum. If the sequencer does not know a user account’s private key, it cannot initiate transactions on behalf of that account or tamper with its balance (and even if attempted, such actions would be quickly detected).
Although the sequencer acts as a central hub with centralized characteristics, in mature Rollup designs, a centralized sequencer can only engage in soft malicious behaviors like transaction censorship or deliberate downtime. However, ideal Rollup systems incorporate countermeasures (such as forced withdrawals or sequencing proofs) to resist censorship.
(Forced withdrawal function set in Loopring protocol's L1 contract source code, callable by users)
State verification methods used to prevent sequencer misbehavior fall into two categories: Fraud Proofs and Validity Proofs. Rollup solutions using Fraud Proofs are called OP Rollups (Optimistic Rollups, OPR). Due to historical reasons, Rollups using Validity Proofs are commonly referred to as ZK Rollups (Zero-Knowledge Proof Rollups, ZKR), rather than Validity Rollups.
Arbitrum One is a typical OPR. Its L1-deployed contracts do not actively validate submitted data, optimistically assuming correctness. If erroneous data is submitted, L2 validator nodes will proactively initiate challenges.
Therefore, OPR implies a trust assumption: at any time, there exists at least one honest L2 validator node. In contrast, ZKR contracts use cryptographic computations to actively yet inexpensively verify data submitted by the sequencer.
(Operation flow of Optimistic Rollup)
(Operation flow of ZK Rollup)
This article provides an in-depth exploration of Arbitrum One—the leading project among optimistic Rollups—covering all aspects of the system. After careful reading, you will gain a profound understanding of Arbitrum and optimistic Rollups (OPR).
Core Components and Workflow of Arbitrum
Core Contracts:
The most important contracts in Arbitrum include SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, and others, which will be detailed later.
Sequencer:
Receives user transactions, orders them, computes execution results, and promptly returns receipts to users (usually within <1 second). Users often see their transactions confirmed on L2 within seconds, delivering a Web2-like experience.
Meanwhile, the sequencer immediately broadcasts newly generated L2 blocks off-chain. Any Layer2 node can asynchronously receive these blocks. However, at this stage, the blocks lack finality and may be rolled back by the sequencer.
Every few minutes, the sequencer compresses and aggregates ordered L2 transaction data into batches (batches) and submits them to the SequencerInbox contract on Layer1, ensuring data availability and enabling the Rollup protocol to operate. Generally, once submitted to L1, L2 data cannot be reverted and achieves finality.
From the above process, we can conclude: Layer2 has its own network of nodes, but they are sparse and generally lack the consensus protocols common in public blockchains, making native security weak. Thus, reliability of data publication and validity of state transitions must depend on Ethereum.
Arbitrum Rollup Protocol:
Defines a series of contracts governing the structure of Rollup chain blocks (RBlocks), chain progression, RBlock publishing, and challenge procedures. Note: This “Rollup chain” is not equivalent to the conventional Layer2 ledger—it is an abstracted “chain-like data structure” independently established by Arbitrum One specifically to implement fraud proofs.
An RBlock may contain outcomes from multiple L2 blocks and differs significantly in data form. The actual RBlock data entity is stored across a suite of RollupCore contracts. If an RBlock contains errors, validators launch challenges against its submitter.
Validator:
Arbitrum validators are a special subset of full L2 nodes, currently subject to whitelist access.
Validators create new RBlocks (Rollup blocks, also known as assertions) based on transaction batches submitted by the sequencer to the SequencerInbox contract, monitor the current state of the Rollup chain, and challenge incorrect data submitted by the sequencer.
Active validators must stake assets on the Ethereum chain beforehand and are sometimes referred to as Stakers. Non-staking L2 nodes can still monitor Rollup operations and alert users to anomalies but cannot directly intervene on-chain against erroneous data submitted by the sequencer.
Challenge Mechanism:
The basic procedure involves multi-round interactive bisection followed by a single-step proof. During the bisection phase, both parties iteratively narrow down disputed transaction data until isolating the problematic opcode instruction, which is then verified. This 'multi-round bisection - single-step proof' paradigm is considered by Arbitrum developers to be the most gas-efficient implementation of fraud proofs. All steps occur under contract control, preventing cheating by either party.
Challenge Period:
Due to the optimistic nature of OP Rollups, when each RBlock is submitted on-chain, the contract does not immediately verify it. Instead, a window is left open for validators to disprove it. This window is known as the challenge period, lasting one week on the Arbitrum One mainnet. Only after this period ends is the RBlock finalized, allowing corresponding L2-to-L1 messages (e.g., withdrawal requests via the official bridge) to be processed.
ArbOS, Geth, WAVM:
The virtual machine used by Arbitrum is called AVM, consisting of Geth and ArbOS components. Geth is the most widely used Ethereum client software, lightly modified by Arbitrum. ArbOS handles all L2-specific functions such as network resource management, L2 block generation, and coordination with EVM. Together, they form a native AVM—the virtual machine used by Arbitrum. WAVM refers to the result of compiling AVM code into Wasm. In Arbitrum’s challenge process, the final "single-step proof" verifies a WAVM instruction.
Below is a diagram illustrating the relationships and workflow among the above components:
Lifecycle of an L2 Transaction
The processing flow of an L2 transaction is as follows:
1. User sends a transaction request to the sequencer.
2. The sequencer validates data such as digital signatures of pending transactions, filters out invalid ones, then orders and executes them.
3. The sequencer sends a receipt back to the user (typically very fast), but this is merely an off-chain "pre-processing" step by the sequencer, existing in Soft Finality and thus unreliable. However, users who trust the sequencer (most users) can optimistically assume the transaction is complete and irreversible.
4. The sequencer highly compresses raw pre-processed transaction data and packages it into a Batch.
5. At regular intervals (depending on data volume, ETH congestion, etc.), the sequencer publishes the transaction batch to the Sequencer Inbox contract on L1. At this point, the transaction can be considered to have achieved Hard Finality.
Sequencer Inbox Contract
This contract receives transaction batches submitted by the sequencer, ensuring data availability. More deeply, the batch data in SequencerInbox fully records the input information of Layer2 transactions. Even if the sequencer permanently fails, anyone can reconstruct the current state of Layer2 from the batch records and take over from a failed or absent sequencer.
Using a physical analogy, what we perceive as L2 is merely a projection of the batches in SequencerInbox, with STF acting as the light source. Since the STF light source rarely changes, the shape of the shadow depends solely on the object—the batch.
The Sequencer Inbox contract is also known as the fast inbox—dedicated for the sequencer to submit pre-processed transactions, and only the sequencer can write to it. In contrast, the slow inbox (Delayed Inbox) serves different purposes, explained in subsequent sections.
Validators continuously monitor the SequencerInbox contract. Whenever the sequencer publishes a batch to this contract, an on-chain event is emitted. Upon detecting this event, validators download the batch data, execute it locally, and publish an RBlock to the Rollup protocol contract on Ethereum.
Arbitrum’s bridge contract includes a parameter called accumulator, which logs new L2 batches submitted and new transaction counts and details received on the delayed inbox.
(The sequencer continuously submits batches to SequencerInbox)
(Details of a batch, where the data field corresponds to the batch data—this portion is large and not fully visible in the screenshot)
SequencerInbox contract has two main functions:
addSequencerL2BatchFromOrigin(), called by the sequencer each time it submits batch data to the SequencerInbox contract.
forceInclusion(), callable by anyone, enables censorship-resistant transactions. Its mechanism will be explained in detail when discussing the Delayed Inbox contract.
Both functions call bridge.enqueueSequencerMessage() to update the accumulator parameter in the bridge contract.
Gas Pricing
Clearly, L2 transactions cannot be free—otherwise, DoS attacks would occur, and operating costs for the sequencer and L2, along with L1 data submission fees, must be covered. When users initiate transactions on the Layer2 network, the gas fee structure is as follows:
Data publication cost due to consumption of L1 resources, primarily from batches submitted by the sequencer (each containing many users’ transactions), ultimately shared among initiating users. The pricing algorithm for data publication fees is dynamic—the sequencer adjusts prices based on recent profit/loss, batch size, and current Ethereum gas prices.
Costs incurred from consuming L2 resources, capped at a rate ensuring stable system operation (currently 7 million gas per second for Arbitrum One). L1 and L2 gas reference prices are tracked and adjusted by ArbOS—the exact formula is beyond the scope here.
While the specific gas price calculation is complex, users need not understand these details—they clearly benefit from Rollup transaction fees being far cheaper than those on the Ethereum mainnet.
Optimistic Fraud Proofs
Recalling earlier discussion, L2 is essentially just a projection of transaction input batches submitted by the sequencer into the fast inbox—that is:
Transaction Inputs → STF → State Outputs. With inputs fixed and STF constant, outputs are deterministic. The fraud proof system and Arbitrum Rollup protocol collectively represent a framework that publishes output state roots in the form of RBlocks (a.k.a. assertions) onto L1 and performs optimistic validation on them.
On L1, we have input data published by the sequencer and output states published by validators. Let us reconsider: Is it necessary to publish L2 state on-chain?
Since inputs completely determine outputs and input data is publicly visible, publishing output states—i.e., state roots—seems redundant? But this overlooks the fact that L1 and L2 systems require state settlement—specifically, withdrawal actions from L2 to L1—which necessitate state proofs.
A core idea in building Rollups is offloading most computation and storage to L2 to avoid high L1 costs. This means L1 does not inherently know L2’s state—it only helps the L2 sequencer publish all transaction inputs without computing L2’s state itself.
A withdrawal action fundamentally involves unlocking funds from an L1 contract according to cross-chain messages from L2 and transferring them to the user’s L1 account or performing other operations.
At this moment, the L1 contract asks: What is your state on L2? How do you prove you genuinely own the assets you claim to withdraw? The user must provide corresponding Merkle Proofs, etc.
Thus, theoretically, a Rollup without withdrawal functionality could operate without syncing state to L1 and without needing fraud proofs or other state-proof systems (though this might introduce other issues). In practice, however, this is clearly unfeasible.
In optimistic proving, the contract does not check whether the output state submitted to L1 is correct—it optimistically assumes everything is accurate. The optimistic proof system assumes that at any given time, at least one honest validator exists. If an incorrect state appears, it will be challenged via fraud proofs.
The advantage of this design is avoiding active validation of every RBlock posted to L1, saving gas. Indeed, for OPRs, validating every assertion is impractical—each RBlock contains one or more L2 blocks, and re-executing every transaction on L1 would be equivalent to executing L2 transactions directly on L1, defeating the purpose of Layer2 scaling.
ZKR avoids this issue because ZK proofs are succinct—only a small proof needs verification, without actually re-executing all underlying transactions. Hence, ZKR is not optimistic—each state publication undergoes mathematical verification by a Verifier contract.
Although fraud proofs lack the succinctness of zero-knowledge proofs, Arbitrum employs a 'multi-round bisection - single-step proof' interactive approach, ultimately requiring proof of only a single VM opcode, keeping costs relatively low.
Rollup Protocol
Let us examine how challenges and proof initiation begin—how the Rollup protocol works.
The core contract of the Rollup protocol is RollupProxy.sol, which uses a rare dual-proxy structure—one proxy pointing to two implementations: RollupUserLogic.sol and RollupAdminLogic.sol—while maintaining consistent data structures. Current tools like Scan cannot properly parse this setup.
Additionally, ChallengeManager.sol manages challenges, while the OneStepProver series of contracts adjudicate fraud proofs.
Within RollupProxy, a sequence of RBlocks (a.k.a. assertions) submitted by various validators is recorded—as shown below: green = confirmed, blue = unconfirmed, yellow = disproven.
Each RBlock contains the final state after executing one or more L2 blocks since the previous RBlock. These RBlocks form a formal Rollup Chain (distinct from the actual L2 ledger). Under optimistic conditions, this Rollup Chain should be fork-free, as forks imply validators submitted conflicting Rollup Blocks.
To propose or support an assertion, a validator must first stake a certain amount of ETH for that assertion, becoming a Staker. This ensures economic incentives for honest behavior—during challenges/fraud proofs, losing stakers forfeit their deposits.
The 111th blue block in the bottom right will eventually be disproven because its parent block 104 is invalid (yellow).
Moreover, Validator A proposed Rollup Block 106, which B disputes and challenges.
After B initiates a challenge, the ChallengeManager contract oversees the refinement process of challenge steps:
1. Refinement is an interactive turn-based process: one party segments historical data within a Rollup Block, and the other identifies which segment contains errors—a process akin to binary search (actually N/K), progressively narrowing the scope.
2. Next, pinpointing continues to identify the problematic transaction and result, further narrowing to the disputed machine instruction within that transaction.
3. The ChallengeManager contract only checks whether the resulting "data fragments" from subdividing original data are valid.
4. Once challenger and challenged agree on the target machine instruction, the challenger calls oneStepProveExecution(), submitting a single-step fraud proof demonstrating incorrect execution of that instruction.
Single-Step Proof
The single-step proof is the core of Arbitrum’s fraud proof system. Let’s explore exactly what a single-step proof verifies.
This requires understanding WAVM—Wasm Arbitrum Virtual Machine—a VM compiled from both the ArbOS module and the Geth (Ethereum client) core module. Due to significant differences between L2 and L1, the original Geth core must be lightly modified and work in tandem with ArbOS.
Thus, state transitions on L2 are jointly executed by ArbOS and Geth Core.
Arbitrum’s node clients (sequencer, validators, full nodes, etc.) compile the program combining ArbOS and Geth Core into native machine code executable directly on host machines (x86/ARM/PC/Mac/etc.).
If the target language is instead compiled into Wasm, the resulting WAVM is used by validators to generate fraud proofs. The contract verifying single-step proofs simulates the functionality of the WAVM virtual machine.
Why compile into Wasm bytecode when generating fraud proofs? Mainly because the contract verifying single-step fraud proofs must simulate a VM capable of processing a specific instruction set within an Ethereum smart contract, and WASM is easier to simulate on-chain.
However, WASM runs slightly slower than native machine code, so WAVM is only used during fraud proof generation and verification by Arbitrum nodes/contracts.
After prior multi-round interactive refinement, the single-step proof ultimately verifies a single instruction from the WAVM instruction set.
As seen in the code below, OneStepProofEntry first determines which category the opcode of the instruction to be proven belongs to, then calls the appropriate prover (e.g., Mem, Math), passing the single-step instruction into that prover contract.
The final result, afterHash, returns to ChallengeManager. If this hash mismatches the hash recorded on the Rollup Block for the post-instruction state, the challenge succeeds. If matched, the Rollup Block’s recorded instruction result is valid, and the challenge fails.
In the next article, we will analyze the contract modules handling cross-chain messaging/bridging between Arbitrum—and Layer2 and Layer1 more broadly—and further clarify how a truly meaningful Layer2 should implement censorship resistance.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
