# The State of 1559 - Update 007 🔥
## TL;DR 📝
* Large state testing is 99% done, expect a write-up soon 🔜
* EIP-1559 has been updated to be Berlin-compatible 🇩🇪
* We'll be proposing EIP-1559 for inclusion in the London Hard Fork during the next AllCoreDevs call 🇬🇧
* *Note: this doesn't guarantee a decison will be made on the next call, or that it will be accepted!*
* Miners are pushing back against EIP-1559 and others are pushing back against the pushback: lots of new write ups from both sides, and a [community call](https://medium.com/ethereum-cat-herders/ethereum-1559-community-call-d43d5f0bf909 ) is planned for this Friday ⛏
* A few bonus posts that were too good to ignore are linked at the end of this update 👇🏻
## Client Updates ⛓
As mentioned in the last update, we had our large state, cross-client performance test. ICYMI, the goal of this test was to check whether nodes could handle blocks with much more than 12.5m gas on a network with a state size comparable to mainnet.
We had run a dry-run of the test to make sure all the tooling worked and [shared the results](https://hackmd.io/@timbeiko/1559-prelim-perf) with AllCoreDevs. One piece of feedback that came out of this was to host nodes in multiple cloud regions vs. having them all co-located.
While this was already planned for the proper test because Nethermind's nodes were in Europe and Besu + Geth in America, based on that feedback, we decided to add a few Besu nodes in other AWS regions (Syndey, Paris) as well. And, of course, that's what broke 😅
We started the peformance test and quickly the two Besu nodes in different regions started processing blocks extremely slowly, even though all other nodes on the network (4 Geth, 4 Besu, 2 Nethermind) across Americas (Geth, Besu) and Europe (Nethermind) stayed perfectly in sync, kept processing blocks at a reasonable rate and consumed a normal amount of ressources.
Like all good bugs, the "Besu nodes in distant regions" one is proving hard to reproduce, and we've now re-run the test a few times for a few hours without it re-occuring. The team will keep investigating this week and share findings in a proper write-up of the performance tests.
Once we have that write-up, we'll be proposing EIP-1559 for inclusion in the next network upgrade, London. More on that right below 👇🏻
## EIP Update / London Calling 🇬🇧
EIP-1559 was first drafted in early 2019, almost two years ago! A lot has changed in the spec since then and we're at a spot where it can be considered pretty-close-to-final. It now uses EIP-2718-style transactions which are being introduced as part of the Berlin upgrade. If you haven't checked it out in a while, now is a good time to have a look at [the actual EIP](https://eips.ethereum.org/EIPS/eip-1559).
Also, I got feedback that the EIP didn't do a great job of articulating the various benefits 1559 brings, so I wrote [a longer, but hopefully more accessible, article](https://hackmd.io/@timbeiko/why-1559) explaining them.
Last but not least, with the London upgrade needing to be spec'ed soon, the next few AllCoreDevs calls will focus on what EIPs to include. Once we have a proper write-up for the large state performance test, I'll open an issue for EIP-1559 to be included in the upgrade.
We should cover that in the next AllCoreDevs call (March 5th), but that doesn't guarantee we'll come to a decision right then. If we do, then 1559 would likely go live on mainnet by the end of the summer. Fingers crossed 🤞🏻!
## Mining Updates ⛏
The biggest source of activity related to 1559 over the past month has been the discussions around the impact of 1559 on mining. Unsurprisingly, because EIP-1559 proposes to burn miner fees, most miners are opposed to it.
Several alternatives to 1559 are being proposed by miners, which mostly fall in three categories:
1. Changing EIP-1559 itself to remove the fee burn;
2. Increasing the block reward to make up for the lost fees;
3. Changing the proof of work algorithm to make it ASIC-resistant.
Let's look at these in more detail!
The first proposed approach is what Tim Roughgarden called "l-smoothing" in [his paper (Section 8.3.1)](http://timroughgarden.org/papers/eip1559.pdf). In short, instead of burning the `BASE FEE`, we give it to the N next miners, potentially with an increasing percentage of the `BASE FEE` being burnt over time. [Elayda](https://discord.com/channels/595666850260713488/692078615269212180/813471298956165151) explored this in a [short write-up](https://hackmd.io/@8Lo6sisiSrSosbAxVPXKgQ/SyQoEUbzu) shared on the mining discord.
The second approach is straightforward: increasing the block reward to make up for the lost fees from the burn. The issue here, aside from the general controvery around increasing the block reward, is determining which "fee period" to use to do so. The last few months? The last year? Since genesis?
The third approach would require a change to the proof of work algorithm. Again, this is a controversial topic given ProgPow's history. An alternative proposal which acheives a similar goal, [EIP-969](https://eips.ethereum.org/EIPS/eip-969), is being discussed by miners because it has less baggage than ProgPow.
Over the weekend, a long call was organized by BitsBeTrippin for miners to discuss the various proposals. A recording is available [here](https://www.youtube.com/watch?v=jgy6rqzljW4&feature=youtu.be).
A [community call](https://medium.com/ethereum-cat-herders/ethereum-1559-community-call-d43d5f0bf909 ) is planned **this friday, 14:00 UTC** between miners and various implementers, researchers, and EIP champions to discuss all of this.
It is worth noting that for any of these proposals to be accepted, the "thing to prove" isn't that EIP-1559 reduces miner revenue and we should make up for it, but that this reduction impacts the chain security. Or, as [Micah Zoltu]((https://discord.com/channels/595666850260713488/798586271445680129/813484723145932830)) more eloquently put it on the mining discord (emphasis mine):
> The primary issue (IMO) against l-smoothing is that security needs aren't strongly coorelated with blockspace demand, and Ethereum historically doesn't pay any more than necessary for security. **Arguing that miners should get any of the congestion fees requires arguing that there is a strong coorelation between chain security needs and blockspace demand.**
Micah had already written on the topic before as part of his [1559 Miner FAQ](https://hackmd.io/S6kW1MjvT8-SjmaoZTyaJw), which I strongly recommend!
On the non-mining side, Hasu and Georgios released [another EIP-1559 analysis](https://insights.deribit.com/market-research/miners-will-accept-eip-1559-here-is-why/), arguing that it is in miners' best economic interest to accept EIP-1559 as-is. The analysis goes into the various options that miners could have to push back against EIP-1559 and the benefits and risks of each of them for miners.
They first explore the strawmen scenario where miners simply do not upgrade to support EIP-1559, which, on Ethereum, is prevented by the difficulty bomb.
Then, they cover the case where miners decide to launch a fork of Ethereum which doesn't have EIP-1559. In that case, they would need to convince all the applications and users of Ethereum to use their fork over the one that has 1559.
After, they explore the idea of miners launching a fresh-state fork of Ethereum, which, along with having miners compete against other Ethereum competitors, would encounter issues regarding supply distribution.
Finally, they explore the scenario where miners stay on the 1559 chain, but decide to block its usage by not allowing blocks that raise the `BASE FEE`. They argue that this miner-activated soft fork would both result in an unstable equilibrium between the colluding miners, but also be interpreted by the community at large as an attack on Ethereum, a network which miners have a vested interest in due to their hardware investments.
The analysis is worth reading in full, and Georgios and Hasu will be present on this Friday's community call to discuss it.
One final mining post before we move on --- Adrian Sutton, one of the handful of "double core devs" (i.e. who has written production code for both an Eth1 and Eth2 client!), [wrote a short blog post](https://www.symphonious.net/2021/02/15/why-miners-can-be-simultaneously-paid-too-much-and-struggling-to-survive/) exploring why it can be simultaneously true that (1) the network is overpaying miners for security and (2) that individual miners feel underpaid. Highly recommended!
## Bonus: Barnabé's Substack 📚
This update is already quite long and packed with links, but one thing I could not omit was Barnabé's new substack, which will be covering EIP-1559 and fee markets on Ethereum more broadly.
His [first post](https://barnabe.substack.com/p/c139eae7-dc78-4970-bdf0-18b909f4e572) approaches the design of EIP-1559 from the angle of traffic congestion and is a great way to "grok" the EIP if you feel like you still don't fully get it yet.
## Next Steps ✅
While you're off reading all the things I linked here, here's what we'll be working on:
- [ ] Sharing a proper write-up of the large-state performance test for EIP-1559;
- [ ] Having the community call with miners & 1559 implementers/researchers/champions this Friday;
- [ ] Proposing EIP-1559 to be included in the London network upgrade;
Heads up: as the 1559 and AllCoreDevs process start to overlap more, so may these updates. More on that soon 👋🏻!