A Comprehensive Guide to Arbitrum and its Security Features

Arbitrum is a prominent L2 scaling solution for Ethereum created by Offchain Labs. It leverages the concept of optimistic rollups to offer faster transaction processing and reduced congestion on the network. 

There are two main technologies under Arbitrum:

1. The Arbitrum rollup protocol: The Arbitrum rollup protocol is an L2 protocol that uses Ethereum as its base for data availability and security features. It is the flagship product for Arbitrum, which inherits the security of Ethereum, its L1 host. Arbitrum One is a live implementation of the Arbitrum rollup.

2. The Arbitrum Anytrust protocol: The Arbitrum AnyTrust protocol is an important security feature for Arbitrum. AnyTrust allows any honest verifier to ensure the correct execution of transactions on the Arbitrum L2 protocol. The Arbitrum Nova is a live implementation of the Anytrust rollup.

Arbitrum is the most popular optimistic rollup integrated into Ethereum. Its fundamental importance lies in how it handles fraud proofs for Ethereum and achieves full compatibility with the EVM using its own Arbitrum Virtual Machine (AVM).

Compared to other L2 optimistic rollups, Arbitrum uses an improved version of optimistic rollups by implementing multi-stage anti-fraud protection, consuming significantly less gas than Optimism and the others, according to Coinmarketcap.

Before exploring the architecture of Arbitrum, let's learn about its foundational technology.

One of the biggest advantages of L2 solutions is that they fully inherit the security of the L1 blockchain. But how does this work?

Rollups, in a nutshell, submit transactions to the L2 protocol instead of the L1 chain in batches to reduce the amount (and ultimately the cost) of data posted to the L1. The batches of transactions are executed on the L2, including state processes, signature verification, and contract execution. After all these, the transaction data (calldata) summary and proof of computational integrity are sent to the L1 chain for storage. The proof provides evidence of the validity of the transactions in the batch, proves that the internal application logic of the rollup implementation is correctly followed and that the state transition is valid after transaction execution.

The L1 provides security in two ways for the L2:

1. Data validity

This method involves the use of validity or fraud proofs to prove and verify the L2 state is valid. L2 protocols publish their state periodically to the L1 chain by writing the hash of their latest state root. This state root is provided as a cryptographic validity proof using zero knowledge in validity proofs and verified on the L1 by a smart contract. Fraud proofs use honest observers to monitor the layer 2 chain. In the case of any suspected incorrect state root submission to L1, they can raise an alarm and provide the fraud proof, which will result in automatic chain rollback.

2. Data availability

Data availability refers to the ability of users to recreate the state of the L2 network independently in the event of transaction disputes, enabling trustless exits to L1. It ensures that users can demonstrate ownership of their funds when withdrawing or spending them. Achieving data availability typically involves recording L2 transactions on L1 using calldata or utilizing an external data availability layer with cryptographic or crypto-economic guarantees. While calldata posting on Ethereum is costly but practical, alternative techniques may be too expensive. Another approach involves storing data off-chain with a separate custodian.

Optimistic rollups assume that transactions are valid by default unless a fraud-proof state otherwise. The rollup provider posts the transaction data on the chain and waits for a couple of days. If an external validator complains with a fraud proof that the transaction data is invalid, the rollup provider loses its stake, and the transaction rolls back.

Optimistic rollups make use of a sidechain that runs parallel to the host blockchain, i.e., Ethereum. If there is no complaint, the optimistic rollup proposes a new state to the parallel L1, which is then written to the L1 as calldata. Calldata is the data area in an Ethereum contract code that is used to pass arguments to a function and behaves like memory or history logs.

Optimistic rollups are more suitable for general-purpose EVM computations, leaving zk-Rollups more suitable for simple payments. Optimistic rollups are secured because all transaction data is stored on the L1 chain, making the data depend on the security properties of the L1 chain. 

The disadvantages to optimistic rollups are:

• The long wait times for fraud proofs

• Vulnerability to attacks if the value in a roll-up exceeds the amount in an operator’s deposit

• Reliance on the L1 chain for security can be detrimental if the L1 chain gets compromised

• The long wait times before being able to withdraw funds back to Ethereum

• In the absence of honest nodes, a malicious operator can exploit the system by posting invalid blocks and state commitments, allowing them to potentially steal funds

• The order of transactions can be tampered with by the centralized sequencers.

With all this fundamental information sorted, let’s explore deeper into the security features of Arbitrum.

At the time of publication, the Arbitrum Optimistic Rollup (Arbitrum One) has a Total Value Locked of $5.9 billion and a 59% market share amongst all other L2 solutions. This is bigger than the sum of every other ZK and Optimistic Rollups combined. As such, it comes as no surprise that most of the biggest hacks of May 2023 are especially targeted at projects built on Arbitrum. 

In this section, we will briefly summarize the security features and challenges of Arbitrum.

A full analysis of Arbitrum done by the well-known website that compares L2 projects has stated that Arbitrum has several lapses in the security of funds on the protocol. Some of these lapses include:

• If no authorized verifier verifies the published state, funds can be susceptible to theft.

• Operators can extract MEV by frontrunning user transactions by exploiting their centralized position.

• Mistakes in the intricate implementation of Nitro and WASM one-step prover can result in fund losses.

• Funds are at risk of being stolen if a contract undergoes a malicious code upgrade, with a specific delay of 12 days and 9 hours associated with code upgrades.

Fund security is of paramount importance in any blockchain solution, and projects built on Arbitrum must prioritize comprehensive security measures to protect user funds. Partnering with a renowned blockchain security company like Halborn to enhance the security posture of your projects on Arbitrum would inspire the confidence required to serve your users and investors.

In Arbitrum, the Sequencer plays the crucial role of aggregating and posting batches of transactions from the Layer 2 chain to the Ethereum mainnet. However, it's important to note that the Sequencer in Arbitrum is not decentralized. In the case of an anomaly where the Sequencer behaves unexpectedly, there is no way to punish the Sequencer.

In June 2023, there was a disruption in the Sequencer’s batch poster that prevented batched transactions from being posted. There has been a thorough fix for the issue since the same day. 

Although the Arbitrum Sequencer currently takes the form of a single, centralized entity, the team is working on making a distributed committee of sequencers to ensure fairness.

Arbitrum utilizes a validation period as part of its protocol to ensure the security and integrity of transactions. The validation period is a critical component in the process of verifying the correctness of transactions on the Arbitrum chain.

During the validation period, Arbitrum validators examine and validate the state transitions and execution of transactions that occur within the Layer 2 system. This validation process helps ensure that the transactions comply with the predefined rules and consensus mechanisms of the Arbitrum protocol.

The duration of the validation period in Arbitrum is an important parameter that determines the time available for validators to assess the correctness of transactions. It allows validators to detect and reject any fraudulent or invalid transactions that may attempt to manipulate the state of the system. Validators analyze the transactions, check the execution results, and validate the integrity of the state transitions before reaching a consensus on the correctness of the blocks. This validation process adds an additional layer of trust and confidence in the integrity of the Layer 2 scaling solution.

It's worth noting that the specific details of the validation period, such as its duration or any additional mechanisms used in the process, may be subject to changes or updates as the Arbitrum protocol evolves. For the most accurate and up-to-date information on the validation period in Arbitrum, it is recommended to refer to official documentation or resources provided by the Arbitrum development team.

Since Arbitrum validators are self-made, they are expected to stake a significant amount of ETH before validating rollups to verify that they are not cheating or providing false proofs. If the first validator is correct, there is no need for another user to stake or attempt to validate. This process ensures the validity and accuracy of transactions on the protocol.

In conclusion, this article has comprehensively evaluated the security aspects of Arbitrum. We took a brief look at the Arbitrum ecosystem and how they intertwine to provide security to the protocol.

The security analysis of Arbitrum has highlighted both its strengths and weaknesses. On the positive side, the protocol benefits from the security provided by Ethereum's L1, ensuring data validity and availability. Arbitrum has implemented multi-stage anti-fraud protection and offers compatibility with the Ethereum Virtual Machine (EVM) while consuming less gas compared to other L2 solutions.

However, there are some security concerns to consider. The evaluation of Arbitrum reveals lapses in fund security, including risks related to state verification, complex implementations, and contract upgrades. Additionally, the centralized nature of the sequencer raises the possibility of a malicious sequencer, although efforts are being made to transition to a distributed committee to enhance fairness.