One of the shortcomings of the Ethereum state model is the huge difference between average state growth and worst-case state growth. Using EIP-1559 to separate the temporary and permanent costs of the network is a solution.
Written by: Vitalik Buterin, co-founder of Ethereum Compiler: Project White Team
This article is a latest discussion put forward by Vitalik in the Ethereum Researcher Forum. The discussion is a recombination of the ideas on the practical implementation of EIP1559 proposed by the Ethereum research scientist Barnabé Monnot.
The following is the original translation, and the team has annotated some vocabulary and some deletions.
As I discussed in detail in the previous “Position Paper on Resource Pricing”, Gas in Ethereum actually pays for three different resources:
- Bandwidth (transaction data that must be downloaded)
- Calculation (time to verify and execute transaction)
- Storage (historical records, but more importantly state statements, such as account balances, random numbers, about codes, contract storage)
Plan Bai’s comment: The “Position Paper on Resource Pricing” is a draft of blockchain resource pricing, in which Vitalik inferred the corresponding pricing method through mathematical calculations.
The draft content includes: price and quantity, social cost curve, first and second auctions, adjustable fee schedule, storage maintenance fee, and why the fixed fee is not fully utilized?
Bandwidth and computing are short-lived costs. Unlike these two costs, storage will exceed the short-term limit.
In a block of time, there is a limit to how many calculations or downloads a node can perform. Once the block passes, the amount of download and verification required reaches the limit. Most of the blocks are gone (only a few sync nodes will need to process them in the future).
And storage is an ongoing cost. If the state of a single block increases by 100MB, the block can be processed at the moment, but a series of blocks will make Ethereum unusable. The “burst” impact of state growth can be ignored, but the long-term impact is the most serious. Once a large state is established, it will always add a burden to the network.
However, as the state becomes stateless (the White Plan Note: the stateless Ethereum solution), the long-term impact of the (super-large) state will be greatly reduced: the state will not impose a permanent burden on the network, it will only bear about one year Time, in that year, only a small part of the nodes needed to actually store that (super large) state. But this long-term (one-year) cost is still real and needs to be priced.
Average size and worst-case storage size
In the current (state) agreement (generally considered unsustainable) and the state-expired improvement agreement, one of the shortcomings of state modeling is the huge difference between average state growth and worst-case state growth.
Consider the current agreement. Today, the total size of this state is about 550 million objects, about 32GB (not including trie overhead). If we exclude all not touched statuses in the previous year, the total amount can easily drop by more than half.
Now, what is the worst case scenario?
The creation of the contract code is charged at a cost of 200Gas per byte. Therefore, if a block is divided into 3 transactions and each transaction creates a contract, we can create 3 contracts of 20558 bytes for 12334800Gas+3*55000Gas. To increase the cost 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 every year. In general, the status can be increased by 61800*2408925=148871600381.67938 bytes, which is about 138 GB.
This difference is about 10 times. (Note for the White Plan: The 16GB of data below is understood to be the total size of the current state of Ethereum for one year according to the context)
It is very important that the actual size of consumer hardware RAM may be 16GB (if not, we can adjust the Gas price or the status expiration date to make it fit), while 138GB cannot be stored.
It would be great if we can make the worst case close to the average case.
Double track EIP-1559
The natural way to solve this problem is to use EIP-1559 pricing for temporary and permanent costs, but the adjustment period is different.
For temporary costs, the price can be adjusted by more than 10% at a time. However, for permanent costs, it will make price adjustments much slower.
If we use the AMM cost curve mechanism as the basis, for storage, we can consider a curve, the target rate is 1GB per month, and the increase in cost depends on how much we are above the target:
For example, every time the target 1GB is exceeded, storage costs may double. In this case, it may take about 3 days for the storage block price to double. If the storage growth exceeds 10GB, the storage cost will be 1,000 times the normal price, and it will be economically impossible to continue storage.
There are two ways to achieve this:
1. Use Gas to buy storage. In other words, using SSTORE to create a new storage slot consumes Gas as it does now, but the amount of Gas consumed will be variable. The disadvantage of this is that it will create (disguised) incentives, and users would rather replenish storage space on weekends when Gas prices are lower.
2. Use ETH to purchase storage. In addition to gas, transactions (and calls) also need to provide another resource (we can call it mana). This resource will use a mechanism similar to Gas but with different parameters. The disadvantage of this is that it complicates the calling rules and needs to add a new CALL opcode.
Note that there is a mixed option here:
3. Storage can be priced in ETH, but charged in Gas (so if the basic fee increases by 2 times, the gas required to fill the storage slot will automatically be halved). We can exclude the ETH used for expansion storage from the EIP 1559 Gas price update rule or even the block limit.
4. More comprehensive transformation of Gas into three concepts: Gas, execution point and storage point. 1Gas=1wei; The 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. As far as the transfer method between call and subcall is concerned, this form works the same as Gas.
However, AMM now manages two costs: execution point cost and storage point cost. When the execution process processes an opcode that currently consumes N Gas, it will cost N execution points, which means that N* execution_point_cost is required to pay for Gas. Filling the storage slot requires 1 storage point, so storage_point_cost is required to charge the gas.
Finally, it should be noted that refunds are expected to be deleted from the roadmap with deadlines. This is because of technical reasons: storage slots cannot be “empty” and are eligible for a refund, so they can only be set to zero, and zero records must remain in this state until the end of the period and the state can expire. This greatly reduces the complexity problems encountered in early storage rent attempts.
Special thanks to @barnabe for suggesting similar ideas in the early days.
Source link: mp.weixin.qq.com
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views, and have nothing to do with the position of ChainNews. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.
