Split Pricing and Dual Track EIP1559 for Ethereum Storage-web3资讯-ODAILY

Split Pricing and Dual Track EIP1559 for Ethereum Storage

The biggest problem with the Ethereum state model is: the huge difference between average state growth and worst-case state growth.

This article is a latest discussion proposed by Vitalik in the Ethereum Researcher Forum, which is a recombination of the ideas on the practical implementation of EIP1559 proposed by the Ethereum research scientist Barnabé Monnot.

The following is the translation of the original text. The team has annotated some words and made some deletions.

Author: Vitalik Burerin

Compilation: Baiplan Team

Special thanks to @barnabe for suggesting a similar idea early on.

As I discussed in detail in my previous Position Paper on Resource Pricing, Gas in Ethereum actually pays for three different resources:

1. Bandwidth (transaction data that must be downloaded)

2. Calculation (time to verify and execute a transaction)

3. Storage (history, but more importantly state statements such as account balances, nonces, contract codes, contract storage)

Plan Bai commented: Position Document on Resource Pricing is a draft of blockchain resource pricing, in which Vitalik deduces the corresponding pricing method through mathematical calculations.

The draft includes: price and quantity, social cost curve, primary and secondary auctions, adjustable fee schedules, storage maintenance fees, and why are fixed fees underused?

Unlike bandwidth and compute, which are ephemeral costs, storage is not like these two costs, it will exceed the ephemeral limit.

There is a limit to how many calculations a node can perform or download data within the time of a block, and once the block is passed, the amount required for downloading and verification is reached. Most of the block is gone (only a few sync nodes need to process it in the future).

And storage is an ongoing cost. If a single block state increases by 100MB, that block can be processed right now, but a series of blocks will render Ethereum unusable. The burst impact of state growth is negligible, but the long-term impact is most severe, as once established a very large state permanently burdens the network.

secondary title

Average size vs worst case storage size

One of the shortcomings of modeling state in current (state) protocols (generally considered unsustainable) and improved protocols with state expiration is the large difference between average state growth and worst-case state growth.

Consider the current protocol. Today, the total size of the state is about 550 million objects, which is about 32GB (not including trie overhead). If we remove all not touched states from the previous year, the total can easily drop by more than half.

Now, whats the worst?

The creation of the contract code is charged at a fee of 200Gas per byte. Therefore, if a block is divided into 3 transactions and each transaction creates a contract, we can make 3 contracts of 20558 bytes for 12334800Gas+3*55000Gas, to increase the overhead of contract creation.

In this way, in a single block, the storage size can be increased by 20600*3=61800 bytes.

Assuming that the average block generation time is 13.1 seconds, there are 31556925/13.1=2408925 blocks per year. In general, the state can grow by 61800*2408925=148871600381.67938 bytes, which is about 138 GB.

This difference is about 10 times. (White Plan Note: The 16GB of data below is understood according to the context to be the current total state size of Ethereum in one year)

Very importantly, consumer hardware RAM can hold the actual size which could be 16GB (if not, we can adjust the gas price or state expiration to make it fit), and 138GB cannot be stored.

secondary title

Dual Track EIP-1559

A natural solution to this problem is to use EIP-1559 pricing for temporary and permanent costs, but with a different adjustment period.

For temporary costs, the price can be adjusted more than 10% at a time. However, for permanent costs, it will make price adjustments much slower.

If we take the AMM cost curve mechanism as a basis, for storage we can consider a curve with a target rate of 1GB per month, and the cost increases depending on how much we exceed the target:

For example, storage costs can double for every GB over target. In this case, it may take around 3 days for the storage block price to double. If the storage grows beyond 10GB, the storage cost will be 1000 times the normal price, making it economically impossible to continue storing.

There are two ways to achieve this:

1. Purchase storage with Gas. That is, using SSTORE to create a new storage slot consumes Gas as it does now, but the amount of Gas consumed will be variable. The downside of this is that it creates (disguised) incentives for users to refill storage on weekends when gas prices are lower.

2. Purchase storage with ETH. In addition to Gas, transactions (and calls) need to provide another resource (we can call it mana), which will use a similar mechanism to Gas, but with different parameters. This has the disadvantage of complicating the calling rules and requiring the addition of a new CALL opcode.

Note that there is a hybrid option here:

3. Storage can be priced in ETH, but charged in Gas (so if the base fee doubles, the Gas required to fill a storage slot will automatically be halved). We can exclude ETH used for scaling storage from EIP 1559 Gas price update rules or even block limits.

4. Transform Gas into three concepts more comprehensively: Gas, Execution Point, and Storage Point. 1Gas=1wei; A transaction that allocates Gas simply means that it is converting some of its wei into a special form that can be used to pay for resources. This form works the same as Gas in terms of how it is passed between the call and the subcall.

However, AMM now manages two costs: execution point cost and storage point cost. When an execution process processes an opcode that currently consumes N gas, it will spend N execution points, which means N* execution_point_cost is required to pay Gas. Filling a storage slot requires 1 storage point, so storage_point_cost is required to charge Gas.

Finally, also note that refunds are expected to be removed from the state deadline roadmap. This is because of a technical reason: storage slots cannot become empty and qualify for a refund, so they can only be set to zero, and zero records must remain in that state until the period ends and the state can expire. This greatly reduces the complexity issues encountered in earlier attempts at storage rent.