What is Arbitrum? An Etherem’s Next-Gen 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 implement a smart contract as a 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 of the VM’s outcome can either select a trusted representative to act on their behalf or serve as managers directly. In fact, the number of managers for many contracts will 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 relying on 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 out-of-band agreement on the VM’s functioning. Changes in state will be accepted only when all of the managers reach a consensus.

When you run a decentralised application (Dapp) on the Arbitrum ecosystem, you can select your group of validators to perform the consensus process. This means that the validators working on one app cannot interact with any other Arbitrum app, which is totally different from Ethereum, where each validator keeps track of all the network’s apps. The benefit is less connection between nodes, meaning faster processing of transactions. 

Layer 2 scaling solutions on Ethereum

Layer 2 (L2) is a collective term for Ethereum scaling solutions that handle transactions off Ethereum layer 1 (the base blockchain) while taking advantage of the robust decentralised security of Ethereum layer 1 (L1). In essence, a layer 2 is a separate blockchain extending Ethereum. 

There are different types of layer 2 with unique features and security models. Some popular ones include Optimistic Rollups and zero-knowledge (zk) Rollups. Imagine that you are buying something as a group so that you still have your goods while having to pay less fees. Rollups work the same way. They indeed roll up (group) hundreds of transactions into a single transaction on L1. This distributes the L1 transaction fees to everyone in the rollup, so it’s cheaper for each user.

The transaction data in the rollup is submitted to L1, but the execution is done separately by the rollup. By uploading transaction data onto layer 1, rollups inherit Ethereum’s security. This is because reverting a rollup transaction would require reverting Ethereum itself. There are two main types of rollups: Optimistic and zero-knowledge, which differ mainly in how they submit transaction data to layer 1.

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 uses 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, so it is 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.

Arbitrum Ecosystem

Arbitrum is now Ethereum’s leading ecosystem with 888 projects in 5 main categories – DeFi, Bridges and On-ramps, Gaming, NFTs, and Infrastructure & Tools. 

How to run your Dapp on Arbitrum?

To deploy your DApp on Arbitrum, you’ll need the Arbitrum compiler, EthBridge, and a validator implementation, all of which are open-source and accessible via Github from Offchain Labs.

Start by utilising the Arbitrum compiler to compile your Solidity contracts, resulting in the creation of an Arbitrum Virtual Machine (AVM). Next, select a group of validators to oversee your VM’s execution and ensure its correctness.

Validators can be chosen by the VM builder, and observers may also be appointed to monitor the VM’s actions without the responsibility of ensuring accuracy, as validators do.

Arbitrum provides the AnyTrust Guarantee, assuring that your VM will operate correctly as long as at least one of its validators is online and operating honestly. Once prepared, use EthBridge to instruct the running of your VM on Arbitrum and identify the VM’s validators. Your VM is now operational on Arbitrum.

Users of your DApp can access your existing front-end interface through their browsers. Through background communication with validators, the front-end will seamlessly interact with the running VM. Users can deposit funds into their Arbitrum wallet, enabling them to make calls to the VM and send ETH or other Ethereum-based tokens to the VM.

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: