Rollup Protocol and Validation

Arbitrum operates as an Optimistic Rollup, which advances the chain's state based on transaction assertions unless a dispute arises. This approach enables scalability, lower costs, and high throughput while maintaining security through Ethereum's trustless validation model.

Optimistic Rollups work by separating execution from proving to ensure efficient transaction processing without immediate validation. The execution process is covered in detail in the State Transition Function. This section focuses on validation and proving mechanisms. We will cover how child chain validators confirm the chain's state and how assertions are posted to parent chain for finalization, with the potential for future challenges if an assertion is determined to be incorrect.

Execution vs. proving: Separating responsibilities

A fundamental design choice in Arbitrum is the separation of execution from proving, which allows for:

Efficient execution

Transactions are processed optimistically without immediate verification.

Deterministic proving

If challenged, state transitions are replayable and verified onchain.

To achieve this, Arbitrum compiles the State Transition Function (STF) into different formats:

Execution mode

Uses Go's native compiler for high-performance execution on validator nodes.

Proving mode

Compiles to WebAssembly (WASM), which transforms into WebAssembly for Arbitrum Virtual Machine (WAVM) for fraud-proof verification.

This dual compilation approach ensures that Arbitrum nodes execute transactions efficiently while allowing deterministic trustless verification on parent chain.

Stylus execution and proving

Stylus extends Arbitrum's execution model by enabling WASM-based smart contracts. While execution occurs natively in WAVM, the proving process follows the same interactive fraud-proof mechanism as the EVM, ensuring Stylus transactions are challengeable and deterministically verifiable. Fraud proofs for Stylus transactions involve WAVM opcode evaluation, leveraging Arbitrum's existing one-step proof (OSP) system.

The role of validators and the Rollup chain

Arbitrum's Rollup Protocol relies on validators––network participants responsible for ensuring state correctness. The protocol enforces security through the following principles:

Permissionless validation

Anyone can become a validator by running an Arbitrum node.

Trustless verification

Validators confirm assertions, ensuring transactions adhere to protocol rules.

Fraud-proof system

If an incorrect assertion is detected, validators can challenge it and trigger an interactive fraud-proof.

Validators interact with the Rollup chain, a sequence of assertions representing state updates. Each assertion includes:

Predecessor assertion

The last confirmed valid state.

State transition output

The result of applying transactions.

Inbox message consumption

A record of processed messages from the parent chain.

Execution claim

A cryptographic commitment to the computed state.

Assertions progress through different stages:

Proposed

A validator submits a state assertion.

Challenged (if necessary)

If another validator disputes the assertion, an interactive fraud-proof initiates.

Confirmed

It becomes final if no one challenges the assertion within the dispute window (6.4 days).

This model ensures that as long at least one honest validator participates, the correct execution will always be confirmed.

Arbitrum Rollup protocol

Before diving into the Rollup protocol, it is important to clarify two key points:

1. End users and developers do not need to interact with the Rollup Protocol.
   • Like a train passenger relying on the engine without needing to understand its mechanics, users, and developers can interact with Arbitrum without engaging with the validation process.
2. The protocol does not determine transaction results, it only confirms them.
   • The ordered sequence of messages in the chain's inbox dictates the transaction outcomes. The protocol ensures correctness and finality but does not alter execution results.

Since transaction execution is deterministic, the Rollup Protocol exists to confirm results and prevent fraud. This mechanism serves two key purposes:

• Detecting dishonest behavior: If a validator submits an incorrect state, others can challenge it.
• Anchoring Rollup state to the parent chain: The parent chain itself does not execute every child chain transaction but serves as the final arbiter of state correctness.

Validators and assertions in the Rollup protocol

Validators play a central role in maintaining Arbitrum's integrity. Some validators act as proposers, submitting assertions to Ethereum and placing a WETH bond as collateral. If their assertion is determined to be incorrect, they lose their bond.

Since at least one honest validator can always confirm the correct state, Arbitrum remains as trustless as Ethereum.

The Rollup chain assertions vs. child chain blocks

The Rollup chain consists of assertions, which serve as checkpoints summarizing multiple child chain blocks.

• Child chain blocks contain individual transaction data
• Assertions provide state summaries recorded on Ethereum
• Each assertion may represent multiple child chain blocks, optimizing gas costs and reducing Ethereum storage usage.

Validators submit assertions by calling createNewAssertion in the Rollup contract. Assertions contain structured data known as AssertionInputs, which capture the before-state and after-state of execution for future validation.

Contents of an assertion

Each assertion consists of:

• Assertion number: A unique identifier
• Predecessor assertion: The last confirmed assertion
• Number of child chain blocks: The total child chain blocks included
• Number of inbox messages: Messages consumed during execution
• Output hash: A cryptographic commitment to the resulting state.

Arbitrum ensures assertions are automatically confirmed or rejected based on protocol rules:

1. An assertion is confirmed if:
   • Its predecessor is the latest confirmed assertion.
   • The dispute window has passed without challenges.
2. An assertion is rejected if:
   • Its predecessor assertion is invalid.
   • A conflicting assertion has been confirmed.

For more details on how the Rollup chain works under BoLD, the gentle introduction provides an overview that touches on the Rollup chain.

note

Validators and proposers serve different roles. Validators validate transactions by computing the next chain state using the chain's STF, whereas proposers can also assert and challenge the chain state on the parent chain.

Except for the assertion number, the contents of the assertion are all just claims by the assertion's proposer. Arbitrum doesn't know at first whether any of these fields are correct. The protocol should eventually confirm the assertion if all of these fields are correct. The protocol should eventually reject the assertion if one or more of these fields are incorrect.

An assertion implicitly claims that its predecessor assertion is correct, which means that it also claims the correctness of a complete history of the chain: a sequence of ancestor assertions that reaches back to the birth of the chain.

An assertion also implicitly claims that its older siblings (older assertions with the same predecessor), if there are any, are incorrect. If two assertions are siblings, and the older sibling is correct––then the younger sibling is considered incorrect, even if everything else in the younger sibling is true.

The assertion is assigned a deadline, which indicates how much time other validators have to respond to it. For an assertion R with no older siblings, this will equal the time the assertion was posted, plus an interval of time known as the challenge Period; subsequent younger siblings will have the same deadline as their oldest sibling (R). You don't need to do anything if you're a validator and agree that an assertion is correct. If you disagree with an assertion, you can post another assertion with a different result, and you'll probably end up in a challenge against the party who proposed the first assertion (or another party acting in support of that assertion). More on challenges below:

In the normal case, the Rollup chain will look like this:

On the left, representing an earlier part of the chain's history, we have confirmed assertions. These have been fully accepted and recorded by the parent chain contracts that manage the chain. The newest of the confirmed assertions, assertion 94, is called the "latest confirmed assertion."

On the right, we see a set of newer proposed assertions. The protocol can't yet confirm or reject them because their deadlines haven't run out yet. The oldest assertion whose fate has yet to be determined, assertion 95, is called the "first unresolved assertion."

Notice that a proposed assertion can build on an earlier proposed assertion. This process allows validators to continue proposing assertions without waiting for the protocol to confirm the previous one. Normally, all of the proposed assertions will be valid, so they will all eventually be accepted.

Here's another example of what the chain state might look like if several validators are being malicious. It's a contrived example designed to illustrate a variety of cases that can come up in the protocol, all smashed into a single scenario.

There's a lot going on here, so let's unpack it:

• Assertion 100 was confirmed.
• Assertion 101 claimed to be a correct successor to assertion 100, but 101 was rejected.
• Assertion 102 eventually receives confirmation as the correct successor to 100.
• Assertion 103 was confirmed and is now the latest confirmed assertion.
• Assertion 104 was proposed as a successor to assertion 103, and 105 was proposed as a successor to 104. 104 was rejected as incorrect, consequently, 105 was rejected because its predecessor was rejected.
• Assertion 106 is unresolved. It claims to be a correct successor to assertion 103 but the protocol hasn't yet decided whether to confirm or reject it. It is the first unresolved assertion.
• Assertions 107 and 108 claim to chain from 106. They are also unresolved. If 106 gets rejected, they will be automatically rejected too.
• Assertion 109 disagrees with assertion 106 because they both claim the same predecessor. At least one of them will eventually be rejected, but the protocol hasn't yet resolved them.
• Assertion 110 claims to follow 109. It is unresolved. If 109 gets rejected, 110 will be automatically rejected too.
• Assertion 111 claims to follow 104. 111 will inevitably get rejected because its predecessor has already been rejected. However, it remains active, because the protocol resolves assertions in assertion number order, so the protocol will have to resolve 106 through 110 in order, before it can resolve 111. After 110 resolves, the protocol will immediately reject 111.

Again this sort of thing is very unlikely in practice. In this diagram, at least four different bonds are on incorrect assertions, and when the dust settles, at least four bonds will be forfeited. The protocol handles these cases correctly, but they're rare corner cases. This diagram illustrates the possible situations that are possible in principle and how the protocol would deal with them.

Delays

Even if the Assertion Tree has multiple conflicting assertions and multiple disputes are in progress, validators can continue making new assertions. Honest validators will build on one valid assertion (intuitively, an assertion is also an implicit claim of the validity of all of its parent assertions). Likewise, users can continue transacting on the child chain since transactions will continue to post in the chain's inbox.

The only delay users experience during a dispute is their Child to parent chain messages (i.e., withdrawals). A key property of BoLD is that we can guarantee that, in the common case, their withdrawals/messages will only get delayed for one challenge period. In the case of an actual dispute, the withdrawals/messages will be delayed by no more than two challenge periods, regardless of the adversaries' behavior during the challenge.

Who will be validators?

Anyone can do it, but most people will choose not to. In practice, we expect people to validate a chain for several reasons.

• It is possible to pay validators for their work by the party that created the chain or someone else. A chain is configurable, so some of the funds from user transaction fees are paid directly to validators.
• Parties with significant assets at bond on a chain, such as dApp developers, exchanges, power users, and liquidity providers, may choose to validate in order to protect their investment.
• Anyone who wants to validate can do so. Some users may choose to validate to protect their interests or be good citizens. But ordinary users don't need to validate, and we expect most users won't.

Staking and validator incentives

Arbitrum requires validators to stake ETH as a security deposit to ensure honest participation and prevent malicious behavior. This mechanism enforces economic accountability:

• Proposers (validators submitting assertions) must bond ETH to support their claims.
• Challenges against incorrect assertions result in bond forfeiture for dishonest validators.
• Successful challengers receive a portion of the dishonest validator's bond as a reward.

Validators can adopt different roles:

1. Active validators: Regularly propose new assertions.
2. Defensive validators: Monitor the network and challenge incorrect assertions.
3. Watchtower validators: Passively observe and raise alarms when fraud is detected.

The protocol design requires only one honest validator to secure the system, making Arbitrum trustless and resistant to Sybil attacks.

Staking mechanism

Some validators will act as bonders (staked participants) at any given time, while others remain passive. Bonders deposit ETH bonds into Arbitrum's smart contracts, which are forfeited if they lose a challenge.

note

Nitro chains exclusively accept ETH as collateral for staking.

A single bond can secure a sequence of assertions, meaning a validator's stake applies to multiple checkpoints of the chain's history. This checkpoint allows efficient resource use while maintaining security.

A validator must be bonded to its predecessor to create a new assertion. The bond ensures that validators have economic risk in any assertion they make.

Staking rules

1. New validators: If unbonded, a validator can stake on the latest confirmed assertion by depositing the required ETH bond.
2. Extending an existing bond: The validator can extend its bond to one successor assertion if already bonded. - If a validator submits a new assertion, they automatically extend their existing bond to cover it.
3. Unbonding: A validator can only request a refund if they have a bond on the latest confirmed assertion.
4. Losing a challenge: If a validator's assertion is challenged successfully (i.e., they are malicious), they lose all their bonded ETH across any unresolved assertions.

Since unbonding is not allowed mid-assertion validators must commit until their assertion is confirmed or disproven.

Handling disputes and delays

Multiple disputes may be active simultaneously if conflicting assertions arise in the Assertion Tree. However, Arbitrum's protocol ensures that:

• Honest validators can continue asserting, building on the last correct assertion.
• Users can keep transacting on the child chain without disruption.
• Child-to-parent chain withdrawals may experience delays - Typically, withdrawals experience a single challenge period (6.4 days) delay. - A key property of BoLD is that we can guarantee that in the common case, withdrawals/messages will only experience delay of one challenge period. In the case of an actual dispute, the withdrawals/messages will be delayed by no more than two challenge periods, regardless of the adversaries' behavior during the challenge.

Despite these delays, Arbitrum guarantees that honest assertions always succeed, maintaining Ethereum-level security.

Who becomes a validator?

Arbitrum's validation process is permissionless, allowing anyone to participate. However, in practice, most users will not act as validators.

Common validator motivations include:

• Financial incentives: Some validators receive payment from network fees or the chain's owner.
• Asset protection: dApp developers, exchanges, and liquidity providers may validate the chain to protect their holdings.
• Public interest: Some participants validate purely for network integrity, ensuring fair execution.

For most users, validation is unnecessary, as the network relies on economic incentives and fraud-proof mechanisms to maintain security.