# Arbitrium

## Setup
Need to initialize the database with `--init.url="https://snapshot.arbitrum.io/mainnet/nitro.tar"` option when `docker run`
## Docker run

docker run --rm -it  -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v2.0.14-2baa834 --l1.url https://l1-node:8545 --l2.chain-id=<L2ChainId> --http.api=net,web3,eth,debug --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=*

### Required parameter

--l1.url=<Layer 1 Ethereum RPC URL>

Must provide standard layer 1 node RPC endpoint that you run yourself or from a node provider

--l2.chain-id=<L2 Chain ID>

See public chains for a list of Arbitrum chains and the respective L2 Chain Ids

#### Example
Arbitrum One

--l1.url https://mainnet.infura.io/v3/fc2489564ccc4e568cea02ace0d9a4e8
--l2.chain-id=42161
--init.url="https://snapshot.arbitrum.io/mainnet/nitro.tar"

## Shutdown
"Graceful shutdown"
`docker stop --time=300 $(docker ps -aq)`

## Deepdive
https://developer.arbitrum.io/inside-arbitrum-nitro/
### Nitro's Design: The Four Big Ideas
1. **Sequencing, Followed by Deterministic Execution:**
Nitro processes transactions with a two-phase strategy. First, the transactions are organized into a single ordered sequence, and Nitro commits to that sequence. Then the transactions are processed, in that sequence, by a deterministic state transition function.
2. **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 ("Geth") Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum.
3. **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 WASM for use in proving, optimized for portability and security.
4. **Optimistic Rollup with Interactive Fraud Proofs:**
Nitro settles transactions to the Layer 1 Ethereum chain using an optimistic rollup protocol, including the interactive fraud proofs pioneered by Arbitrum.

### Sequencing, Followed by Deterministic Execution

The Sequencer publishes transaction sequence in two ways: a **real-time feed**, and **batches posted on L1 Ethereum**.
* The feed represents the Sequencer's promise that it will record transactions in a particular order
* "soft finality"
* Sequencer also publishes on the L1 Ethereum chain, periodically--perhaps every few minutes in production--
* final and official record of the transaction sequence
* "hard finality".

### Geth at the Core
* The base layer is the core of geth--the parts of Geth that **emulate the execution of EVM contracts and maintain the data structures** that make up the Ethereum state. Nitro compiles in this code as a library, with a few minor modifications to add necessary hooks.
* The middle layer, which we call ArbOS, is custom software that provides additional functions associated with **Layer 2 functionality**, such as decompressing and parsing the Sequencer's data batches, accounting for Layer 1 gas costs and collecting fees to reimburse for them, and supporting cross-chain bridge functionalities such as deposits of Ether and tokens from L1 and withdrawals of the same back to L1.
* The top layer consists of node software, mostly drawn from geth. This handles **connections and incoming RPC requests** from clients and provides the other top-level functionality required to operate an Ethereum-compatible blockchain node.

### Separating Execution from Proving
* For execution, the ordinary **Go compiler** is used, producing native code for the target architecture
* For proving, the portion of the code that is the State Transition Function (STF) is compiled by the Go compiler to WebAssembly (wasm), which is a typed, portable machine code format. The wasm code then goes through a simple transformation into **WAVM format**. If there is a dispute about the correct result of computing the STF, it is resolved with reference to the WAVM code.
#### WAVM
WAVM differs from wasm in three main ways
* First, WAVM removes some features of wasm that are not generated by the Go compiler
* WAVM restricts a few features of wasm.
* No floating-point instructions
* No nested control flow. Control flow constructs flattened; control flows turn into jumps
* Adds a few opcodes

### Optimistic Rollup
#### Rollup:
The inputs to the chain are all recorded on the Ethereum chain as calldata
#### Optimistic:
Let any party (a “validator”) post on Layer 1 a rollup block that that party claims is correct, and then giving everyone else a chance to challenge that claim.

#### Resolving disputes using interactive fraud proofs
Two choices: interactive proving, or re-executing transactions. **Interactive proving** is superior

## MISC
https://research.arbitrum.io/t/compression-in-nitro/20

## Run options
- `--node.seq-coordinator.my-url string`
- url for this sequencer if it is the chosen (default "`<?INVALID-URL?>`")
- `--node.seq-coordinator.redis-url string`
- the Redis URL to coordinate via
- `--node.sequencer.forwarder.redis-url string`
- the Redis URL to recomend target via