Broadly speaking, Arbitrum refers to a set of tools, protocols, and blockchains that work together to greatly expand the throughput of the Ethereum network, the world’s largest smart-contract platform. It’s known as a Layer-2 (L2) scaling solution.

At the time of writing, Arbitrum is the premier L2 for Ethereum. It has the largest user base and is considered to provide some of the biggest efficiency improvements to the network. Additionally, Arbitrum is built to be as compatible with Ethereum as possible. It uses much of the same architecture and software as Ethereum, which makes deploying existing Ethereum-based applications to it exceedingly simple.

If you’ve been in the blockchain space long enough, you’ve undoubtedly come across the topics of scalability and layers. There is a lot of confusion surrounding – and misappropriation involving these topics – especially when it comes to layers. While there are many popular terms involving layers, only two find their roots in proper technical documentation. 

Layer 1

“Layer 1” is what we’re all familiar with. Bitcoin, Ethereum, BNB Chain, Cardano, NEAR. These and many more blockchain networks are considered Layer 1s. They provide immutable, permissionless, decentralized databases and — in cases where they’re “smart contract-enabled” — include the software environments necessary to build and deploy decentralized applications (dApps). 

Layer 2

“Layer 2” refers to Layer-2 scaling solutions. These are networks separate from Layer 1s that help them scale (i.e. improve their ability to handle a growing number of users). 

What Other Blockchain Layers Are There? 

People in crypto often talk about other layers like Layer 0 (the “infrastructure” layer) and Layer 3 (the “application” layer). These terms are inconsistent, confusing, and colloquial at best, and they tend to be perpetuated by marketing hype. Most importantly, they don’t come from any official technical language, but rather from popular trends that have adopted them to promote specific conversations. 

Scaling a blockchain network most commonly refers to the act of increasing its ability to process more transactions (throughput) while keeping gas fees low in order to accommodate the demands of a growing user base. 

As networks like Ethereum acquire more users, they’re required to process more transactions. The presence of many limitations on L1 blockchains (some technological, others built-in) makes scaling them difficult. This results in all sorts of problems, like exorbitant fees and long waiting times. For this reason, developers are searching for ways to increase transaction processing efficiency via external solutions. 

How Do Layer 2 Scaling Solutions Work?

L2s are numerous in the ways they tackle the problem of expanding a blockchain’s throughput.

They all involve technology that works separately from the blockchain network that requires scaling. Many of these solutions use separate networks that work “on top” of a host (Layer 1) in order to take over much of its processing.

Arbitrum is based on rollups. This type of L2 scaling solution relies on the L1 chain for security but processes transactions on a separate network in a far more efficient manner. The processed transactions are “rolled up” in batches and sent to the main chain to be recorded, hence the name “rollup.”

Arbitrum uses optimistic rollups which derive their name from the fact that, under normal conditions, the protocol assumes participants are acting honestly (which significantly speeds up transaction processing). 

Crucially, optimistic rollups don’t use any sort of mechanisms to prove that the transaction data sent to L1 is valid: They just use Layer 1’s superior security to store an accurate record of the data. Validators then use that data to validate blocks on the L2 chain. These “optimistic” assumptions – and the nature of the validation process – are why operations like L2 to L1 transfers can take more than a week to complete. 

The lifecycle of an Arbitrum transaction involves a number of aspects that are beyond the scope of this article. The official documentation provides a more in-depth look into the topic.

What follows is a somewhat simplified explanation of the process: It covers only what happens on Arbitrum One, the main blockchain in the ecosystem. 

Part 1: Collecting, Ordering, & Executing Transactions 

When users interact with Arbitrum, they can do so from two points.

• Layer 1 (Ethereum), where transactions are pushed to the Delayed Inbox (ie. “Slow Inbox)

• Layer 2 (Arbitrum), where transactions go directly to the chain’s Core Inbox (ie. “Fast Inbox”)
  

No matter the source, all transactions ultimately end up passing through an entity known as the Sequencer. 

This entity can have many forms. At the time of writing, it exists as a centralized Arbitrum full node, maintained by the Arbitrum team. Its main function? Ordering and preparing transactions for processing.

Once transactions are in their final order, they’re executed by The Sequencer locally, in the Layer 2 virtual environment (i.e. Arbitrum Nitro VM). When this happens, a receipt is sent to the transaction’s issuer within a few seconds, representing a “soft confirmation”. 

What Happens if the Sequencer Isn’t Working Properly?

In this very unlikely case, The Arbitrum Sequencer can only slow down the process but can’t derail it completely. A mechanism is built into the Sequencer to force-include transactions into the L2 chain’s inbox. If transactions can’t reach the core inbox through the L2 path, they can be submitted through the L1 (where they’ll go through the delayed inbox). From there, they can be force-included in the core inbox. 

Additionally, The Sequencer’s abilities are limited to ordering and executing transactions it has received. It can not generate transactions itself and thus cannot influence the validity of the chain’s state. 

Part 2: “Rolling Up” Batches and Posting Them to Layer 1

With the transactions sequenced and executed on Layer 2, they’re ready to be “rolled up” into a batch and posted to Layer 1. 

Think of rolling up a batch as compressing its data. Transaction details arrive on L1 as calldata and are fed into a receiving contract through which they’re ultimately recorded to the Ethereum blockchain. 

Part 3: Assertions, Disputes, and Verifications

Once the batch is recorded on L1, Arbitrum validator nodes can look at the data and re-execute the transactions (again, using Arbitrum Nitro VM) in order to make “assertions” about the L2 chain’s current state. 

There’s a one-week time window (called the “challenge period”) when assertions can be disputed by other validators. If there are no disputes, the Rblock is considered valid and becomes a permanent part of the L2 chain. This is commonly referred to as the “happy” case. 

In the case of a dispute, a special protocol is engaged in order to resolve it. 

The Dispute Resolution Protocol

Let’s say two validators disagree on the validity of an assertion. In this “unhappy” case, the challenger and the asserter (i.e. challenged) begin a game where they take turns narrowing down the source of their disagreement down to a single block on Layer 2, then down to a single operation within that block. 

Here is where the assumption of validity originates. One side of this argument is always correct, and the valid block is guaranteed to be revealed eventually (assuming the participation of at least one honest validator [more on this later]). 

Part 4: Confirmation

After all existing disputes have been resolved, the Rblock can be confirmed on L1. 

Importantly, L1 confirmations don’t affect transaction finality on L2. There, finality is “assumed” much earlier. The reason it can be assumed is that validators adding to the valid leaf of the blockchain keep doing so, even if bad actors try to create alternate, invalid versions. The latter will ultimately be defeated and lose a lot of money in the process, and the valid state of the chain will carry on existing as if nothing ever happened. 

This is true due to the way the validation process works: Honest validators can compute valid states with complete accuracy from just a few data points which are all securely stored on L1 (Ethereum). 

The downside to this method is the waiting period associated with cross-layer transactions. But even then, clients pursuing honest transactions have a guarantee that their transactions will be recorded, just not immediately. 

Once again, this all hinges on the assumption that there is at least one honest validator. 

There’s no denying that Arbitrum is a complex system. It incorporates many complicated procedures in order to achieve its purpose of scaling the world’s most popular smart contract-capable blockchain network (Ethereum). 

Pros of Arbitrum

Arbitrum is very effective. It innovates on previous scaling solutions and makes for a near-seamless user experience for both developers and end-users. Where Arbitrum shines for users is in its ease of use and cost-effectiveness. Arbitrum gas fees are incredibly low compared to its L1 counterpart. For those building on Ethereum, it’s the closest thing to a plug-and-play experience that currently exists. 

Porting existing Ethereum applications to the L2 is easy. For this reason, Arbitrum already features an impressive ecosystem of dApps and protocols. 

Pros include: 

• Large throughput 

• Low fees

• Privacy

• Permissionless validation (Note: Validation is still permissioned under Mainnet Beta)

• Ultra-high Ethereum compatibility

• Large partner ecosystem (dApps running on Arbitrum)
  

Cons of Arbitrum 

Arbitrum is complex and relies on a few performance assumptions and compromises whose sustainability can really only be confirmed as the network matures. 

Generally speaking, the biggest issue with the network and optimistic rollups is the reliance on time as a requirement for security. Arbitrum needs a substantial amount of time to facilitate cross-layer transactions, specifically due to this constraint. The system is very secure and can recover (in theory) from any malicious activity if it’s given enough time. However, its weakness is that it can be slowed down significantly if a bad actor finds it worth the cost to do so.

However, Arbitrum Co-Founder Ed Felten recently teased an innovative solution to this problem which will be implemented with the next version of the protocol. 

Cons include: 

• Trust assumptions paired with temporary centralization in some areas (like The Sequencer)

• Long waiting times for cross-layer transactions (especially L2 to L1 transfers using Arbitrum Bridge which can take ~8 days)

• Susceptibility to attacks aimed at slowing down the network (“delay attacks”)

Arbitrum is an Offchain Labs project. 

Offchain Labs was founded in 2018 by Ed Felten, Steven Goldfeder, and Harry Kalodner. The three founders are former Princeton University colleagues who specialized in Computer Science. 

Offchain Labs underwent three funding rounds which raised a total of $123.7m. The company is backed by some of the industry’s most prominent VCs (e.g.Pantera Capital, Lightspeed Venture Partners, Coinbase Ventures). 

No, there is no official Arbitrum token at the moment. However, interest in a potential token release spiked after Arbitrum’s main competitor, Optimism launched the OP token. Following an enigmatic tweet by Offchain Labs SEO Steven Goldfeder, rumors of an imminent “ARBI or ARB” token release appear to have died down. The tweet in question seems to have been related to the Arbitrum network’s Nitro upgrade, which was expected at the time. 

Due to its excellent Ethereum Virtual Machine (EVM) compatibility, the Arbitrum network has seen its ecosystem grow at an impressive pace. 

Most of DeFi’s more prominent players – including the likes of Uniswap, Aave, and Chainlink – are ecosystem partners. Additionally, many of the top Centralized Exchanges (CEXs) like Binance and Crypto.com are integrated with Arbitrum as well. Hundreds of other DEXs, wallets, and blockchain games have also found their home with the network. Gaming is particularly popular on the L2. 

Competition in the L2 world is fierce at the moment. So much so that people have started calling it “The L2 Wars.” On the other hand, it’s also a bit of a fallacy: Projects that build scaling solutions aren’t fighting over a fixed number of users but are rather working to expand the usability (and therefore the user base) of the entire blockchain ecosystem. 

So while different L2s are competing for their place at the top, they’re also aligned in their pursuit of a common goal instead of playing a zero-sum game. 

Arbitrum vs Optimism

The second biggest L2 at the moment — and arguably Arbitrum’s biggest competitor — is Optimism, also an optimistic rollup. The two L2s share a number of similarities due to the nature of their underlying design. Where they differ, however, is in how they handle validation and dispute resolution. 

Unlike Arbitrum, Optimism resolves disputes by executing entire L2 transactions on L1 to confirm chain validity. Arbitrum, on the other hand, narrows down the disagreement to a single operation and executes only that operation on-chain (L1). 

Since Arbitrum doesn’t execute L2 transactions on L1 to confirm them, this frees it from L1's gas limit, opening the door to more complex computations that are currently impossible on Ethereum. 

Other concerns involve Optimism’s ability to adapt to changes in Ethereum’s design. 

Arbitrum vs zkSync 

Another “hot” L2 scaling solution design right now is ZK rollups. These rely on cryptographic methods (known as zero-knowledge proofs) which allow parties to validate a statement without having to reveal it. 

The most prominent among the ZK L2s is zkSync. It has some distinct advantages compared to optimistic rollups (ORs) like Arbitrum, most of which revolve around security. 

zkSync substitutes ORs’ game theory-based incentive mechanisms for validators with pure math (cryptography). The “optimistic” element is removed and replaced with a mathematical guarantee of validity. It also features quick withdrawals as opposed to the weeklong waiting period on ORs. 

For smart contract capability, zkSync 2.0 was developed and is EVM-compatible.

Abitrum vs StarkNet

Another exciting L2 is StarkNet which also uses ZK proofs but of a different kind to the ones used by zkSync. StarkNet is based on zkSTARKs which are quantum-resistant. 

Its biggest downside (depending on who you ask) is its lack of EVM compatibility. StarkNet uses a programming language called Cairo which isn’t native to the EVM. However, a Solidity to Cairo transpiler called Warp has been developed by the team behind StarkNet. 

While there is currently no Arbitrum token, that doesn’t mean you can’t extract value from the network’s massive success. There are hundreds of dApps already deployed to Arbitrum and an incredibly loyal, rapidly-growing community. 

GMX is Arbitrum’s biggest decentralized exchange (DEX). It features a Total Value Locked (TVL) of nearly half a billion dollars. Its token (GMX) has been steadily growing throughout the second half of 2022. 

Seeking out and investing in Arbitrum-native projects is proving to be a lucrative strategy for many at the moment. Of course, it goes without saying: Always do your research before investing in crypto.

We’re happy to announce that Sonar is releasing its own Arbitrum node to power its proprietary blockchain indexing solution, ecosystem of analytics, and portfolio management tools (Sonar Studio and Sonar Wallet). 

That’s why we’re gathering real-time data on what’s happening on Arbitrum – straight from the source. This is part of our ongoing effort to index all the major blockchains and provide Sonar users with ultra-fast, accurate, price, and transaction data.