Status Update #4 for EIP 1559

Author | Tim Beiko

Author | Tim Beiko

➤ We now have a detailed economic analysis of EIP-1559

➤ We are building a testnet with mainnet-level capacity to analyze the performance of 1559 on a large network

➤ Progress has been made to address transaction pool issues caused by changing BASE FEE

➤ We have new simulations to analyze the behavior of legacy transactions as well as 1559-style transactions on a single network

➤ OpenEthereum is hiring a full-time engineer focused on 1559

In December 2020, Tim Roughgarden, a leading game theory and computer science researcher, published a 50+ page economic analysis of EIP-1559. He wrote the gist of the report in a tweet and in the first part of the report, but it's worth sharing it here in full:

Annotation: The translation of the above ten points can be viewed"Ether Seven Day Talk • 2020/12/7"。

In the past, critics of 1559 have often mentioned that it lacks a formal economic analysis, arguing that 1559 relies on intuition about the Ethereum transaction fee market. This report provides an exhaustive and generally positive analysis of EIP-1559. It even seems to have convinced some famous 1559 skeptics like Nick Johnson 🎉!

This report highlights some aspects of 1559 that deserve further consideration, namely those situations where miners may have colluded[0], and a better analysis of the base fee update rules. The 7th EIP-1559 implementers meeting discussed the miner collusion scenario, but no definite conclusions were drawn. As for the basic fee update rules, I launched a Twitter call for experts in this field, and some people have reached out to me, hoping to help💪.

Roughgarden also mentioned that he hopes the Ethereum community will get the most out of the report and that anyone can contact him if they have questions, comments, or concerns. His website lists his various contact details.

As discussed in the previous update, the next milestone of testing EIP-1559 will be testing under conditions similar to mainnet. The first method considered is to actually fork a network from the mainnet, lower the difficulty and start EIP-1559 on it. Although this would give us a copy of the mainnet state, the idea was rejected due to security concerns [1].

Instead, the Besu team has been building a large state testnet generator. The generator takes a large number of accounts and storage slots as input, and starts a program called"whale"A smart contract that sends a small amount of ETH and creates a storage slot[2] for each input. There is a full demo at the 7th EIP-1559 Implementers Meeting, starting at 1:16:00. Here's a screenshot of the tool in action.

Now that we have this database, we will try to sync all client implementations to this network, and then transaction bomb the network with the transaction generation tool we built earlier. This way, we can gain insight into how clients can handle 200% full blocks smoothly under the 1559 rule when they have to manage the state of mainnet-level capacity.

In the previous update, we discussed some important issues related to transaction pool management, which still need to be resolved. I explained them in a document, but the gist of it is that because the BASE FEE between blocks is different, and the transaction will specify the maximum fee (FEE CAP) and miner tip (TIP) they are willing to pay, a miner packs The fee received by the transaction will change with the change of BASE FEE, which means that nodes are potentially required to reorganize the transaction pool of each block, which is very inefficient.

Ansgar from the Quilt team has been paying attention to this issue, and he shared an article on this issue at the 7th implementers meeting.

In short, there are two problems that need to be solved: miners want the transactions included in the block to pay them the highest fee; non-mining nodes need to have a transaction eviction policy when their transaction pool is full.

Although the document does not propose a solution to this problem, it highlights an interesting feature of transactions for miners - changing rewards. Under 1559, you can imagine a transaction having two possible "states". The first state is "constant", that is, the FEE CAP of the transaction is greater than the sum of BASE FEE and TIP, and miners will get the entire TIP. The second state is "changing", that is, FEE CAP is still higher than BASE FEE, but lower than the sum of BASE FEE and TIP [4]. In this case, miners get the difference between FEE CAP and BASE FEE.

When transactions are not in these two states, you can create a relative order between them (by TIP for states of class "constant" and for states of class "varying" by their "effective tip", e.g.: FEE CAP - BASE FEE)

The insight of the Ansgar article is that transactions of the "change" class of state will preserve the same inter-block relative order, since an increase/decrease in BASE FEE will have the same effect on them. This means that the core of the problem is to find an effective way to determine which transactions change from "constant" to "variable" when BASE FEE changes, and how to properly handle these transactions.

Hopefully we will have answers to these questions in the next Quilt post 😁!

The Nethermind team has published a new notebook on simulations that explore the interplay between legacy transactions and 1559-style transactions in the network, and that legacy transactions can be interpreted as 1559-style transactions. These studies build on previous simulations by Barnabé Monnot and his team.

This simulation introduces three types of users: naive 1559 users who always shoot their TIP to the lowest value; smart 1559 users who strategically set their TIP based on network usage; smart legacy transactions users, who strategically set their gas price based on network usage.

For each type of user, a fixed number of transactions are sent to the network. That report analyzed what types of transactions were included, how much those users paid, and how long users ended up waiting.

The "Summary" section of the report is short and well worth reading in full, but I'll give the summary anyway:

➤ We see two clear "phases" in the simulation: when BASE FEE converges to its equilibrium value, and when it is stable

➤ In the unstable stage of BASE FEE, smart 1559 users will initiate most of the packaged transactions

➤ The behavior of the transaction pool changes depending on which "stage" we are in. When the base fee is unstable, there are many evicted transactions and the transaction pool needs to be rearranged; but when it is stable, the transaction pool has very few evicted transactions.

When discussing mocking at implementers' meetings, two interesting issues arise.

First, BASE FEE risks becoming less stable if more legacy transactions appear on the network, and 1559-style transactions tend to be packaged preferentially when those phases create incentives to adopt 1559-style transactions.

Second, as the use of 1559-style transactions grows and BASE FEE becomes stable, estimated gas prices for legacy transactions will become more accurate because they can use the value of BASE FEE in their estimates. In other words, 1559 users will help reduce the volatility of gas prices in the network, narrowing the confidence intervals of gas price estimator estimates.

A lot of updates have been written above, and one last point worth mentioning is that OpenEthereum is hiring a full-time developer to work on EIP-1559.

This update is very late! Here's what we're going to do next:

➤ Share the latest research and development results to the community, including AllCoreDevs, to collect feedback;

➤ Find experts to provide better analysis for base fee update rules

➤ Synchronize all clients to a large state testnet and use the transaction generator tool to test performance on the network

➤ Propose a good algorithm that can classify the transaction pool of miners and non-miners

Thanks for reading 😁

[0] Although this is unlikely under 1559, such studies are still helpful.

[1] Forking the main network and disclosing the main network variables on the client can easily lead to repeated attacks and frauds

[2] In the background, it is sending ETH to 0x0...1, 0x0..2, 0x0..3, etc., and making storage entries for 0x0..1, 0x0..2, 0x0..3, etc., Until the desired number of accounts and storage slots are reached.

[3] This document has the following disclaimer: This document is intended primarily as the basis for discussion at the upcoming implementers meeting. A more detailed article will follow later. Because the Quilt team has only recently joined the EIP-1559 effort, it is possible that we have made wrong assumptions or overlooked existing related work.

Official Account: ETH Chinese Station

Click "Read the original text" to get the internal link of the article!

Original link:https://hackmd.io/@timbeiko/1559-updates/https%3A%2F%2Fhackmd.io%2F%40timbeiko%2F1559-update-004

ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author, and the source of the original text and the ETH Chinese website must be indicated when reprinting. For long-term reprinting, please contact eth@ecn.co for authorization.

Official Account: ETH Chinese Station

Website: ethereum.cn