---
tags: 1559
---

# The State of 1559 - Update 006 🔥

*:star: I've compiled a list of [1559 Resources](https://hackmd.io/@timbeiko/1559-resources) which includes analyses, documentation, explainers, etc. It is linked in the sidebar of these updates :star:*

## TL;DR 👀

* There was a bug in the large state testnet, we're restarting it 🐞
* Polishing the spec: EIP-2718 support on the way, and a `BASE FEE` opcode EIP drafted :nail_care:
* A quick Vitalik post about why "200% full" blocks should be fine on mainnet :chart_with_upwards_trend:
* We've got a "good enough" strategy for managing the transaction pool ✅
* New simulations & analyses for the transition to 1559 and `BASE FEE` manipulations :page_with_curl:
* Some miners voiced their opposition to 1559, we're thinking about how to best move things forward ⛏

## Client Updates ⛓

The main workstream on the client side over the holidays was getting the large state testnet ready. In short, this testnet aims to re-create conditions similar to mainnet to test whether nodes can handle blocks that are "200% full" when dealing with a large state.

We were hoping to schedule the test on this week's [implementers' call](https://www.youtube.com/watch?v=KllIW2hqw2I), but we found some last minute bugs! Some of the configs used by Besu to initialize the testnet were not supported by other clients, and after implementing a quick fix for this, we found an overflow bug in the `BASE FEE` calculation.

Because the testnet was built using Besu's implementation, the simplest path forward at this point is to re-generate the testnet data, which should take about two weeks, and have Besu, Nethermind and Geth in sync from the start of the process. This way, any further bugs will be discovered during, and not after, the data generation process.

But, don't worry, we've got plenty of other work to keep us busy in the meantime!

With Berlin being almost ready to go, it is now time to update EIP-1559 to align it with EIP-2718. 2718 proposes a framework for handling multiple transaction types. The first new transaction type will be introduced in Berlin with EIP-2930. EIP-1559 transactions will thus be the second new transaction type that gets introduced. Along with that, we've drafted [an EIP to add a `BASE FEE` opcode](https://eips.ethereum.org/EIPS/eip-3198). This will be useful for contracts that want to query a block's `BASE FEE` directly, and could lead to better alternatives to Gas Token.

Finally, Vitalik shared [a write up](https://notes.ethereum.org/@vbuterin/eip_1559_spikes) meant to address the "200% full blocks" concerns related to 1559. The post is concise and worth reading fully, but here's a TL;DR:
* Most issues with large blocks have to do with the average block size, rather than the maximum block size. 1559 doesn't change this significantly [0];
* The main issue with a short span of large blocks is DoS attacks;
* The worst DoS attacks will be mitigated after Berlin with EIP-2929;
* Under EIP-1559, the rising `BASE FEE` would make DoS attacks grow in cost very quickly, which would make them prohibitively expensive to sustain for too long;
* This leave us with the problem of "short spikes of large blocks", which is something that is already occuring on Ethereum today given that block production follows a Poisson process.

Hopefully this write up and our upcomming large state testnet test will help us check off the last item on the `Client-level Open Issues` section of the [Mainnet Readiness Checklist](https://github.com/ethereum/pm/blob/master/Fee%20Market%20Meetings/mainnet-readiness.md#client-level-open-issues) :hand_with_index_and_middle_fingers_crossed:.

## R&D Updates 🤖

Three main updates on the R&D front: we've come up with a good enough approach to managing the transaction pool under EIP-1559, new simulations look at the transition from our current state to 1559, and some analysis of `BASE FEE` manipulation by Nethermind.

### Transaction Pool Management

On the latest implementers' call, Ansgar shared a [concise proposal](https://hackmd.io/@adietrichs/1559-transaction-sorting-part2) for how transaction pool handling could work post-1559. The approaches for both mining and non-mining nodes rely on the fact that under 1559, the number of pending but includable transactions will, most of the time, be quite low [1].

For miners, segregating the transaction pool between includable & unincludable transactions will allow them to easily start filling blocks with the includable ones. For non-mining nodes, it seems that simply sorting the transaction pool by `FEE CAP`, while not perfectly optimal, should be good enough in most cases.

Luckily, because the transaction pool behavior is not part of consensus, clients are free to both vary in their implementations and update it outside of network upgrades. This means that we can ship 1559 with the recommendations from Ansgar and improve things as needed once we have usage data.

Given that the main risk with regards to the transaction pool was not finding a "good enough" approach, we can consider this done. Checked off the [Mainnet Readiness Checklist](https://github.com/ethereum/pm/blob/master/Fee%20Market%20Meetings/mainnet-readiness.md) ✅!

### Transition to 1559

Barnabé and Fred have a [new simulation notebook](https://github.com/barnabemonnot/abm1559/blob/master/notebooks/transition1559.ipynb) out which analyses the impact of the new transition approach in 1559, where legacy transactions are still allowed on the network by setting their `FEE CAP` to `GAS PRICE` and `TIP` to `FEE CAP - BASE FEE`.

The notebook shows that when both types of transactions are possible on the network, gas price oracles can look at the price paid by 1559-style transactions to provide better fee estimations for legacy-style ones. In other words, as the report states, "the behaviour of 1559 users drives oracles closer to the true market price."

Barnabé explained the results in more detail in a great [tweet thread](https://twitter.com/barnabemonnot/status/1349615592139943939) 🐦

### Base Fee Manipulation

The Nethermind team has been looking into the different scenarios under which the EIP-1559 `BASE FEE` could be manipulated, both on the main Ethereum network, as well as potential private network implementations, such as [Oiler Network](https://medium.com/oiler-network/oiler-research-eip-1559-basefee-manipulations-6de2d177bd66).

One takeaway from their [recent analysis](https://medium.com/nethermind-eth/the-manipulation-of-the-basefee-in-the-context-of-eip-1559-4b082898271c) is that while, in some cases, single actors could manipulate the `BASE FEE` upwards [2], it would require the coordination of a cartel of miners to manipulate it downwards.

The following graph from the analysis shows the likelihood of success for manipulating the `BASE FEE` downward based on the hashrate controled by the cartel:


The report recommends that, to make it even harder for cartel to manipulate the `BASE FEE`, the update rule should not be symmetric. This is not the first time the `BASE FEE` update rule has been shown to be suboptimal: Tim Roughgarden also noted this in [his analysis](http://timroughgarden.org/papers/eip1559.pdf).

Improving this rule is still an open nice-to-have on the Mainnet Readiness Checklist. Reach out if you think you can help!

## Mining Concerns ⛏

Last but not least, the past few weeks have seen concerns raised by the mining community about EIP-1559. In short, because the `BASE FEE` in every transaction is burnt, miner revenue will be reduced by introducing EIP-1559.

I and other working on EIP-1559 are obviously biased here, but while it is true that miner revenue will decrease under 1559, it is worth noting that:

* Until recently, transaction fees had only represented a small fraction of miner revenue ([source](https://www.theblockcrypto.com/linked/79452/ethereum-miner-revenue-september-gas-fees));
* Fee-denominated chains can lead to an increased risk of near-head re-orgs due to miners "fighting" for high fee transactions ([source](https://www.cs.princeton.edu/research/techreps/TR-983-16));
* Other factors, such as the network hashrate ([currently at ATH](https://etherscan.io/chart/difficulty)) and ETH price (also near ATH) influence miner profitability;
* We don't yet know what percentage of transaction fees will be burnt under 1559. It is possible that while most transactions only have a small tip, the ones that absolutely need to be included ASAP (e.g. DeFi arbitrage) will use large tips, leading to a lesser-than-expected burn, or revenue loss. **Better estimated would be very welcome here!**

This being said, when discussing miners' concerns on the last implementers' call, we agreed that we should do the following:

1. Better document and communicate the impact of EIP-1559 on miners (*this is a start*);
2. Catalog miners' stance for/against 1559, ideally with their associated hashrate and share it with AllCoreDevs as part of the decision process regarding 1559;
3. When deciding whether to ship 1559 on mainnet, make it clear to the community that those objections were considered and, if 1559 goes live, why they were rejected.

For those who would like to engage in the discussion with regards to 1559 & mining, I've created a [discord room](https://discord.gg/87dV4zX82R). Note that we want to keep the conversation there civil & productive, and will be quick to moderate the channel if things get ugly :hammer: .

EDIT: Alex Stokes has also published a [great post](https://ralexstokes.medium.com/miners-favor-1559-b91e003b63eb) about why 1559 can better align miners' incentives with the rest of the community.

## Next Steps ✅

This update was _massive_, thanks for bearing with me! For clarity, here are the next steps mentioned throughout this note:

- [ ] Fix the consensus issues between Besu & other clients and restart the large state testnet;
- [ ] One the above is done, schedule a performance test with Besu, Geth and Netermind on the testnet;
- [ ] Add EIP-2718 support to the 1559 spec;
- [ ] Better document the impact of 1559 on miners;
- [ ] Reach out to various mining entities to gather their position on 1559;
- [ ] When done, share all of the above with AllCoreDevs 😁

Again, thanks for reading. See you next time!

---

[0] Under 1559, even if we have occasinal spikes with large blocks, the `BASE FEE` rises quickly enough to make these short in duration. This mean that the average block size over a long period, would not be significantly affected.

[1] This is because, on average, blocks will only be 50% full. This implies that new transactions can almost always be included in a block directly, assuming their `FEE CAP` is higher than the `BASE FEE`. In other words, most transactions are either unincludable (too low `FEE CAP`), or already included (because the blocks have room for them).

[2] This would be quite expensive, at ~250 ETH per 20 blocks.