Thread by @TimBeiko

We had our 9th EIP-1559 Implementers' call this AM 🔥

Agenda: github.com/ethereum/pm/is…
Recording:

Summary below 👇🏻

https://twitter.com/TimBeiko/status/1339645443236536321

First on the call, @adietrichs gave an update on his work about transaction pool management. His latest writeup is available here: hackmd.io/@adietrichs/15…

The document is quite short, and worth reading, but here are the main takeaways with regards to mining ⛏

One note about "currently includable" transactions: under 1559, because blocks can be up to 200% full, it is expected that there often won't be many transactions whose FEE CAP is larger than the BASE FEE that aren't already included in a block.

The scenarios that lead to this happening are (1) the transaction is very recent (e.g. published since the last block), (2) the BASE FEE _just_ went down below the transaction's FEE CAP, making it "newly includable", (3) a block was mined before the txn could be included.

This is a big conceptual shift from right now where we have a large mempool and all transactions _could_ be included in the next block.

This means that for miners, the mempool can be optimized to only surface "includable" transactions, which should, most of the time, represent less transactions than can be included in a single block.

On the call, we had discussions about how frequently to "re-sort" the block that is being generated by miners. Currently, this happens every 1-3 seconds in geth. Under 1559, we could leave this unchanged, or even re-sort less frequently (e.g. only if the block is 200% full).

Re-sorting blocks less frequently would lead to transactions being included in order of appearance in the block, and could help prevent priority gas auctions (PGAs).

To be clear, though, given this isn't part of consensus, whatever setting is chosen here would only be a default: miners and other can tweak their transaction pool management as they like.

The other part of Ansgar's write up covers transaction eviction, i.e. when should nodes drop "unincludable" transactions from their tx pool. Again, it can be shared in full here:

Again, while there are many possible optimizations here, starting with a simple approach (sort by FEE CAP, evict lowest) is probably good enough to get started.

As mentioned on a previous call, to prevent transaction pool spamming, we can have clients only update a transaction if it has at least the same miner tip *and* a >X% (10?) increase in FEE CAP.

Legacy transactions could also be sorted by clients by using the gas price as a FEE CAP value.

Again, these would all be defaults, and one thing that @nethermindeth stressed is that we should try and make these settings configurable for miners!

There are some things clients will need to agree on (e.g. what types of txns shouldn't be broadcasted), but generally, we're all confident that @adietrichs's work provides sufficiently robust heuristics that "dealing with the transaction pool" isn't a risk to 1559 anymore 🎉!

(It's now been checked off as part of the Mainnet Readiness Checklist ✅)

Next up, we discussed the progress on our large state testnet. Quick recap: we want to build a testnet with a state comparable to mainnet to make sure clients can handle 200% full blocks when dealing with a large state.

@dimahledba had put together a "large state generator" that he demoed in the previous call and created a network with a comparable state to mainnet but... 😅

... to create it we used a genesis file param that only Besu supports and not Geth or Nethermind

We think we can salvage things with a bit of hardcoding in geth/nethermind to run the test, and we're hoping to get this sorted in the next few days. If everything works out, we expect to run our performance test sometime in the next week or two. Fingers crossed 🤞🏻!

It's not all bad news, though! Related to this topic, @VitalikButerin wrote up a short document explaining why he isn't too concerned with the occasional large blocks that 1559 will generate on the network: notes.ethereum.org/@vbuterin/eip_…

Again, short doc, worth reading 👀

Main argument is most "big blocks" issues only show up if _all_ blocks are big, not if occasional blocks are.

The one thing that _can_ be a problem with only a small number of large blocks is DoS attacks. Luckily, we're fixing the biggest issue related to this in Berlin with EIP-2929 🎉

FYI, this is another why 1559 can't ship before Berlin

A second reason why DoS attacks will be impractical under 1559 is that the BASE FEE increases quite quickly: long DoS attacks would quickly become extremely expensive.

And for short spans of 200% blocks? Well, given that block production follows a Poisson process, we already see similar conditions on mainnet today.

So, TL;DR, this is very promising. We'll still need to get core developers' take on this, and will also conduct our large state testnet test, but it seems like one of the biggest technical risks for 1559 is starting to vanish ⛅️

Another thing that was brought up on the call was miners' concerns with the EIP. It's worth watching the recording for the nuance here, but I'll try and summarize 😅

First, @tkstanczak made the good point that we should have an open dialog with the mining community about 1559.

@MicahZoltu summarized his takeaways of this past week's concerns as the following: miners have raised two issues with 1559. First, it will reduce their income (because of the burnt base fee) and second, it could lead to more mining centralization.

The reason for the second is that if income is reduced, operations with the largest margins, which is likely larger pools/miners, are the one that will be profitable, and miners with lower margins, which likely maps to smaller miners, will become unprofitable.

While this is true, he also noted there is another very important factor in mining profitability: ETH's volatility.

One point I made on the call is that mining depends on a host of factors (hashrate, price of ETH, the split between base fee & tip as part of total txn fees, etc.), and so it is very hard to provide a good estimate of the impact of 1559 on miners.

A few things we agreed could be done on the call to better manage this were:

1. Better communicating the scope and impact of the change from a mining perspective. I'll try and take a stab at this.

2. Try and gauge community sentiment from miners more explicitly to make it clear to core devs what the opposition is.

Note: this doesn't mean that we shouldn't go through with 1559 even if miners oppose it, but if we have a strong negative signal, we can be better prepared for the potentially rough transition.

3. When the time comes, make it clear to the community what AllCoreDevs' decision about 1559 is.

Once (1) is done, I'll try and coordinate (2) (likely with the help of @EthCatHerders 😸). (3) is still farther away, but I'll also make sure we communicate clearly what the decision is.

The next thing we discussed was adding EIP-2718 support to 1559. Recap: 2718 adds support for multiple transaction types and is being introduced in Berlin. 1559 transactions will thus be a new 2718-based type of transaction.

Everyone agreed it makes sense to start working on this. @MicahZoltu will update the 1559 spec to reflect this and clients will review over the next few weeks.

Then, we briefly discussed a new EIP by @dimahledba to add a BASE FEE opcode: eips.ethereum.org/EIPS/eip-3198

This was brought up on Twitter this week (h/t @nicksdjohnson

https://twitter.com/nicksdjohnson/status/1349083197250785280

), and everyone agreed it's a good, small change we should do along 1559 👍🏻

Another update by @dimahledba: he created a tool for people to join the 1559 testnet in <2 minutes ⏳👀!

Want to try it? Just run "npm install -g eip1559" and wait for it to download. Then "eip1559 run" will get you on the testnet!

We got a node up during the call 😁

Here's a short recording of the demo:

1m33 from start to finish!

And, finally, we didn't have time to cover it on the call, but @barnabemonnot has released another simulations notebook 🤖

He beat me to writing a tweet thread summarizing it, so I'll just link his here:

https://twitter.com/barnabemonnot/status/1349615592139943939

And that was it! We haven't scheduled the next implementers call because we'll have the large state testnet call whenever things are ready. I'll share an update here when that is done 😁