Understanding Arbitrum: An Introduction to Ethereum's Next-Generation Layer 2 Solution

What is Arbitrum?

When a transaction is executed on Ethereum through smart contracts, a fee is required to reward the network participants that store such contracts on their machines. As the user base expands and more transactions need to be processed, the transaction fee increases. Furthermore, miners in the Ethereum blockchain must simulate every step of a contract’s execution, which is costly and significantly limits scalability. In addition, all contracts’ codes and data must be made public, unless there is a privacy overlay feature, which incurs its own set of costs.

Arbitrum aims to alleviate network congestion and reduce transaction costs by offloading as much work and data storage as possible from Ethereum’s primary network or layer 1 (L1). Offchain Labs, the company behind Arbitrum, was co-founded in 2018 by Ed Felten, a professor of computer science and public affairs at Princeton. The approach employed by Arbitrum, known as the layer 2 (L2) scaling solution, involves storing data off-chain and is implemented on the Ethereum network to enhance scalability.

How does Arbitrum work?

The Arbitrum ecosystem involves four distinct roles, each fulfilled by verifiers, a virtual machine (VM), a key, and a manager, as elaborated below:

1. Verifier: A distributed protocol/global entity that verifies transactions legitimacy and is responsible for publishing accepted transactions.
2. Key: A protocol member who can own currency and propose transactions. The hash of a public key serves as its identification. A key can propose transactions by signing them with the private key associated with the transaction.
3. VM: A protocol’s virtual participant with code and data that define its operation.
4. Manager: A virtual machine manager is a person who keeps track of a virtual machine’s progress and ensures that it behaves properly.

Arbitrum operates on a straightforward cryptocurrency framework, where participants can execute a smart contract as a Virtual Machine (VM) following the encoded rules of the contract. These VMs run on the Arbitrum Virtual Machine (AVM) Architecture.

The VM's creator appoints a group of managers responsible for overseeing the virtual machine. Through the Arbitrum protocol, any honest manager can ensure that the VM adheres to its specified code.

Stakeholders invested in the VM's outcome can either select a trusted representative or serve as managers directly. In fact, the number of managers for many contracts is expected to be reasonably limited.

Instead of requiring every validator to replicate the execution of each VM, the VM's state can be progressed at a significantly lower cost for verifiers by leveraging managers. Verifiers just need to monitor the hash of the VM's state, not the entire state. Arbitrum provides incentives for managers to reach an agreement on the VM's functioning through an out-of-band arrangement.

Layer 2 scaling solutions on Ethereum

The Ethereum blockchain's current structure is being modified to create layer 2 solutions, primarily aimed at reducing transaction fees and alleviating network congestion.

Implementing scalability changes directly on layer 1, such as increasing the number of approved transactions, poses challenges to the decentralisation and security aspects of the Ethereum blockchain. To address this, Ethereum 2.0 mainnet is set to be introduced soon. However, as an interim solution, layer 2 scaling options like Optimistic Rollups and zero-knowledge (zk) Rollups have emerged. Arbitrum represents an example of a layer 2 expansion rollup, specifically an Optimistic Rollup, designed for the Ethereum blockchain.

Optimistic Rollups operate under the assumption that all new additions to the chain are valid unless contested by a network user within a week. On the other hand, zk-Rollups utilises cryptographic proofs to validate each new block added to the network, eliminating the need for validators to be inherently trusted. While zk-Rollup technology holds the potential to become a leading layer 2 solution in the future, it is more intricate than Optimistic Rollups and requires additional research and development.

What gas does Arbitrum use?

Arbitrum utilises ArbGas to monitor the execution cost on an Arbitrum chain. Each instruction within the Arbitrum VM incurs an ArbGas cost, and the overall cost of a calculation is the sum of the ArbGas fees for the instructions, compared to Ethereum's gas limit.

Unlike Ethereum, Arbitrum does not have a strict ArbGas limit, making it significantly more cost-effective than ETH gas fees. Typically, this fee is imposed to compensate validators for their expenses on the Arbitrum chain, although it defaults to zero.

ArbGas is also applied to proof-check every instruction by the AVM. It is crucial to ensure that the EthBridge does not surpass the L1 gas limit by estimating the required L1 gas for the EthBridge. Additionally, estimating emulation time is vital for determining rollup chain throughput, establishing a safe speed limit for the chain.

ArbGas differs from Ethereum gas as it aims to estimate emulation on AVM, while Ethereum gas serves a similar purpose on the Ethereum network. For instance, accessing storage is notably expensive on Ethereum due to the obligation it imposes on all Ethereum miners, possibly indefinitely.

An extended view: Arbitrum vs. Optimism

Arbitrum and Optimism share a similarity in that they are activated only when detecting faulty blocks rather than with each transaction. Both networks feature cross-chain bridges enabling token movement between layer 1 and layer 2.

In contrast to traditional confirmation sequences, transactions on these networks are verified after block creation, contributing to a network characterised by low latency and high throughput.

While these networks share commonalities, they exhibit differences across various aspects, as illustrated in the table below:

Title	Arbitrum	Optimism
Fraud-proofs	Multi-round fraud proofs	Single-round fraud proofs.
Network performance	High: due to focus on a single point for transaction disagreement	Low: due to reliance on L1 to execute L2 transactions
Virtual Machine	Arbitrum Virtual Machine (AVM)	Ethereum Virtual Machine (EVM)
Programming Languages	Supports all EVM programming languages (Solidity, Vyper, Flint, LLLL, YUL+)	Limited to a Solidity compiler for OVM bytecode
Token usage	Native ETH support	Wrapped ETH (WETH)