---
tags: 1559
---

# The State of 1559 - Update 004 🔥

## TL;DR 👀

* We now have an extensive economic analysis of EIP-1559;
* We are building mainnet-sized testnets to analyze 1559's performance on large networks;
* We've made progress on addressing the transaction pool issues caused by the changing `BASE FEE`;
* We have new simulations that analyze the behavior of legacy and 1559-style transactions on a single network;
* OpenEthereum is hiring a full time engineer to work on 1559!

## Economic Analysis 📑

This week, [Tim Roughgarden](http://timroughgarden.org/), a leading game theory and computer science researcher, published a [50+ page economic analysis of EIP-1559](http://timroughgarden.org/papers/eip1559.pdf). He summarized the key takeaways both on [Twitter](https://twitter.com/algo_class/status/1333828688916439041) and in the first section of the report, but it is worth re-sharing them here in full:


The lack of a formal economic analysis was brought up frequently in the past by critics of 1559, saying it relied on little more than intuitions about the transaction fee market on Ethereum. This report provides an exhaustive, and generally positive, analysis of EIP-1559. It even seems to have convinced some of 1559's more notable skeptics, such as [Nick Johnson](https://twitter.com/nicksdjohnson/status/1334277446833618945) 🎉!

The report did highlight a few areas of 1559 that merit further considerations, namely thinking through potential collusion scenarios for miners [0] and a better analysis of the base fee update rule. Miner collusion scenarios were discussed on the [last implementers' call](https://github.com/ethereum/pm/issues/226), without any strong conclusion. On the update rule front, [I've made a call for experts on Twitter](https://twitter.com/TimBeiko/status/1334288252912582656), and a few people have already reached out to potentially help :muscle:

Roughgarden also mentioned that he wants this report to be maximally useful to the Ethereum community, and if anyone has questions, comments or concerns, they should reach out to him. [His website](http://timroughgarden.org/) lists the various ways to do so.

## Large State Testnets 📈

As discussed in the previous update, the next milestone in testing EIP-1559 is to test it in conditions similar to mainnet. The first approach considered was to literally create a fork of mainnet, lower the difficulty and activate EIP-1559 on it. While this would have given us an exact copy of mainnet's state, the idea was discarded due to security considerations [1].

Instead, the Besu team has been working on a ["large state tesnet generator"](https://github.com/abdelhamidbakhta/tommygun-eth). The generator takes a number of accounts and storage slots as input, starts a new network with one "whale" smart contract, and has it send a small amount of ETH and create a storage slot for each input [2]. A full demo was shared in the last implementers' call, starting at [1:16:00](https://youtu.be/dopljpI59Rw?t=4560). Here is a screenshot of the tool in action:


Mainnet currently has ~100M accounts, so our last run of the tool created a network with 100M accounts and storage slots. The process took about 4 days, and resulted in a database size of ~240GB. The time to create networks grows almost exponentially with the size of the network, with a 100k-sized network taking 2x as long as a 10k one, a 1M-sized network taking ~10x as long as a 100k one, a 10M-sized network ~15x longer than a 1M one and 100M-sized network taking ~40x (!!) longer than a 10M one!

Now that we have this dataset, we will try and get all client implementations synced on this network, and then spam the network with transactions using the [transaction generator tool](https://github.com/ConsenSys/eip1559-tx-sender) we had previously built. Doing this will give us insight into how smoothly clients can process "200% full" blocks under 1559 rules when having to manage a mainnet-sized state.

## Transaction Pool 🏊‍♂️

In the previous update, we discussed some outstanding issues related to transaction pool management that still had to be figured out. I explained them [in a document](https://hackmd.io/unbJUt-HQgStvwmpLPsXsQ), but the gist of it that because the `BASE FEE` can vary from block to block, and that transactions specify the maximum fee (`FEE CAP`) and miner tip (`TIP`) they are willing to pay, the amount that a miner receives for including a transaction can vary as the `BASE FEE` changes, potentially requiring nodes to re-sort the transaction pool each block, which is terribly inefficient.

[Ansgar](https://twitter.com/adietrichs) from the Quilt team has been looking into this. He shared [a write up about the problem](https://hackmd.io/@adietrichs/1559-transaction-sorting) during the last implementers' call.

In short, there are two cases to solve: miners, which want to include transactions that pay them the most in blocks, and non-mining nodes, who need a policy for which transaction to evict when their transaction pool is full.

While the document doesn't propose a solution for the problem [3], it highlights an interesting property of the "changing profitability" of transactions for miners. You can think of transactions under 1559 as having two possible "states". The first state is "constant", meaning that the transaction's `FEE CAP` is greater than sum of `BASE FEE` and `TIP`, and the miner will get the entire `TIP`. The second state is "changing", where the `FEE CAP` is still higher than the `BASE FEE`, but lower than the sum of `BASE FEE` and `TIP` [4]. In that case, the miner will get the difference between `FEE CAP` and `BASE FEE`.

When transactions are in either of these states, you can create a relative ordering between them (sort the "constant" ones by their `TIP`, and sort the "changing" ones by their "effective tip", i.e. `FEE CAP` - `BASE FEE`).

The insight from Ansgar's writeup is that transactions in the "changing" state will preserve the same relative order between blocks given that the `BASE FEE` increase/decrease will have the same effect on all of them. This means that the core of the problem is finding an efficient way to determine which transactions go from "constant" to "changing" when the `BASE FEE` changes, and how to deal with those appropriately.

Hopefully, we'll get an answer to that question in Quilt's next writeup 😁!

## Simulations Update 🤖

The Nethermind team released [a new simulations notebook](https://github.com/NethermindEth/research/blob/main/legacyTransactions.ipynb) exploring the interplay between legacy and 1559-style transactions on a network where legacy transactions are interpreted as 1559-style ones. The work builds on [the previous simulations](https://github.com/barnabemonnot/abm1559#abm1559) by Barnabé Monnot and his team.

Three types of users are introduced in the simulation: naive 1559 users, who always set their `TIP` to the minimum value, clever 1559 users, who set their `TIP` strategically based on network usage, and clever legacy users, who set their `gas price` strategically based on network usage.

For each group of users, a fixed number of transactions is sent on the network. The report then analyzes which group's transactions have been included, how much did those users pay and how long did users end up waiting.


The "Summary" section of the report is short, and worth reading in full, but TL;DR:

* We see two clear "periods" in the simulation: when the `BASE FEE` is converging to its equilibrium, and when it is stable;
* During `BASE FEE` instability periods, clever 1559 users originate the majority of included transactions;
* The transaction pool's behaviour changes depending on which "phase" we were in. When the base fee is unstable, there are lots of evictions and re-sorting of the pool, but when it is stable, the pool has very little evictions.

When discussing this on the implementers' call, two interesting things came out.

First, the fact that the `BASE FEE` risks being less stable if there are more legacy transactions on the network *and* that 1559-styles transactions tend to be prioritized for inclusion during those periods creates an incentive to adopt 1559-style transactions.

Second, as 1559-style transaction usage grows and the `BASE FEE` stabilizes, gas price estimations for legacy transactions will become more accurate, given that they can use the `BASE FEE` value in their estimate. In other words, 1559 users will help reduce the variance in gas prices on the network, narrowing the confidence interval of gas price estimators' estimations.

## Other Updates 👀

Plenty of updates already, but one last thing worth noting is that OpenEthereum is hiring a full time developer to work on EIP-1559 🎉

If you are interested in the role, you can apply [here](https://boards.greenhouse.io/gnosis/jobs/4978262002?t=addc4e802)!

## Next Steps ✅

This update was long overdue! Here's what will be keeping us busy until the next one:

* Sharing the results of the recent R&D work with the community, including AllCoreDevs, to gather feedback;
* Finding experts who can provide a better analysis of the base fee update rule;
* Getting all client implementations syncing on the large state testnet and use the transaction generator tool to test the performance on the network;
* Comming up with good sorting algorithms for miners and non-mining nodes' transaction pools.

We also have [one final implementers' call](https://github.com/ethereum/pm/issues/229) scheduled before the holidays 🎄

Thanks for reading 😁

----

[0] Which, while they don't become _more_ likely under 1559, may become more beneficial.

[1] Forking mainnet and exposing mainnet variants at the client level could easily open the door for replay attacks and scams.

[2] Under the hood, it is sending ETH to `0x0...1`, `0x0..2`, `0x0..3`, etc. and making a storage entry for `0x0..1`, `0x0..2`, `0x0..3`, etc. until it reaches the right amount of accounts and storage slots.

[3] The document has the following disclaimer: *This document is mainly intended to serve as a basis of discussion for the upcoming implementers’ call. It will be followed up by a more comprehensive writeup. As the Quilt team has only recently joined the EIP-1559 effort, it is very possible that we made incorrect assumption or overlooked relevant existing work.*

[4] If `FEE CAP ` is less than `BASE FEE`, the transaction cannot be included in the block.