Arbitrum Nitro White Paper Quick Read: How to be more EVM compatible and reduce transaction costs?

Source: Offchain labs

Compiled by: Karen, Foresight News

In the latest release of the Arbitrum Nitro white paper, Offchain Labs presents Arbitrum Nitro as a second-generation Optimistic Rollup. Compared to previous Rollups, Nitro is capable of providing higher throughput, faster finality, and more efficient dispute resolution solutions.

At the core of Arbitrum Nitro's technology is a new prover that can perform interactive fraud proofs on WASM code. In other words, the L2 Arbitrum engine can run on WASM, replacing the previously custom-designed AVM (Arbitrum EVM) architecture, allowing the use of standard languages and tools for building and compiling.

The coolest aspect of Nitro is the direct compilation of the Geth core into Arbitrum, as Geth effectively defines the EVM engine standard for Ethereum. Thus, Nitro essentially runs Geth on Layer 2 above Ethereum and can prove fraud against the Geth core engine compiled to WASM.

Arbitrum has also stated that Nitro features optimized batching and data compression components, which can further reduce transaction costs on Arbitrum, and it has Ethereum L1 Gas compatibility. Additionally, fraud proofs, sequencers, and token bridges are also components of Nitro. Since Nitro is built on standard technologies like WASM and Geth, it is more compatible with EVM. According to the white paper, the improved Nitro is more efficient, has lower latency, and better incentive compatibility compared to Arbitrum One.

The design principles that enable Arbitrum to achieve these properties include:

• Separating transaction ordering from deterministic execution;
• Combining existing Ethereum simulation software with scaling and implementing cross-chain functionality;
• Compiling execution and proof separately;
• Using an Optimistic Rollup protocol based on interactive fraud proofs to place transaction results on Layer 1.

1. Ordering and Deterministic Execution

Nitro processes submitted transactions in two stages. The sequencer orders the transactions and publishes the order as a real-time stream and compressed data batches on the Layer 1 chain. These transactions are processed one at a time according to a deterministic state transition function, which updates the chain state and generates Layer 2 blocks that will later settle to the Layer 1 chain.

Specifically, regarding ordering, the sequencer is trusted and honestly orders incoming transactions sequentially. Currently, it publishes its transaction ordering in two ways: first, by releasing a real-time stream of ordered transactions, representing the sequencer's commitment to recording transactions in a specific order; second, after collecting a batch of transactions, the sequencer compresses them using a general algorithm called Brotli to reduce costs and passes the results to the Nitro chain's Inbox contract (running on L1 Ethereum). Once the transactions from the sequencer to the inbox achieve finality on Ethereum, the transaction order on the Nitro chain is final.

Currently, the sequencer is a centralized component operated by Offchain Labs, with plans to transition to a committee-based sequencer using a fair distributed ordering protocol in the future.

In terms of deterministic execution, after ordering the incoming transactions, the Nitro chain uses the chain's state transition function (STF) to process them, outputting the updated state and generating Layer 2 blocks.

2. Software Architecture: Geth at the Core

Integrating Geth is the second key design principle of Nitro. Geth refers to the Ethereum node software go-ethereum. The core execution and state maintenance functions in Nitro are handled by the open-source go-ethereum (geth) package code, ensuring its execution and state are highly compatible with Ethereum.

The software that constitutes Nitro nodes can be viewed as built into three main layers: the base layer—Geth core (simulating EVM contract execution and maintaining the data structures that constitute Ethereum state), the middle layer (ArbOS), and the top layer. ArbOS is a software layer that implements the necessary functions for managing the Layer 2 chain, including accounting functions, supporting secure bi-directional cross-chain calls between Nitro and Layer 1 Ethereum, and Layer 2-specific fee tracking and collection.

Regarding cross-chain interactions, Nitro's cross-chain messaging capabilities can also be used to create a token bridge, which is an application that allows for the efficient transfer of assets between Ethereum and the Nitro chain. The Offchain Labs team has implemented and released an informal token bridge that provides deposit or withdrawal functionality for fungible tokens. Additionally, the new and improved batching and compression system can also minimize L1 costs.

The top layer consists of node software that handles connections from clients and incoming RPC requests, providing other functionalities required for operating a blockchain node compatible with Ethereum.

3. Separation of Execution and Proof

Nitro separates execution and proof by using the same source code but compiling it to different targets for these two cases. When compiling the Nitro node software for execution, a standard Go compiler is used to generate native code for the target architecture, which may vary for different node deployments.

Additionally, the code for the state transition function part is compiled by the Go compiler into WebAssembly (WASM), which is a typed, portable machine code format. The WASM code is then simply transformed and modified into a format called WAVM.

The white paper notes that WAVM differs from WASM in three main aspects: it removes some features of WASM that the Go compiler does not generate; it restricts some functionalities of WASM, including the removal of floating-point instructions and the exclusion of nested control flow; and it adds some opcodes to facilitate interaction with the blockchain environment.

If there is a dispute regarding the correctness of the computed state transition function results, it is resolved through an interactive fraud proof protocol referencing the WAVM code.

4. Optimistic Rollup with Interactive Fraud Proofs

Building on the initial design of Arbitrum, Nitro employs an improved Optimistic Rollup protocol that utilizes an optimized interactive fraud proof protocol.

This Rollup protocol is Nitro's method for confirming the Layer 2 chain state and the relevant data on Layer 1 Ethereum. Layer 2 users typically do not wait for L1 confirmations but rely on the deterministic state transition function, which allows deriving transaction results from the recorded transaction sequence.

The Rollup protocol generates a chain of Rollup Blocks (RBlocks), which differ from Layer 2 blocks in that a Rollup Block typically encapsulates a series of Layer 2 blocks, resulting in far fewer RBlocks than L2 blocks. Initially, an RBlock represents a claim by a party that the data of the RBlock is correct. Ultimately, each such claim is either confirmed by the protocol or removed from the RBlock chain after being rejected. This set of confirmed RBlocks will form a chain starting from the genesis RBlock.