V Gods new article: Multi-dimensional Gas Pricing to Improve Ethereum Scalability

avatar
Asher
1 weeks ago
This article is approximately 1660 words,and reading the entire article takes about 3 minutes
A deep dive into the complexity and potential of multi-dimensional gas pricing on the Ethereum network.

Original article: Multidimensional gas pricing

Compiled by: Odaily Planet Daily Asher

V Gods new article: Multi-dimensional Gas Pricing to Improve Ethereum Scalability

In the Ethereum network, resources are limited and priced through a single resource called Gas. Gas is a measure of the computational effort required to process a particular transaction or block. Gas combines multiple types of effort, the most important of which are:

  • Primitive calculations (such as ADD, MULTIPLY )

  • Read and write Ethereum storage (such as SSTORE, SLOAD, ETH transfers)

  • Data bandwidth

  • Cost of generating a block ZK-SNARK proof

For example, this transaction cost a total of 47085 Gas. This includes: (i) 21000 Gas for the base fee; (ii) 1556 Gas for the calldata bytes that are part of the transaction; (iii) 16500 Gas for reading and writing storage; (iv) 2149 Gas for log generation; and the rest for EVM execution. The transaction fee that a user must pay is proportional to the Gas consumed by the transaction. A block can contain up to 30 million Gas, and the Gas price is constantly adjusted through the EIP-1559 target mechanism to ensure that the block contains an average of 15 million Gas.

V Gods new article: Multi-dimensional Gas Pricing to Improve Ethereum Scalability

Demo Case

This approach has one major advantage: since all transactions are combined into a single virtual resource, market design is very simple. It is easy to optimize transactions to minimize costs, it is relatively easy to optimize blocks to charge the highest possible fees (excluding MEV ), and there are no weird incentives to encourage certain transactions to be bundled with others to save fees.

But this approach also suffers from a major inefficiency: it treats different resources as convertible into each other, when the actual fundamental limitations of what the network can handle are not true. One way to understand this problem is to look at the following diagram:

V Gods new article: Multi-dimensional Gas Pricing to Improve Ethereum Scalability

If there are clear safety limits on the 𝑛 resource, then one-dimensional Gas could reduce throughput by up to 𝑛 times. As a result, there has been a long-standing interest in the concept of multi-dimensional Gas, and through EIP-4844, we can actually use multi-dimensional Gas on Ethereum today. This post explores the benefits of this approach, and the prospects for further improvement.

Blobs: Cancuns upgraded multi-dimensional Gas

At the beginning of this year, the average block size was 150 kB . A large part of this is convolutional data: the L2 protocol that stores data on-chain for security reasons. This data is expensive: although transactions on convolution are 5-10 times cheaper than corresponding transactions on Ethereum L1, even this cost is too high for many use cases.

This problem was ultimately solved by introducing a separate convolution-friendly data space (called Blobs) in each block.

After the Cancun upgrade, an Ethereum block can contain up to (i) 30 million Gas and (ii) 6 Blobs, each of which can contain about 125 kB of calldata. Both resources have independent prices, adjusted by independent pricing mechanisms similar to EIP-1559 , with the goal of using an average of 15 million Gas and 3 Blobs per block.

As a result, the cost of convolution has been reduced by a factor of 100, the number of transactions that can be convolutionally increased by more than 3 times, while the theoretical maximum block size has only increased slightly: from 1.9 MB to 2.6 MB.

V Gods new article: Multi-dimensional Gas Pricing to Improve Ethereum Scalability

Rolling transaction fees, provided by growthepie.xyz . The Dencun fork occurred on March 13, 2024, introducing multi-dimensionally priced Blobs

Multi-dimensional Gas and Stateless Clients

In the future, stateless clients will face the problem of storing proofs. A stateless client is a new type of client that is able to verify the blockchain while storing little or no data locally. It accepts proofs to verify the state of Ethereum for a specific part of a block without storing any data itself.

On average, a block performs about 1,000 storage read and write operations, but the theoretical maximum could be tens of millions. The current plan is to support stateless clients by migrating Ethereums state tree design from a Merkle Patricia tree to a Verkle tree. However, the Verkle tree is not quantum-resistant and is not suitable for the newer STARK proof system.

Therefore, many people hope to support stateless clients through binary Merkle trees and STARKs, which can completely skip Verkle, or upgrade a few years after the Verkle migration. Although the STARK proof of binary hash tree branches has many advantages, the speed of generating proofs is slow and cannot meet the high-speed requirements.

It is expected that there will be a period of time in the future when it will be possible to prove 1000 values in less than a second, but it will not be possible to prove 14,285 values. To solve this problem, the concept of multi-dimensional Gas was proposed. This method can limit and charge storage access separately, ensuring an average storage access of 1000 times per block, while setting a limit of 2000 times per block to improve the security and efficiency of the network.

Wider applications of multi-dimensional Gas

State size growth is another resource to consider. When increasing the size of the Ethereum state, full nodes need to hold more data. Unlike other resources, the growth limit of state size is mainly derived from long-term sustained usage rather than short-term peaks. Therefore, in order to handle operations with state size growth, one can consider adding a separate gas dimension. The goal of this approach is to set a floating price that targets a specific average usage, rather than setting a limit per block.

This demonstrates the power of multi-dimensional Gas, which allows different questions to be asked for each resource: (i) what is the ideal average usage of each resource; (ii) what is the safe maximum usage of each resource per block. By setting these parameters, the price of Gas can be adjusted based on the security of the network, rather than based on the maximum usage per block. When dealing with more complex situations, multiple Gas can be used. For example, a zero to non-zero SSTORE operation may require the consumption of different types of Gas, such as stateless client proof Gas and storage expansion Gas.

Maximum value per transaction: Get multi-dimensional Gas A weaker but simpler strategy

In a one-dimensional gas system, the gas cost of a transaction is determined based on the gas consumed by both data and computation. However, in a multi-dimensional gas system, the gas cost can be determined based on the main resources consumed by the transaction. This approach improves throughput while maintaining security.

EIP-7623 proposed a similar solution, which reduced the space occupied by transactions in the block by increasing the minimum price per byte, but this also led to some problems, such as individual resource-intensive transactions still having to pay high fees, and also created an incentive for data-intensive and computationally intensive transactions to be bundled together to save costs. Although this approach has its limitations, the benefits are worth it, but if you are willing to invest more development work, there are more ideal solutions.

Multidimensional EIP-1559: A harder but more ideal strategy

At its core, Multidimensional EIP-1559 adjusts the base fee for blobs by tracking the excess_blobs parameter to ensure that the average usage of blocks remains at a target level.

When the number of blobs in a block exceeds the target value, the base fee will increase to reduce usage; otherwise, it will decrease. This pricing mechanism allows the transaction price within the block to be dynamically adjusted to keep the block half-filled. At the same time, a short-term surge in usage will also trigger the restriction mechanism, ensuring reasonable competition for transactions.

In Ethereum, this pricing method for Gas has existed for many years: EIP-1559 introduced a very similar mechanism as early as 2020. With the introduction of EIP-4844, there are now two floating prices for Gas and Blobs respectively.

For users and block builders, the experience is similar to before, but they will need to adjust to two separate fees. However, for developers, the need to redesign EVM functionality to accommodate multiple prices and multiple restrictions may add some challenges.

Multi-dimensional pricing, EVM, and subcalls

In the EVM, there are two kinds of Gas limits: a total Gas limit set for each transaction, and individual Gas limits when contracts call other contracts. This allows contracts to call untrusted contracts while ensuring that there is still remaining Gas for other calculations after the call. However, there are challenges in implementing multi-dimensional Gas pricing between different types of execution. This multi-dimensional scheme requires sub-calls to provide multiple limits for each Gas type, which will make profound changes to the EVM and is incompatible with existing applications.

Multi-dimensional Gas proposals usually stay at just two dimensions: data and execution. Data is allocated outside the EVM, so no internal changes are required to price it separately. For developers, this means that the EVM and its surrounding infrastructure need to be redesigned to accommodate multiple prices and multiple limits. In some cases, optimization will also become more difficult because it is not clear which approach is more efficient, which may affect the development process.

While there are some challenges, these issues can be addressed by implementing something like EIP-7623, which charges an additional fee for storage operations and refunds them at the end of the transaction to ensure that the main call still has enough gas to perform subsequent operations.

summary

In either case, it is worth emphasizing that once you start introducing multi-dimensional execution Gas, the complexity of the system will increase significantly, which seems to be inevitable.

We are therefore faced with a complex decision: are we willing to accept more complexity at the EVM level in exchange for unlocking significant gains in L1 scalability, and if so, which specific proposal is best for protocol economics and application developers? It is likely that the best solution is neither of the ones mentioned previously nor the ones mentioned above, and there is still room for more elegant and effective solutions.

This article is translated from https://vitalik.eth.limo/general/2024/05/09/multidim.htmlOriginal linkIf reprinted, please indicate the source.

ODAILY reminds readers to establish correct monetary and investment concepts, rationally view blockchain, and effectively improve risk awareness; We can actively report and report any illegal or criminal clues discovered to relevant departments.

Recommended Reading
Editor’s Picks