Skip to content

docs: haw-refactor #2221

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 14 commits into
base: master
Choose a base branch
from
Draft
119 changes: 77 additions & 42 deletions arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -8,80 +8,115 @@ content_type: get-started
---

import ImageWithCaption from '@site/src/components/ImageCaptions/';
import ImageZoom from '@site/src/components/ImageZoom';

:::info
<a data-quicklook-from="arbitrum">Arbitrum</a> is a scaling technology suite designed to enhance Ethereum
by offering cheaper, faster transactions without sacrificing security. The core product, Arbitrum Rollup
(i.e., <a data-quicklook-from="arbitrum-nitro">Arbitrum Nitro</a>), is an Optimistic Rollup protocol
that processes transactions offchain and posts succinct proofs to Ethereum for verification. This
approach allows users to interact with Web3 apps and deploy smart contracts just like on Ethereum
but with significantly reduced fees and higher throughput.

This page gives a high-level overview. It explains <a data-quicklook-from="arbitrum">Arbitrum</a>, its purpose, and a brief "how it works." As you progress through the articles in this section, the content will get more technical and dive deeper into each component(s) and function(s) of the Arbitrum technology stack.
This documentation provides a comprehensive, end-to-end walkthrough of how Arbitrum works. It combines a high-level overview with a step-by-step technical explanation, following a <a data-quicklook-from="transaction">transaction</a> from the moment it's submitted all the way through execution, proving, and bridging. Each section corresponds to a core protocol component and collectively paints a full picture of how Arbitrum achieves scalability with Ethereum-grade trustlessness.

:::
## Diagram overview

Arbitrum is a technology suite designed to improve Ethereum. You can use Arbitrum chains for the same things you do on Ethereum, like using Web3 apps and deploying smart contracts. The difference is that your transactions will be cheaper and faster. Our main product, Arbitrum Rollup, is an Optimistic Rollup protocol that offers the same security as Ethereum.
The following diagram provides a clickable, high-level visualization of Arbitrum's architecture. It captures the key components and their interactions: sequencing, validation, execution, bridging, and proving.

### But why?
The diagram is interactive –– you can click on each part to view a more detailed scope of the relevant section of the document.

Ethereum is awesome, but it has its limitations. The Ethereum <a data-quicklook-from="blockchain">Blockchain</a> can handle only about 20 to 40 transactions per second (TPS) for all users. Once it reaches this limit, users must compete for space to have their transactions included, increasing fees.
<ImageZoom
src="/img/haw-transaction-lifecycle-interactive.svg"
alt="Interactive diagram of the transaction lifecycle"
className="img-600px"
/>

Arbitrum Rollup solves this issue! Here's how it works: an <a data-quicklook-from="arbitrum-rollup-chain">Arbitrum Rollup Chain</a> acts as a submodule within Ethereum. Unlike regular Ethereum transactions, we don't need Ethereum nodes to handle every Arbitrum transaction. Instead, Ethereum takes an ["innocent until proven guilty"](https://insights.deribit.com/market-research/making-sense-of-rollups-part-2-dispute-resolution-on-arbitrum-and-optimism/) stance with Arbitrum. Initially, the <a data-quicklook-from="parent-chain">Parent chain</a> assumes that actions on Arbitrum follow the rules. If there is a rule violation (like someone claiming, "Now I have all of your money"), that claim is challengeable on the parent chain. In this case, we can prove fraud, disregard the invalid claim, and penalize the guilty party. This ability to investigate and confirm fraud on the parent chain is Arbitrum's main feature and explains why it benefits from Ethereum's security.
## The lifecycle of a transaction

### How do these fraud proofs work?
At the most basic level, an <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> works like this:

People who help manage the <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> on the parent chain are called validators. They make claims about the chain's state, dispute others' claims, and more. Most Arbitrum users are unlikely to run a <a data-quicklook-from="validator">validator</a>, just as most Ethereum users do not operate their parent chain staking node. However, anyone can become a validator; you don't need special permission ([once the allowlist gets lifted](https://docs.arbitrum.foundation/state-of-progressive-decentralization)). You only need to run the [open source validator software](https://github.com/OffchainLabs/nitro) and stake Ether if required.
- Users submit transactions
- The <a data-quicklook-from="sequencer">Sequencer</a> determines a global order
- The <a data-quicklook-from="state-transition-function">State Transition Function</a> (STF) processes these transactions deterministically
- Validators post assertions summarizing results to Ethereum
- The results become finalized if no one challenges the <a data-quicklook-from="assertion">assertion</a> within the dispute window
- Messages and funds can be bridged back to Ethereum upon finalization

The chain stays secure if there is at least one honest validator. It only takes one trustworthy fraud prover to catch many bad actors. These features make the system "<a data-quicklook-from="trustless">Trustless</a>." Users do not depend on any specific group to keep their funds safe.
<ImageWithCaption
caption="Original napkin sketch drawn by Arbitrum co-founder Ed Felten"
src="https://lh4.googleusercontent.com/qwf_aYyB1AfX9s-_PQysOmPNtWB164_qA6isj3NhkDnmcro6J75f6MC2_AjlN60lpSkSw6DtZwNfrt13F3E_G8jdvjeWHX8EophDA2oUM0mEpPVeTlMbsjUCMmztEM0WvDpyWZ6R"
/>

### Who does this fraud proofing?
This documentation follows a transaction from start to finish:

This step is where the "Rollup" part comes in. Arbitrum Rollup chains handle user <a data-quicklook-from="transaction">transaction</a> data by posting it directly on Ethereum. This setup means that as long as Ethereum is secure, anyone can see what happens on Arbitrum. They can also spot and prove any fraud that occurs.
### [1. Sequencing, followed by deterministic execution](/how-arbitrum-works/02-transaction-lifecycle.mdx)

Validators are the nodes that help move the Arbitrum <a data-quicklook-from="chain-state">Chain state</a> forward on the parent chain. They make claims about the chain's state and can dispute claims made by others. Most Arbitrum users are unlikely to want to run a validator, just as most Ethereum users typically don't run their parent chain staking nodes. However, anyone can become a validator. Once the allowlist gets removed, users only need to run the open-source validator software and stake Ether if they need to take action.
A user submits a transaction, which the Sequencer receives and orders. This ordering forms the basis of consistent state transitions across all nodes.

The network stays secure if there is at least one honest validator, which means that just one trustworthy fraud prover can catch any number of bad actors. This setup makes the system "trustless"; users do not have to rely on any specific person to keep their funds safe.
### [2. The Sequencer and censorship resistance](/how-arbitrum-works/03-sequencer.mdx)

### The game
Even if the Sequencer misbehaves or censors, users can bypass it using the <a data-quicklook-from="parent-chain">Parent chain</a>'s <a data-quicklook-from="delayed-inbox">Delayed Inbox</a>. This bypass ensures liveness and permissionless access.

It's not as complicated as it seems. If two validators disagree, only one is telling the truth. In the event of a dispute, the two validators engage in an interactive game, where they respond to each other in a call-and-response format. This process allows them to narrow their disagreement to a single computational step—something straightforward, like multiplying two numbers. This step executes on the parent chain, which shows which party is honest. For a more detailed explanation, see here.
### [3. Bridging from a parent chain to a child chain](/how-arbitrum-works/10-l1-to-l2-messaging.mdx)

Users only experience delays when they withdraw funds from Arbitrum back to Ethereum. When withdrawing directly from Arbitrum to Ethereum, users usually wait one week to receive their funds on the parent chain. However, users can skip this waiting period if they use a fast <a data-quicklook-from="bridge">bridge</a> application, often for a small fee. Other activities do not have this delay, like depositing funds from Ethereum to Arbitrum or using a decentralized application (<a data-quicklook-from="dapp">dApp</a>) on the Arbitrum chain.
Transactions can move assets and messages from the parent chain (Ethereum) to the <a data-quicklook-from="child-chain">Child chain</a> (Arbitrum). This movement is facilitated via canonical <a data-quicklook-from="bridge">Bridge</a> contracts and retryables, allowing future execution on the child chain.

### How is it cheaper?
### [4. State Transition Function (STF)](/how-arbitrum-works/04-state-transition-function/01-stf-gentle-intro.mdx)

Arbitrum helps lower user transaction costs by reducing the strain on the parent chain. The primary way it does this is by processing transactions in batches. A <a data-quicklook-from="batch">batch</a> can contain several hundred <a data-quicklook-from="child-chain">child chain</a> transactions and gets submitted as one parent chain transaction. This batching makes interacting with the parent chain cheaper since you save on overhead costs compared to submitting each transaction individually.
The STF consumes transactions as inputs and computes outputs deterministically. It supports multiple languages (e.g., Solidity, <a data-quicklook-from="stylus">Stylus</a>) and compiles into execution/proving formats.

Additionally, Arbitrum posts transaction data on the parent chain in a compressed format. It only decompresses this data within the child chain environment, reducing the amount of information that needs storing on the parent chain.
### [5. Validation and proving](/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx)

### How does it all work together?
Validators periodically create assertions summarizing state updates and post them to Ethereum. These can be challenged in an interactive fraud-proof game if incorrect. If no <a data-quicklook-from="challenge">challenge</a> occurs, the assertion is confirmed.

At the most basic level, an Arbitrum chain works like this:
### [6. Child to parent chain bridging](/how-arbitrum-works/11-l2-to-l1-messaging.mdx)

<ImageWithCaption
caption="Original napkin sketch drawn by Arbitrum co-founder Ed Felten"
src="https://lh4.googleusercontent.com/qwf_aYyB1AfX9s-_PQysOmPNtWB164_qA6isj3NhkDnmcro6J75f6MC2_AjlN60lpSkSw6DtZwNfrt13F3E_G8jdvjeWHX8EophDA2oUM0mEpPVeTlMbsjUCMmztEM0WvDpyWZ6R"
/>
Once finalized, withdrawals and outbound messages (e.g., `ETH`, tokens) are now executable on the parent chain via the <a data-quicklook-from="outbox">Outbox</a> system, where results flow back to the parent chain.

## Why Arbitrum?

Ethereum is powerful but limited in scalability, supporting only 20 to 40 transactions per second (TPS) for the entire network. Once at capacity, transaction fees spike as users compete for space. Arbitrum Rollup solves this by batching hundreds of transactions into a single update to Ethereum, compressing data, and leveraging offchain execution to maximize efficiency.

Users and contracts put messages into the inbox. The chain reads the messages one at a time and processes each one. This processing updates the state of the chain and produces some outputs.
Ethereum doesn't directly verify every transaction on Arbitrum. Instead, it assumes that transactions are valid unless fraud is proven –– the essence of an Optimistic Rollup. If any state transition occurs, validators can challenge it through interactive fraud proofs, and Ethereum enforces the correct state.

If you want an Arbitrum chain to process a transaction for you, you need to put that transaction into the chain's inbox. Then, the chain will see your transaction, execute it, and produce some outputs: a transaction receipt and any withdrawals that your transaction initiated.
### The Trust model and fraud proofing

Execution is deterministic, meaning that the contents of its inbox uniquely determine the chain's behavior. Because of this, the result of your transaction is knowable as soon as it gets put in the inbox. Any Arbitrum node will be able to tell you the result. (And you can run an Arbitrum node yourself if you want.)
Anyone can run a <a data-quicklook-from="validator">validator</a>. Validators propose state assertions and challenge others in a call-and-response dispute game. This process narrows disagreements to a single computation step that executes on the parent chain, determining the honest party.

All of the technical details in this document connect to this diagram. To get from this diagram to a complete description of Arbitrum, we'll need to answer questions like these:
The system requires only one honest validator to maintain correctness. This makes the protocol <a data-quicklook-from="trustless">trustless</a> –– where trust is not dependent on a single party, and dishonest participants are penalized economically.

- Who keeps track of the inbox, Chain state, and outputs?
- How does Arbitrum make sure that the chain state and outputs are correct?
- How can Ethereum users and contracts interact with Arbitrum?
- How does Arbitrum support Ethereum-compatible contracts and transactions?
- How are ETH and tokens transferred into and out of Arbitrum chains, and how are they managed while on the chain?
- How can I run my own Arbitrum node or validator?
### Why it's cheaper

### Nitro's Design: The Four Big Ideas
Arbitrum minimizes costs by:

- Batching transactions into single-parent chain posts
- Compressing transaction data before posting to the parent chain
- Deferring execution to the child chain nodes using deterministic state computation

All this significantly reduces gas usage on the parent chain while maintaining transparency and verifiability.

### The Four big ideas behind Nitro

The essence of Nitro and its key innovations lie in four big ideas. We'll list them here with a quick summary of each. We will unpack them in more detail in later sections.

**Big Idea: Sequencing, Followed by Deterministic Execution**: Nitro processes transactions with a two-phase strategy. First, the transactions get organized into a single-ordered sequence, and Nitro commits to that sequence. Then, the transactions get processed in that sequence by a deterministic <a data-quicklook-from="state-transition-function">State Transition Function</a>.
#### Sequencing, followed by deterministic execution

Nitro processes transactions with a two-phase strategy. First, the transactions get organized into a single-ordered sequence, and Nitro commits to that sequence. Then, the transactions get processed in that sequence by a deterministic State Transition Function.

#### Geth at the core

Nitro supports Ethereum's data structures, formats, and virtual machine by compiling in the core code of the popular go-ethereum (<a data-quicklook-from="geth">Geth</a>) Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum.

#### Separate execution from proving

Nitro takes the same source code and compiles it twice, once to native code for execution in Nitro code, optimized for speed, and again to <a data-quicklook-from="wasm">WASM</a> for use in proving, optimized for portability and security.

#### Optimistic Rollup with interactive fraud proofs

Nitro settles transactions to the parent Ethereum chain an Optimistic Rollup protocol, including the interactive fraud proofs pioneered by Arbitrum.

**Big Idea: <a data-quicklook-from="geth">Geth</a> at the Core**: Nitro supports Ethereum's data structures, formats, and virtual machine by compiling in the core code of the popular go-ethereum ("Geth") Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum.
Now that we have covered the foundational concepts, the big picture, and the four big ideas of Arbitrum Nitro, we will begin a journey following a transaction through the Arbitrum protocol. In the next section, the transaction lifecycle begins.

**Big Idea: Separate Execution from Proving**: Nitro takes the same source code and compiles it twice, once to native code for execution in a Nitro node, optimized for speed, and again to <a data-quicklook-from="wasm">WASM</a> for use in proving, optimized for portability and security.
## What comes next?

**Big Idea: Optimistic Rollup with Interactive Fraud Proofs**: Nitro settles transactions to the parent Ethereum chain using an Optimistic Rollup protocol, including the interactive fraud proofs pioneered by Arbitrum.
Now that we have covered the foundational concepts, the big picture, and the four big ideas of <a data-quicklook-from="arbitrum-nitro">Arbitrum Nitro</a>, we will begin a journey following a transaction through the Arbitrum protocol. In the next section, the transaction lifecycle begins.
The remainder of this document walks through each component in detail. If you want to know how a particular part works –– token bridging, STF execution, validator staking, or fraud-proof games –– just click into the relevant section from the diagram or navigate sequentially. We'll trace every step in the lifecycle and explain how Arbitrum delivers secure, efficient scaling for Ethereum.
Loading