Skip to main content

Arbitrum One & Nova

Key Takeaways​

  • Arbitrum is a representative optimistic rollup in the Ethereum ecosystem, consistently maintaining the top spot in terms of TVL.
  • Arbitrum Nitro is the only existing rollup network with a fraud proof system implemented. Furthermore, it provides high scalability and EVM compatibility.
  • Arbitrum Nova is based on the Arbitrum AnyTrust protocol. Since it stores data through the Data Availability Committee (DAC) rather than the Ethereum network, it can provide higher scalability than Arbitrum Nitro.

1. Overview​

Arbitrum is a representative optimistic rollup in the Ethereum ecosystem, consistently maintaining the top spot in terms of TVL. Arbitrum upgraded its protocol from Arbitrum Classic to Arbitrum Nitro, achieving higher throughput and EVM compatibility. Because of its high EVM compatibility, developers can easily deploy contracts that can compile to EVM bytecode, with some minor changes.

2. Execution​

2.1 Arbitrum Nitro​

Arbitrum Nitro is an upgrade applied in August 2022. The previous Arbitrum Classic looks quite different from the current Arbitrum Nitro. Arbitrum Classic used the Arbitrum Virtual Machine (AVM), a self-built execution environment, not EVM. In contrast, nodes of Arbitrum Nitro do not use AVM, and as shown in the picture above, it consists of three layers.

The base layer has a geth core that can perform EVM operations, and most of the top layer has node software that came from geth. The ArbOS in the middle layer is custom software responsible for L2-related functions (e.g., L1-L2 bridging, L1 gas calculations, etc.).

Arbitrum Nitro, thanks to its new structure, has various advantages over Arbitrum Classic:

2.1.1 Separation of Execution and Proving

In Arbitrum Nitro, the execution and proving of transactions are performed separately. In Arbitrum Classic, high-level languages (e.g., Solidity, Vyper, …) were once compiled into EVM bytecode, and then this bytecode was transpiled to suit AVM for the fraud proof system.

However, in Arbitrum Nitro, in general cases, it is compiled targeting the native language, whereas, when a challenge comes in from the fraud proof system, it is compiled targeting Wasm bytecode suitable for generating fraud proof.

To put it another way, in Arbitrum Classic, all transactions were inefficiently compiled into fraud-proof code, even outside of dispute periods. In contrast, Arbitrum Nitro significantly improves efficiency by normally compiling into code specific to execution. However, it switches to compile into Wasm code used for fraud proof only during dispute periods.

2.1.2 Transaction Data Compression

As most of the costs incurred in rollup networks are gas fees for storing transaction data in the base layer, compressing transaction data is very important.

Since Arbitrum Classic’s AVM was a custom virtual machine, it was challenging and technically risky to implement a new data compression algorithm. In contrast, Arbitrum Nitro only needs the VM to be compiled into Wasm, so not only geth but any Go code can be used. Since there are already many Go libraries related to transaction data compression, they can easily introduce algorithms to compress transaction data, which can reduce the transaction fees of the rollup network.

2.1.3 Ethereum Compatibility

The Classic AVM had subtle differences from EVM, such as different gas calculation logic, which was a disadvantage because developers had to modify the existing code slightly. However, Arbitrum Nitro has improved these things. Also, since the Arbitrum Nitro stack originally comes mostly from geth, it provides a much higher level of Ethereum compatibility.

2.2 Transaction Lifecycle​

The transaction lifecycle of Arbitrum is as follows:

  1. The sequencer receives transactions from users. Transactions can be received directly at L2 or through the Delayed Inbox contract at L1. Most transactions received from L1 are bridging, and if the sequencer censors, the user can forcibly include the transaction through the Delayed Inbox contract.
  2. The sequencer determines the order of transactions. Currently, Arbitrum uses a centralized sequencer, and transactions are processed on a first-come-first-served basis.
  3. The sequencer collects L2 transactions, creates a batch, and stores it on L1 as calldata.
  4. The rollup block is finalized (if there are no challenges) after a dispute period of one week through the fraud proof system.

3. Settlement​

An interesting fact is that among the existing optimistic rollups, the only networks that have introduced a fraud proof system are Arbitrum One and Arbitrum Nova. Note that only whitelisted validators can participate in Arbitrum’s fraud proof system currently, but Arbitrum recently announced a permissionless validation system called BOLD.

There are two main options in the fraud proof system: ‘interactive proving’ or ‘re-executing transactions’. Arbitrum adopts the former approach. Interactive proving refers to resolving disputes through interaction between the disputing parties. Arbitrum uses a method called dissection, in which the two parties interact to reduce N operations to → N/2 → N/4 → … until one operation step remains, and the validity of this operation is judged.

4. Data Availability​

Currently, there are Arbitrum One and Arbitrum Nova in the Arbitrum ecosystem. The most significant difference between the two is the way they handle transaction data.

Because Arbitrum One stores transaction data directly in the Ethereum network, it can fully leverage the security of Ethereum, but there is a disadvantage of slightly lower scalability. On the other hand, because Arbitrum Nova manages transaction data by off-chain entities called the Data Availability Committee (DAC), it has the advantage of having much higher scalability in optimistic situations than Arbitrum One.

4.1 Arbitrum Nova​

Arbitrum Nova is a network based on the Arbitrum AnyTrust protocol, which is a slightly modified version of Nitro technology. Arbitrum Nitro basically stores transaction data on the Ethereum network as calldata, but Arbitrum AnyTrust relies on an off-chain party called the Data Availability Committee (DAC) for the storage of transaction data. Assuming that there are N members in the DAC, it is designed not to fail if at least two are honest (2-of-N). Typically, in BFT, more than 2/3 of honest actors are needed, but how can the Arbitrum AnyTrust system not fail with only two actors? This is because there is a ‘fallback to rollup’ function in case of system failure.

The Sequencer sends transaction data to the DAC, and the members of the DAC send signatures for storing the data back to the sequencer. If the sequencer cannot collect enough signatures within a certain time, it gives up using the DAC and operates in rollup mode. From then on, the transaction data is stored on Ethereum, not DAC. Therefore, the 2-of-N assumption of Arbitrum AnyTrust is not burdensome, and it can always be valid if N-1 out of N people signed it (assuming at least two are honest, at least one of N-1 must be honest).

5. Team​

6. Resources​

CTRL + J