In the previous post, we introduced rollups as the currently preferred L2 solution for scaling Ethereum and focused on Optimism.

Today we're going to focus on Arbitrum One, another EVM-compatible optimistic rollup. It was launched on mainnet by Offchain Labs on September 1st, 2021. We then walk through gas fees on Arbitrum, and create a spell on Dune so anyone can query Arbitrum gas fees and compare it with other chains!

**In this post, we’ll refer to the Arbitrum One rollup as Arbitrum for convenience, but note that Offchain Labs also recently launched Arbitrum Nova, another chain designed to serve as the premier solution for Web3 gaming and social applications (cheaper costs, less security). *

To ensure the chain remains safe, optimistic rollups have to specify a dispute period (currently set to 7 days), during which anyone can dispute a state transition.

In the previous post, we saw that Optimism uses a single-round interactive proving model, which means the rollup has to replay and execute the disputed transaction on Ethereum L1 to verify the validity of a fraud proof.

But re-executing individual transactions on L1 increases the data rollups must publish on-chain, and incurs significant gas costs. 

To mitigate these negative externalities, Arbitrum has come up with a different proving method to narrow down the scope of the dispute. This method is referred to as multi-round interactive proving, and involves a back-and-forth dialogue between the block proposer and a challenger overseen by an L1 verifier contract to identify the lying party.

When an L2 node (challenger) submits a fraud proof to challenge a particular block, he asks the block proposer (asserter) to divide the disputed rollup block into two equal halves. The challenger is then asked to choose which part of the block is problematic, and this bisection process continues until both parties narrow down the dispute to a single step of execution. Once this is achieved, this single step can be compared and resolved by the L1 verifier contract to determine its validity!

This multi-round interactive method, by minimizing the amount data posted on-chain, allows for cheaper costs and allows rollup transactions to exceed Ethereum’s gas limit (since they don’t need to be entirely replayed on L1).

Another major difference between Optimism and Arbitrum comes down to their use of the Ethereum Virtual Machine (EVM). On the one hand, Optimism regenesis led to a transition from EVM compatibility to EVM equivalence, a design that brings Optimism close to 1:1 parity with Ethereum.

In other words, it means Optimism can use an out-of-the box Ethereum client like go-ethereum (geth) and is now in complete compliance to Ethereum’s yellow paper specifications and Ethereum Improvement Proposals (EIPs). 

On the other hand, the Arbitrum team made the decision to design their own custom made virtual machine called the Arbitrum Virtual Machine (AVM).

At first, in a version now referred to as Arbitrum “Classic”, high level code (Solidity, Vyper, etc.) was compiled to EVM bytecode, and then converted into AVM instructions by a program called “ArbOS”. The AVM instructions were used to run the L2 virtual machine, as well as executing the multi-round interactive proving before executing the single state transition on the L1 EVM itself.

The Abitrum Classic design was further removed from an Ethereum compatibility standpoint compared to Optimism, but allowed more custom code and operations to validate fraud proofs and optimize gas costs.

On September 1st, 2022, exactly one year after its mainnet launch, Arbitrum introduced the biggest protocol upgrade to date: Arbitrum Nitro.

Nitro introduced a new architecture for the Arbitrum rollup in which geth, the most widely used EVM implementation, is directly integrated into the ArbOs program as a submodule. The effects of this major protocol redesign can be summarized as follows:

1. Better Ethereum Compatibility - Nitro’s usage of geth means a 1:1 equivalence between Ethereum L1 and Arbitrum L2 for gas calculations, as well as a tighter synchronization with L1 block numbers and full support for all L1 pre compiles.

2. Lower gas fees - In Arbitrum Classic, the code executed in the happy/common case was equivalent to the code used in a fraud proof (i.e., always using the AVM). Nitro’s architecture introduced the possibility of separating execution from proving, and performing the multi-round interactive proving if and only if a dispute occurred (see Figure for more details). In cases during which no fraud proof is emitted, Nitro is capable to run native execution code that is far more performant, allowing 7x-10x higher throughput and lower fees for end users. Nitro also allowed the implementation of widely used libraries coded in Go for calldata compression, thus reducing the cost of posting transaction batches. It also introduced a more sophisticated mechanism for determining the price of calldata and ensuring that batch posters are ultimately properly compensated, which we will explore in more detail in the next section.

On Arbitrum, like on any other rollups, users pay gas fees to cover costs of operating the two resources consumed to perform a transaction:

‍1. L1 calldata: a fee per unit of L1 calldata attributable to the transaction as part of a batch posted to Ethereum L1 by the sequencer

2. L2 gas: assessed and collected by ArbOS, an Ethereum equivalent version of gas fees paid for a given transaction including computation, storage and execution on Arbitrum L2

The L1 component exists because the sequencer - also called batch poster - is posting transaction batches on Ethereum as calldata. To determine fees associated with a single transaction, the Arbitrum L1 pricing algorithm computes the transaction’s size, which is an estimate of how many bytes the transaction will add to the compressed batch it is in. This gives a value that represents the ArbGas used for L2 computation, plus an additional buffer. This additional buffer is introduced to make sure that the total amount paid at the given gas price is enough to cover both the L1 and L2 dimensions of the fee.

On Dune, the value representing the ArbGas used + the additional buffer is expressed as the gas_used column in the arbitrum.transactions table. Note that Arbitrum transaction receipts also show the actual amount of gas used on L1 in units of L2 gas, denoted gas_used_for_l1. 

The L2 component consists of the traditional computation, storage and execution charges paid on an L1 chain to cover the cost of a transaction. 

L2 gas fees are computed using a mechanism equivalent to Ethereum Mainnet post EIP-1559 (see Fueling Gas Spells on Dune part 1), called “exponential mechanism”, to adjust the L2 base fees relative to gas usage.

Since the sequencer on Arbitrum works on a first come first serve basis, L2 ignores the equivalent of EIP-1559's “tip” (i.e., also referred to as the priority fee on Ethereum). A small percentage increase buffer is added (any excess gets refunded) and results in the gas_price column on Dune.

Moreover, the L2 gas price on Arbitrum has a set floor currently set to 0.1 gwei. To get the actual gas price at which the transaction fee was paid after the excess is refunded, we need to use the effective_gas_price column.

In sum, this simple formula allows to compute the total transaction fees paid for transactions on the Arbitrum rollup:

Total transaction fee = gas_used_for_l1 * effective_gas_price

Next step is to write the query with all the information necessary to build the Arbitrum gas fees spell, standardize the column names and add it to the Spellbook Github repo!

Once this is done, we can easily compare transaction fees between L2 rollups using queries such as:

SELECT block_date as date, blockchain,         CASE WHEN blockchain = 'arbitrum' THEN AVG(tx_fee_usd)            WHEN blockchain = 'optimism' THEN AVG(tx_fee_usd)            ELSE NULL END AS tx_fees FROM gas.fees WHERE block_date > now() - interval '4 months' AND block_date < '2022-10-20' GROUP BY 1,2

…to produce charts like the one below, showing us the impact of the Nitro upgrade on September 1st that brought the average transaction fees consistently down below 10 cents, effectively making Arbitrum cheaper than its main competitor Optimism.

We’ve seen a lot of innovation coming from L2 rollups in the past couple of years, but this is far from being over.

If you’re interested about what’s to come, keep an eye out for Ethereum upgrades relative to sharding that will bring the fees down by order of magnitude, and ZK rollups solutions like ZKsync, Starknet, or Polygon zkEVM coming to mainnet sooner than expected!

In the previous post, we introduced rollups as the currently preferred L2 solution for scaling Ethereum and focused on Optimism.

Today we're going to focus on Arbitrum One, another EVM-compatible optimistic rollup. It was launched on mainnet by Offchain Labs on September 1st, 2021. We then walk through gas fees on Arbitrum, and create a spell on Dune so anyone can query Arbitrum gas fees and compare it with other chains!

**In this post, we’ll refer to the Arbitrum One rollup as Arbitrum for convenience, but note that Offchain Labs also recently launched Arbitrum Nova, another chain designed to serve as the premier solution for Web3 gaming and social applications (cheaper costs, less security). *

To ensure the chain remains safe, optimistic rollups have to specify a dispute period (currently set to 7 days), during which anyone can dispute a state transition.

In the previous post, we saw that Optimism uses a single-round interactive proving model, which means the rollup has to replay and execute the disputed transaction on Ethereum L1 to verify the validity of a fraud proof.

But re-executing individual transactions on L1 increases the data rollups must publish on-chain, and incurs significant gas costs. 

To mitigate these negative externalities, Arbitrum has come up with a different proving method to narrow down the scope of the dispute. This method is referred to as multi-round interactive proving, and involves a back-and-forth dialogue between the block proposer and a challenger overseen by an L1 verifier contract to identify the lying party.

When an L2 node (challenger) submits a fraud proof to challenge a particular block, he asks the block proposer (asserter) to divide the disputed rollup block into two equal halves. The challenger is then asked to choose which part of the block is problematic, and this bisection process continues until both parties narrow down the dispute to a single step of execution. Once this is achieved, this single step can be compared and resolved by the L1 verifier contract to determine its validity!

This multi-round interactive method, by minimizing the amount data posted on-chain, allows for cheaper costs and allows rollup transactions to exceed Ethereum’s gas limit (since they don’t need to be entirely replayed on L1).

Another major difference between Optimism and Arbitrum comes down to their use of the Ethereum Virtual Machine (EVM). On the one hand, Optimism regenesis led to a transition from EVM compatibility to EVM equivalence, a design that brings Optimism close to 1:1 parity with Ethereum.

In other words, it means Optimism can use an out-of-the box Ethereum client like go-ethereum (geth) and is now in complete compliance to Ethereum’s yellow paper specifications and Ethereum Improvement Proposals (EIPs). 

On the other hand, the Arbitrum team made the decision to design their own custom made virtual machine called the Arbitrum Virtual Machine (AVM).

At first, in a version now referred to as Arbitrum “Classic”, high level code (Solidity, Vyper, etc.) was compiled to EVM bytecode, and then converted into AVM instructions by a program called “ArbOS”. The AVM instructions were used to run the L2 virtual machine, as well as executing the multi-round interactive proving before executing the single state transition on the L1 EVM itself.

The Abitrum Classic design was further removed from an Ethereum compatibility standpoint compared to Optimism, but allowed more custom code and operations to validate fraud proofs and optimize gas costs.

On September 1st, 2022, exactly one year after its mainnet launch, Arbitrum introduced the biggest protocol upgrade to date: Arbitrum Nitro.

Nitro introduced a new architecture for the Arbitrum rollup in which geth, the most widely used EVM implementation, is directly integrated into the ArbOs program as a submodule. The effects of this major protocol redesign can be summarized as follows:

1. Better Ethereum Compatibility - Nitro’s usage of geth means a 1:1 equivalence between Ethereum L1 and Arbitrum L2 for gas calculations, as well as a tighter synchronization with L1 block numbers and full support for all L1 pre compiles.

2. Lower gas fees - In Arbitrum Classic, the code executed in the happy/common case was equivalent to the code used in a fraud proof (i.e., always using the AVM). Nitro’s architecture introduced the possibility of separating execution from proving, and performing the multi-round interactive proving if and only if a dispute occurred (see Figure for more details). In cases during which no fraud proof is emitted, Nitro is capable to run native execution code that is far more performant, allowing 7x-10x higher throughput and lower fees for end users. Nitro also allowed the implementation of widely used libraries coded in Go for calldata compression, thus reducing the cost of posting transaction batches. It also introduced a more sophisticated mechanism for determining the price of calldata and ensuring that batch posters are ultimately properly compensated, which we will explore in more detail in the next section.

On Arbitrum, like on any other rollups, users pay gas fees to cover costs of operating the two resources consumed to perform a transaction:

‍1. L1 calldata: a fee per unit of L1 calldata attributable to the transaction as part of a batch posted to Ethereum L1 by the sequencer

2. L2 gas: assessed and collected by ArbOS, an Ethereum equivalent version of gas fees paid for a given transaction including computation, storage and execution on Arbitrum L2

The L1 component exists because the sequencer - also called batch poster - is posting transaction batches on Ethereum as calldata. To determine fees associated with a single transaction, the Arbitrum L1 pricing algorithm computes the transaction’s size, which is an estimate of how many bytes the transaction will add to the compressed batch it is in. This gives a value that represents the ArbGas used for L2 computation, plus an additional buffer. This additional buffer is introduced to make sure that the total amount paid at the given gas price is enough to cover both the L1 and L2 dimensions of the fee.

On Dune, the value representing the ArbGas used + the additional buffer is expressed as the gas_used column in the arbitrum.transactions table. Note that Arbitrum transaction receipts also show the actual amount of gas used on L1 in units of L2 gas, denoted gas_used_for_l1. 

The L2 component consists of the traditional computation, storage and execution charges paid on an L1 chain to cover the cost of a transaction. 

L2 gas fees are computed using a mechanism equivalent to Ethereum Mainnet post EIP-1559 (see Fueling Gas Spells on Dune part 1), called “exponential mechanism”, to adjust the L2 base fees relative to gas usage.

Since the sequencer on Arbitrum works on a first come first serve basis, L2 ignores the equivalent of EIP-1559's “tip” (i.e., also referred to as the priority fee on Ethereum). A small percentage increase buffer is added (any excess gets refunded) and results in the gas_price column on Dune.

Moreover, the L2 gas price on Arbitrum has a set floor currently set to 0.1 gwei. To get the actual gas price at which the transaction fee was paid after the excess is refunded, we need to use the effective_gas_price column.

In sum, this simple formula allows to compute the total transaction fees paid for transactions on the Arbitrum rollup:

Total transaction fee = gas_used_for_l1 * effective_gas_price

Next step is to write the query with all the information necessary to build the Arbitrum gas fees spell, standardize the column names and add it to the Spellbook Github repo!

Once this is done, we can easily compare transaction fees between L2 rollups using queries such as:

SELECT block_date as date, blockchain,         CASE WHEN blockchain = 'arbitrum' THEN AVG(tx_fee_usd)            WHEN blockchain = 'optimism' THEN AVG(tx_fee_usd)            ELSE NULL END AS tx_fees FROM gas.fees WHERE block_date > now() - interval '4 months' AND block_date < '2022-10-20' GROUP BY 1,2

…to produce charts like the one below, showing us the impact of the Nitro upgrade on September 1st that brought the average transaction fees consistently down below 10 cents, effectively making Arbitrum cheaper than its main competitor Optimism.

We’ve seen a lot of innovation coming from L2 rollups in the past couple of years, but this is far from being over.

If you’re interested about what’s to come, keep an eye out for Ethereum upgrades relative to sharding that will bring the fees down by order of magnitude, and ZK rollups solutions like ZKsync, Starknet, or Polygon zkEVM coming to mainnet sooner than expected!