Arbitrum uses ArbOS to run the blockchain. This system provides cross-chain communication, layer 2 fee economics and blockchain administration.

Arbitrum Virtual Machine (AVM)

The Arbitrum team has created a custom VM that is compatible with the EVM. Since transactions are performed at Layer 2, the environment had to be modified to be compatible with decentralized applications (dApps) running at Layer 1.

One of the main differences between AVM and EVM is the usage of "code points." Normally, during code execution, instructions are stored in a linear array with a program counter (PC) that points to the current instruction. Using a program counter to show which instruction is currently being executed would take a long time. To reduce this time, the Arbitrum team implemented code points as a  pair: the current instructions and the hash of the subsequent code point. Each instruction in the array has its own code point. This allows AVM to immediately prove which instruction was executed on a given program counter. Code points do indeed add some complexity to AVM, but the Arbitrum blockchain only uses them when it needs to perform proof of transaction. Otherwise, it uses a conventional program counter architecture.

Arbitrum was upgraded in August 2022 to its system called Nitro. Let’s discuss its new features:

• Sequencing and subsequent deterministic execution
• Geth built into the core
• Separate execution and checking of transactions
• Optimistic Rollup with interactive Fraud Proofs

Sequencing and subsequent deterministic execution

The user sends the transaction to the sequencer after creating it. Sequencers receive transactions, sort them into sequences, and publish them.

During the checkout process, the sequenced transactions are checked one by one (account balances, contract codes, etc.). Once a sufficient number of transactions have been checked, the compressed transactions are sent to layer 1 for finalization.

The state transition function is deterministic, which means that it only depends on the current state and the next transaction – and nothing else. Due to this determinism, the outcome of a transaction T depends only on the state of the genesis chain, the transactions preceding T in the sequence, and the transaction itself.

Anyone who knows the sequence of transactions will be able to determine the previous state. The Nitro nodes function in this manner (they receive the sequence of transactions and create additional blocks).

A deterministic algorithm is an algorithm that always produces the same results (so that it is predictable) from the same initial conditions (input).

Geth built into the core

The 'Geth' refers to the 'go-ethereum' application, which is one of the most common node management software used in Ethereum's network.

The Go-Ethereum program is written in the GO programming language, as is the entire Nitro.

• A node's functionality includes handling connections and requests from clients, as well as providing other top-level functions for operating an Ethereum blockchain-compatible node
• ArbOS is a custom software designed for the Arbitrum blockchain that ensures the smooth operation of Layer 2
• Geth core is the core of the Geth system that emulates the operation of Ethereum smart contracts and maintains the data structures that maintain the Ethereum blockchain state (Nitro is presented as a software library in this code with a few minor modifications that add necessary improvements).

Separate execution and checking of transactions

The Nitro uses the same source code for both execution and checking, but they are used in different ways:

• Execution uses the Go compiler to produce native code for the target architecture, which will of course vary for different nodes
• The Go compiler compiles a section of the code into WebAssembly (WASM), which is a typed machine code format. After a simple transformation is performed on the WASM code, we are left with a format we call WAVM. In the event of a dispute regarding the correct result of a determination, WAVM will resolve the matter.

Optimistic Rollup with interactive Fraud Proofs

Optimistic Rollup

Arbitrum uses rollups, which means that all transactional data on the Arbitrum blockchain (Layer 2) is passed to Layer 1 as an aggregate of blocks, which are then recorded on the Ethereum blockchain. The information provided here allows everyone to determine the current correct state of the blockchain. The entire transaction history of the blockchain is available, so that the state of the blockchain can be reconstructed using only publicly available data if necessary.

Arbitrum (like its L2 competitor Optimism blockchain) is "optimistic", meaning that Arbitrum creates blocks (rollups) of its blockchain by allowing anyone (the validator) to publish on layer 1 a block from the rollup they claim is correct, and then allowing everyone else to challenge it. Upon expiration of the challenge period of 7 days (valid as of January 2023) and no one challenges the declared block from the rollup, Arbitrum will confirm the block summary as accurate. Arbitrum will use a system of fraud proofs to determine which party is cheating if anyone disputes the claim within the deadline – interestingly, competitor Optimism has renamed them "fault proofs" because of the negative connotation. If cheating is confirmed, the cheater will lose his deposit, which will be divided between the person who reported it and part of it will be burned.

Interactive Fraud Proofs

As the proof of possible fraud is handled by a mechanism called ChallengeManager, it follows the following steps: the block challenge, the execution challenge, the general bisection protocol (general interval halving protocol), and the winning challenge (decision on who wins the challenge).

• Block challenge: Initially, the challenge is divided into two parts based on global states (including block hashes). Once the dispute has been narrowed down to individual blocks, the challenger can invoke the next step: the execution challenge, to begin the process of verification.
• Execution challenge: The actual proof can be divided once the blocks have been narrowed down to single blocks. Once the proving has been divided into steps, the challenger can invoke oneStepProveExecution. Data must be provided as proof of fraud by the actual challenger. In the event that the data provided by the challenger proves to be accurate, the challenger wins.
• General bisection protocol: During each round of the "game," the current challenger is required to challenge two adjacent sections. Specifically, he challenges his opponent's claim, executes the first section for a specified period of time (number of steps), and then creates the second section. At this point, both parties agree that the first section is correct, but disagree about the second section. The respondents are required to submit a bisection with a starting section that is identical to the first section, but with an ending section that differs from the second section. As a result, the problem is divided into smaller time periods, and now it is his opponent's turn to solve the problem. In order to ensure that the task progresses, each bisection must have a degree that corresponds to min (40, numStepsInChallengedSegment). Furthermore, bisections of length onesection cannot be divided. It depends on the challenge phase what gets executed, either challengeExecution or oneStepProveExecution. The sectioning is symmetrical, with each participant taking turns selecting which section to mark for subsequent inspection.
• Winning challenge: The process of winning a challenge is not instantaneous. As a result, the current challenger is declared the winner and the hash is set to 0. When the time limit expires, the side will lose since it has no valid moves. It is done as a precaution to ensure that if the challenge is resolved incorrectly, an update of the contract will allow time to diagnose and correct the error.