Vitalik's new work: What is multi-dimensional Gas pricing?
Vitalik talks about the multi-dimensional Gas pricing of Ethereum, how should one balance and choose?
Author: Vitalik Buterin
Translation: Karen, Foresight News
In Ethereum, resources have been limited until recently and are priced using a single resource called "Gas." Gas is a unit of measurement for the "computational effort" required to process specific transactions or blocks. Gas combines various types of "computational effort," with the most important ones being:
1. Raw computation (e.g., ADD, MULTIPLY);
2. Reading and writing to Ethereum storage (e.g., SSTORE, SLOAD, ETH transfers);
3. Data bandwidth;
4. Cost of generating ZK-SNARK proofs for blocks.
For example, the transaction I sent consumed a total of 47,085 Gas. This includes: (i) a base cost of 21,000 Gas, (ii) calldata bytes included as part of the transaction consuming 1556 Gas, (iii) storage read/write consuming 16,500 Gas, (iv) logging consuming 2149 Gas, with the rest used for EVM execution. The transaction fee that users must pay is directly proportional to the Gas consumed by the transaction. A block can contain a maximum of 30 million Gas, and the Gas price is continuously adjusted through the EIP-1559 targeting mechanism to ensure an average of 15 million Gas per block.
This approach has a major advantage: because all content is merged into a virtual resource, market design is very simple. Optimizing transactions to minimize costs is easy, optimizing blocks to collect as high fees as possible is relatively easy (excluding MEV), and there are no strange incentive mechanisms encouraging some transactions to be bundled with others to save costs.
However, this approach also has inefficiencies: it treats different resources as interchangeable when the actual underlying constraints are different. To understand this issue, you can first look at the following chart:
Gas limits impose a constraint:
The actual underlying security constraints are usually closer to:
This difference causes Gas limits to either unjustly exclude blocks that are actually secure, accept blocks that are actually insecure, or both.
If there are n resources with different security constraints, one-dimensional Gas may reduce throughput by up to n times. Therefore, people have long been interested in the concept of multi-dimensional Gas, and through EIP-4844, we have actually implemented multi-dimensional Gas on Ethereum. This article explores the advantages of this approach and the prospects for further enhancements.
Blob: Multi-dimensional Gas in Dencun
At the beginning of this year, the average block size was 150 kB. A large part of this is Rollup data: Layer2 protocols store data on-chain. This data is very expensive: although the cost of transactions on Rollup is only 5-10 times that of corresponding transactions on Ethereum L1, this cost is still too high for many use cases.
So why not reduce the Gas cost of calldata (currently 16 Gas for non-zero bytes, 4 Gas for zero bytes) to make Rollup cheaper? We have done this before, and we can do it again now. But the answer here is: the maximum block size is 30,000,000/16=1,875,000 non-zero bytes, and the network can barely or almost not handle blocks of this size. Lowering the cost by 4 times would increase the maximum to 7.5 MB, which would pose a huge risk to security.
This problem is ultimately solved by introducing a separate, Rollup-friendly data space (called blob) in each block.
These two resources have different prices and limits: after the Dencun hard fork, an Ethereum block can contain (i) 30 million Gas and (ii) 6 blobs, each capable of holding about 125 kB of calldata. These two resources have separate prices and are adjusted through a pricing mechanism similar to EIP-1559, with the goal of averaging 15 million Gas and 3 blobs per block.
As a result, the cost of Rollup has been reduced by 100 times, the transaction volume on Rollup has increased by more than 3 times, and the theoretical maximum block size has only slightly increased: from about 1.9 MB to about 2.6 MB.
Note: Rollup transaction fees provided by Growthepie.xyz. The Dencun fork occurred on March 13, 2024, introducing multi-dimensional pricing for blobs.
Multi-dimensional Gas and Stateless Clients
In the near future, storage proofs for stateless clients will also face similar issues. Stateless clients are a new type of client that will be able to verify the chain without needing to store a large amount or any data locally. Stateless clients achieve this by accepting proofs of specific parts of the Ethereum state that transactions in that block need to access.
The diagram shows a stateless client receiving a block and proof of the current values of the state-specific parts touched by the block's execution (e.g., account balances, code, storage), enabling nodes to verify a block without any storage.
A storage read costs 2100-2600 Gas, depending on the type of read, with storage write costs being higher. On average, a block will perform about 1000 storage read/write operations (including ETH balance checks, SSTORE and SLOAD calls, contract code reads, and other operations). However, the theoretical maximum is 30,000,000/2,100=14,285 reads. The bandwidth load of stateless clients is proportional to this number.
The current plan is to support stateless clients by transitioning Ethereum's State tree design from Merkle Patricia trees to Verkle trees. However, Verkle trees do not have post-quantum security and are not the optimal choice for newer STARK proof systems. Therefore, many are interested in supporting stateless clients through binary Merkle trees and STARKs, either completely skipping Verkle or upgrading to STARKs after a few years of Verkle transition, once STARKs become more mature.
STARK proofs based on binary hash tree branches have many advantages, but their key weakness is the long time it takes to generate proofs: Verkle trees can prove over 100,000 values per second, while hash-based STARKs typically prove only a few thousand hashes per second, and proving each value requires many hash "branches."
Considering today's predictions from highly optimized proof systems like Binius and Plonky3, as well as dedicated hashes like Vision-Mark-32, it seems that proving 1000 values per second is feasible for a while, but proving 14,285 values is not. An average block would be fine, but potential worst-case blocks (released by attackers) would disrupt the network.
Our default approach to handling such situations is repricing: increasing the cost of storage reads to reduce the maximum per block to a more secure level. However, we have done this many times already, and if done again, it would make too many applications too expensive. A better approach is multi-dimensional Gas: limiting and charging for storage access separately, keeping the average usage at 1000 storage accesses per block, but setting an upper limit per block, for example, 2000 accesses.
Universality of Multi-dimensional Gas
Another resource worth considering is the growth of state size: operations that increase the Ethereum state size, which subsequently require full nodes to store. The uniqueness of state size growth is that its limitation comes entirely from long-term sustained usage, not peak usage.
Therefore, adding a separate Gas dimension for operations that increase state size (e.g., zero-to-nonzero SSTORE, contract creation) may be valuable, but with a different goal: we can set a floating price targeting a specific average usage, without setting any limits per block.
This demonstrates a powerful property of multi-dimensional Gas: it allows us to separately inquire for each resource: (i) what is the ideal average usage? (ii) what is the secure maximum usage per block? Unlike setting Gas prices based on the maximum per block and letting the average usage follow, we have 2n degrees of freedom to set 2n parameters, adjusting each parameter based on considerations for network security.
In more complex scenarios, such as when security considerations for two resources partially overlap, this can be handled by making an opcode or resource consume a certain amount of Gas of multiple types (e.g., consuming multiple types of Gas for a zero-to-nonzero operation).
ERO SSTORE may consume 5000 stateless client proof Gas and 20000 storage expansion Gas).
Max per transaction (selecting the one that consumes more data or computation)
Let 𝑥1 be the Gas cost of data, 𝑥2 be the Gas cost of computation, so in a one-dimensional Gas system, we can write the Gas cost of a transaction:
In this scheme, we define the Gas cost of a transaction as:
That is, transactions are charged not based on data plus computation, but based on which of the two resources it consumes more of. This can easily be extended to cover more dimensions (e.g. 𝑚𝑎𝑥(...,𝑥3∗𝑠𝑡𝑜𝑟𝑎𝑔𝑒_𝑎𝑐𝑐𝑒𝑠𝑠)).
It should be easy to see how this increases throughput while ensuring security. Theoretically, the maximum data volume in a block is still GasLIMIT/𝑥1, which is the same as in the one-dimensional Gas scheme. Similarly, the theoretical maximum computational volume is GasLIMIT/𝑥2, also the same as in the one-dimensional Gas scheme. However, the Gas cost of any transaction that consumes data and computation will decrease.
This is probably the approach adopted in the proposed EIP-7623 to reduce the maximum block size while further increasing blob count. The precise mechanism in EIP-7623 is slightly more complex: it keeps the current calldata price at 16 Gas per byte but adds a floor price of 48 Gas per byte; transactions pay the higher of (16 * bytes + execution_Gas) and (48 * bytes). Therefore, EIP-7623 reduces the theoretical maximum transaction call data in a block from about 1.9 MB to about 0.6 MB while keeping costs for most applications unchanged. The benefit of this approach is that it changes very little compared to the current one-dimensional Gas scheme, making it very easy to implement.
However, this approach has two drawbacks:
1. Even if all other transactions in the block use very little of that resource, transactions that heavily consume one resource will still unnecessarily incur high fees;
2. It incentivizes bundling data-intensive and computation-intensive transactions together to save costs.
I believe that rules like EIP-7623, whether for transaction calldata or other resources, can bring significant benefits, even with these drawbacks.
However, if we are willing to invest (significantly more) development effort, a more ideal approach will emerge.
Multi-dimensional EIP-1559: A More Challenging but Ideal Strategy
Let's first review how regular EIP-1559 works. We will focus on the version introduced in EIP-4844 targeting blobs as it is more mathematically elegant.
We track a parameter excess_blobs. During each block period, we set:
excess_blobs <-- max(excess_blobs + len(block.blobs) - TARGET, 0)
where TARGET = 3. This means if a block has more blobs than the target, excess_blobs increases, and if a block has fewer blobs than the target, excess_blobs decreases. Then we set blob_basefee = exp(excess_blobs / 25.47), where exp is the approximate value of the exponential function 𝑒𝑥𝑝(𝑥)=2.71828^𝑥.
This means that whenever excess_blobs increases by about 25, the base fee of blobs increases by about 2.7 times. If blobs become too expensive, average usage decreases, and excess_blobs starts to decrease, automatically lowering the price again. The price of blobs continuously adjusts to ensure that on average, blocks are half full, meaning each block contains an average of 3 blobs.
If there is a short-term peak in usage, there is a limit: each block can contain a maximum of 6 blobs, in which case transactions can compete by increasing the priority fee. However, in normal circumstances, each blob only needs to pay the blob_basefee plus a small additional priority fee to be included as an incentive.
This type of Gas pricing has been in Ethereum for many years: as early as 2020, EIP-1559 introduced a very similar mechanism. Through EIP-4844, we set two independent floating prices for Gas and Blobs.
Note: Gas base fees in gwei within one hour on May 8, 2024. Source: ultrasound.money
In principle, we can add more independently floating fees for storage reads and other types of operations, but I will detail an issue to be aware of in the next section.
For users, this experience is very similar to today: you no longer pay a base fee, but two base fees, which your wallet can abstract from you, showing only the expected fee and maximum fee you can expect to pay.
For block builders, the optimal strategy most of the time is the same as today: include any valid content. Most blocks are not full—whether in Gas or Blobs. A challenging situation arises when there is enough Gas or enough Blobs to exceed the block limit, and builders potentially need to solve a multi-dimensional knapsack problem to maximize their profits. However, even with fairly good approximation algorithms, the gains from optimizing profits through proprietary algorithms in this scenario are much smaller than those from using MEV for the same operations.
For developers, the main challenge is the need to redesign the EVM and its related infrastructure functions, which are currently designed based on a single price and limit and now need to be refactored to accommodate multiple prices and limits.
One issue application developers face is that optimization becomes slightly more difficult: in some cases, you can no longer explicitly say A is more efficient than B because if A uses more calldata and B uses more execution, A may be cheaper when calldata is cheap and more expensive when calldata is expensive.
However, developers can still achieve fairly good results by optimizing based on long-term historical average prices.
Multi-dimensional Pricing, EVM, and Sub-calls
One issue that does not arise in blobs, and would not arise in a full multi-dimensional pricing implementation targeting calldata like EIP-7623 or even for separately pricing state access or any other resource, is the Gas limits in sub-calls.
Gas limits in the EVM exist in two places. First, each transaction sets a Gas limit, restricting the total amount of Gas that can be used in that transaction. Second, when a contract calls another contract, that call can set its own Gas limit. This allows contracts to call other contracts they do not trust and still ensure they have remaining Gas to execute other computations after the call.
Note: Trace of an account abstracting a transaction, where one account calls another account and provides a limited amount of Gas to the callee to ensure that even if the callee consumes all the Gas allocated to it, the external call can continue to run.
The challenge is that achieving multi-dimensional Gas between different types of executions seems to require sub-calls to provide multiple limits for each type of Gas, which would require very deep changes to the EVM and be incompatible with existing applications.
This is one of the reasons why multi-dimensional Gas proposals typically stay at two dimensions: data and execution. Data (whether transaction calldata or blob) is allocated externally to the EVM, so no changes are needed internally to the EVM to price calldata or blob separately.
We can come up with an "EIP-7623-style solution" to address this issue. This is a simple implementation: charge 4 times the fee for storage operations during execution; to simplify analysis
Assuming each storage operation costs 10,000 gas. At the end of the transaction, a refund of min(7500 * storage_operations, execution_Gas) is given. Therefore, after deducting the refund, the user needs to pay the following fees: execution_Gas + 10,000 * storage_operations - min(7500 * storage_operations, execution_Gas) This equals: max(execution_Gas + 2,500 * storage_operations, 10,000 * storage_operations) This reflects the structure of EIP-7623. Another approach is to track storage_operations and execution_Gas in real-time and charge 2,500 or 10,000 based on how much max(execution_Gas + 2,500 * storage_operations, 10,000 * storage_operations) increases at the time the opcode is called. This avoids the need for transactions to over-allocate gas, which is mainly recovered through refunds. We do not have fine-grained permission for sub-calls: sub-calls may consume all of the transaction's allowance for cheap storage operations. However, we do have something quite good, which is that the contract making the sub-call can set a limit and ensure that once the sub-call is completed, the main call still has enough gas for the necessary post-processing. The simplest "complete multi-dimensional pricing solution" I can think of is: we treat the gas limit for sub-calls as proportional. That is, assuming there are 𝑘 different execution types, and each transaction sets multi-dimensional limits 𝐿1...𝐿𝑘. Assuming at the current execution point, the remaining gas is 𝑔1...𝑔𝑘. When calling the CALL opcode and using the sub-call gas limit 𝑆, let 𝑠1=𝑆, then 𝑠2=𝑠1/𝑔1*𝑔2, 𝑠3=𝑠1/𝑔1*𝑔3, and so on. In other words, we treat the gas for the first type (actually VM execution) as a special "account unit" and then allocate gas for other types so that sub-calls get the same percentage of available gas in each type. This method may seem a bit ugly but maximizes backward compatibility. If we want to make this solution more "neutral" between different types of gas without sacrificing backward compatibility, we can simply represent the sub-call gas limit parameter as a part of the remaining gas in the current context (e.g., [1...63]/64). However, in any case, it is worth emphasizing that once we start introducing multi-dimensional execution gas, inherent complexity will increase, which seems hard to avoid. Therefore, our task is to make a complex trade-off: do we accept some level of complexity (ugliness) increase at the EVM level to safely unlock significant L1 scalability gains, and if so, which specific proposal is most effective for protocol economics and application developers? It is very likely that neither of the two approaches I mentioned above is the best, but there is still room to propose more elegant and better solutions. Special thanks to Ansgar Dietrichs, Barnabe Monnot, and Davide Crapis for their feedback and review.Disclaimer: The content of this article solely reflects the author's opinion and does not represent the platform in any capacity. This article is not intended to serve as a reference for making investment decisions.
You may also like
10 signs you’ve been in the crypto industry too long
Meta reportedly cut metaverse budget by 20% as Q2 earnings call looms
Arkham：WBIT在134个钱包中持有8900枚BTC
ผู้โจมตีกระเป๋าเงิน Fantom โอน 300 ETH ไปยัง Tornado Cash
Trending news
MoreCrypto prices
More
