In the Ethereum ecosystem, the gas fee is a long-term predominant factor that dictates the number of computational resources required to process any transaction. Or in simple terms, the fee you pay to the blockchain for executing the transaction. This gas fee term under its umbrella encompasses many dimensions of transaction processing, including storage operation, computational operations, raw data operations, and proof generation. Up until now resources in Ethereum are only limited and priced in terms of gas fees (wei). With EIP 4844 Ethereum has committed to provide better scalability, improve resource allocation, and enhance overall performance. However, this system relies on a single dimension: computational cost. This means that transactions with similar computational tasks incur the same gas fees, irrespective of their impact on other network resources like storage or bandwidth. This one-size-fits-all approach introduces inefficiencies when the usage of the network grows.

Background and Limitations 

Multidimensional Gas Pricing is a new concept that has been introduced by Vitalik Buterin. This concept addresses many of the core issues related to pricing. Incorporating this method means, we price various network resources separately which could boost the transaction execution significantly and will lay a strong groundwork for the Ethereum rollup centric roadmap. 

Before getting deep into the concepts of multidimensional pricing we first need to understand how gas fees affect the network. In principle, the gas fee directly influences the cost and network throughput. Each transaction incurs a fee proportional to the amount of gas consumed. Earlier just to get simple transaction processes in a block users had to pay an average of 100$ fee. However, with EIP 1559 we have already got rid of the first auction mechanism and with its employment, a total of 30 million gas could be added per block. The EIP adjusts gas prices dynamically,  aiming for an optimal average gas usage of 15 million per block. While EIP 1559 has simplified the market dynamics, treating different resources convertible to one unit can lead to inefficiencies. For example in this transaction provided by Vitalik Buterin, a total of 47,085 gas has been consumed. This gas cost could be divided into different aspects of resource allocation.

1. The 21000 gas base cost of the block(according to EIP 1559).
2. 16500 gas for reading and writing to storage.
3. 1556 gas for CALLDATA.
4. 2149 gas for logs.

There are two main concerns.

i) How much data can be handled by the network in the block?
ii) How many computations can be safely performed within the block?

With EIP 1559 we have only one check where we verify if the  (gas cost for computations)* (gas cost for data) < block limit.

Therefore, until and unless our gas cost does not exceed per block, the block is considered to be safe for processing. However, there is a possibility in the network where the data bandwidth is slower for some reason and hence more computationally intensive transactions will be included in the block to get an average of 15 million gas and hence the network will be burdened with regards to computational resources.  

With this approach, we are limited to distinguishing between the various resource demands.  For instance, resources like storage might be underutilized if the price doesn’t accurately reflect their true cost. Similarly, bandwidth congestion may occur if data-heavy transactions are underpriced compared to their network impact.

A Step Towards Multidimensional Gas Model

With the surge in rollups on Ethereum, a large size of the transaction block is being occupied with rollup data. The layer2 data has been stored on Ethereum for the purpose of security and handling disputes. This data is expensive. We can’t simply reduce the CALLDATA cost due to network performance because by decreasing the price the size of the data will increase.

This was the reason why Ethereum came up with EIP 4844 and introduced a separate space for data blobs to increase network efficiency. 

In EIP- 4844 both the computations and data limit are separated. As a result, rollups have become 100x cheaper, transaction volume on rollups increased by more than 3x, and the theoretical maximum block size was only increased slightly: from ~1.9 MB to ~2.6 MB.

Now, if we look carefully we definitely have found a solution for our two different resources, Data and Computations but in the near future when we will have stateless clients with Verkle proofs, we then will again have to figure out a solution to separate it. Stateless clients are a new type of client that will be able to verify the chain without storing much or any data locally. Stateless clients do this by accepting proofs of the specific pieces of Ethereum that have been used or altered by that transaction. 

The bandwidth of stateless clients is of the utmost concern over here. On average 1000 storage reads and writes are performed within the block and the stateless client load is directly proportional to this number. With Zk proofs, this number could not be handled in a block and these proofs take time to generate. The default and simplistic way is to increase the pricing for storage read and write to decrease the load on stateless clients per block but this too will cost us the scalability. Therefore, the concept of multidimensional gas pricing has been introduced. 

Concept of Multidimensional gas

Rather than setting prices per resource, we need to think about what is the safe per-block maximum usage, for each resource and then we can set the average to follow this price. Earlier we were defining our block resources limit with these two resources:

single-dimensional gas scheme

(gas cost for computations)* (gas cost for data) < block limit

Multi-dimensional gas scheme

That is, instead of a transaction being charged for data + computation, the transaction gets charged based on which of the two resources it consumes more of.  

(gas cost for resource1)*(gas cost for resource2)<block limit

x1*x2< block limit

Theoretically, we can also verify if it’s under a safe limit by doing GasLimit/x1.

The benefit of this approach is that it is a very small change from the current single-dimensional gas scheme, and so it is very easy to implement. However, this scheme has two major flaws.

1. Transactions that are heavy on one resource are still needlessly charged a large amount, even if all the other transactions in the block use little of that resource.
2. It creates incentives for data-heavy and computation-heavy transactions to merge together into a bundle to save costs.

Another major problem with multidimensional gas pricing is the subcalls. Gas limit is important in two places. One where each transaction sets its gas limit, in a way that it does not exceed the block limit. Second, when a contract calls another contract, the call can set its own gas limit. This allows contracts to call other contracts that they do not trust, and still guarantee that they will have gas left over to perform other computations after that call. 

The main challenge here is that making gas multidimensional between different types of execution will require sub-calls to provide multiple limits for each type of gas, which would require a really deep change to the EVM and would not be compatible with existing applications.

Conclusion

For users after implementing the multidimensional gas pricing, the experience will be almost similar except for the fact that instead of paying one base gas fee, they will pay two base fees. For block builders, they would need to put extra effort into solving the pricing relation in a way that they get the maximum fee. However, the main challenge lies for developers because this requires the redesign of EVM.