Arbitrum Blog

Smarter Gas Fees on Arbitrum With Dynamic Pricing

Share this article:
Smarter Gas Fees on Arbitrum With Dynamic Pricing

Any person who has used the blockchain today will have had to pay gas fees in order to run transactions. These gas fees represent the resource costs that are used when powering a transaction. These include simple tasks such as sending token transfers to a friend or business, or more complicated activities such as deploying a smart contract.

Today, Arbitrum One inherits Ethereum’s gas model where each EVM opcode is assigned a single one-dimensional scalar gas cost. This one-dimensional model is simple and easy to understand, but it does not reflect the diversity of a node’s computing power and storage that are consumed when the transaction is executed. When the one-dimensional gas price increases, it increases for all transactions, no matter what types of resources those transactions consume.

Dynamic Pricing proposes to alter the gas pricing algorithm so that resource consumption is accurately reflected, which means you pay for exactly what you use, unlocking cheaper, more predictable transactions for everyone. This blog post aims to explore the motivation, proposed design, and how things may look if Dynamic Pricing were to be implemented on Arbitrum.

One-Dimensional Gas Pricing

As previously mentioned, gas costs on Arbitrum today are one dimensional and each EVM opcode has a fixed cost in gas units. For example the ADD instruction costs three gas units, while other more complex operations such as SSTORE or CREATE2 can cost thousands. 

When calculating gas costs today, the total gas used by a transaction is multiplied by the gas price (which is denominated in wei). This method of calculating gas is simple, and has served the ecosystem well. It provides a clean abstraction and is a straightforward way to reason about costs. However, there are limitations.

A one dimensional gas model can not differentiate between operations that stress different system resources. For example, 10,000 gas of ADD primarily consumes CPU, while 10,000 gas of SSTORE creates a consistent state growth that impacts long-term storage. In the current model these are priced the same. 

Introducing a more complex multi-dimensional gas model allows differences to be captured more precisely, and better reflect the true variety of resources consumed, subsequently opening the door to new economic levers. 

A Multi-Dimensional Gas Pricing System

Dynamic Pricing, or more descriptively, a multi-dimensional gas pricing system, can make gas costs more representative of actual network resource usage. 

The EVM Resource Pricing Working Group has also been investigating the use of multi-dimensional gas pricing, in their case for L1. The transaction patterns, workloads, and user profiles between an L1 and L2 are slightly different, and their analysis divides gas units into 8 dimensions as opposed to our less fine-grained 5, but the trends appear to be broadly similar in terms of overall breakdown. Their later proposal also suggests that multidimensional gas pricing could improve throughput by 240% based on historical transaction data. 

Offchain Labs proposes using a model that tracks gas usage across five distinct resources (or dimensions). It is worth noting that there are certainly more than five types of underlying resources in a blockchain system; however, we believe these five selected resources represent a practical and meaningful subset for pricing purposes:

  1. Computation: Fast operations which are handled in memory or local cache.
  2. State Access: Reading or updating existing values in the state without increasing its size.
  3. State Growth: Increasing the size of the state a node has to maintain.
  4. History Growth: Mostly relevant to logs and events, these are stored separately from the state and are accounted for separately.
  5. Calldata: Transaction input that impacts both execution and network bandwidth. This includes both the gas required to post to the L1 (Ethereum), and the calldata used in the L2 itself.

Using this model, each opcode is analysed and broken down into its interactions and resource consumption across these different dimensions. With ADD, for example, its usage will be purely computational, while CREATE2 would include computation, state access and state growth. 

According to Offchain Labs, around 50% of today’s transaction resource usage is computation, with the remainder split between the other resources. This breakdown suggests that pricing along these dimensions are practical and measurable, reflecting patterns of real-world resource usage. Additionally, state-manipulation-heavy transactions (like those that write a lot of data into the state) take significantly longer to execute, so individual gas units are not all equal in how they affect performance or scalability. 

Another noteworthy fact is that the gas rate associated with state growth tends to remain relatively stable over time. This stability supports the case for treating state growth as its own explicitly priced dimension and highlights that storage-related resource consumption is predictable enough to be modeled more directly.

Pricing with Constraints

Arbitrum’s model suggests implementing a new type of pricing mechanism using targets for each of the distinct resource dimensions mentioned previously, rather than a universal one. What this means, in simple terms, is that there will continue to only be a singular scalar gas price that users see in their wallet applications, but the internal gas accounting systems on an Arbitrum node would account for the different dimensional gas usages such that prices only go up when the target for a distinct resource target is breached.

Using the proposed model, each resource type would have a different usage target over some period of time. While transactions are being processed, the system tracks how much of each resource is used (computation, state growth, state access, history growth, and calldata) relative to its target per block. If usage exceeds the target, the excess is added to a “backlog”, which decays gradually over time. Each backlog value is then converted into a multiplier that adjusts the base fee for that resource. Among all resources, the highest multiplier becomes the effective gas price for the block, meaning the scarcest resource at that moment dictates overall pricing. When usage drops below target, the backlog shrinks, multipliers fall, and fees decrease accordingly. For example, a period full of compute transactions will maintain low pricing for longer while a period with lots of contract deployments (state growth) will dynamically raise in price. This mechanism allows the system to respond more efficiently and dynamically to real network load while stabilizing long-term pricing.

This design offers important benefits which are worth noting. It is able to stabilize fees by adjusting costs based on real-time demand, rather than have sharp spikes. It also distributes costs more fairly, with transactions paying based on the resources they use. In turn, bottlenecks are reduced and node operators are protected from hardware strains while developers are rewarded for writing more resource efficient contracts.

It’s worth noting that this type of constraint backlog based mechanism already exists on Arbitrum today. Currently, Arbitrum uses a base fee adjustment mechanism that places throughput constraints on the total gas usage. The system adjusts base fees based on a specific average gas usage per second, in a situation where gas usage is higher than 7 million gas-per-second over a 1 second window, the base fee will increase exponentially and discourage further high usage until the rate is normalized. For further reading on this topic, you can check the Arbitrum Nitro Whitepaper, section 3.3.1.

Future Flexibility 

Dynamic Pricing is the next step forward from the pricing mechanisms that exist on Arbitrum today. Constant iterations are necessary as this is nowhere near the end of the road. For example, following the implementation of Dynamic Pricing, if approved, future transaction types could allow advanced users to explicitly set per-dimension gas limits and optimize for resource specific behaviour. Wallet applications could show the exact gas dimensional components making up a user’s transaction fee, to help make users more informed about the sources of their fees. Smart contract developers could become more educated about the actual resource impacts of their contracts, and perhaps be incentivized to use more resource-efficient programming techniques in order to lower gas costs for their users.

In a recent talk by Davide Crapis, an Ethereum Foundation researcher, the long term vision for Ethereum’s fee market moves in a similar direction as proposed by Arbitrum. In this vision, there will be improved metering of blockchain resources and a more flexible and multidimensional price system that makes markets more transparent and efficient.

Dynamic Pricing doesn’t solve every problem that exists with gas pricing or fee markets today, and there is much more work still to be done. The goal is not to reach perfection in one large leap, but steady, sustainable practical progress that is built off a strong foundation.

Read more