Thread by @TimBeiko

We just wrapped up another @ethereum #AllCoreDevs 🤝

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

Recap below 👇🏻

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

First on the call we discussed the London upgrade going live on Goerli and Ropsten. For Goerli, @vdWijden and Karim from @ConsenSysQuorum spammed the network before the fork block and after it to make sure things went smoothly, which they did 🎉

On Rinkeby, the @go_ethereum team found a small issue in their validator configs: the minimum gas price that miners/validators accept in Geth is 1 gwei, and post-London this is calculated with the priority fee instead.

A lot of transactions were stuck because they had a 1 gwei max priority fee + max fee, and the network had a base fee of 7 wei, so the priority fee received by validators was 0.999999993 gwei, not 1. This was fixed by lowering the limit that's accepted by validators 👍🏻

With that being said, all clients reiterated being comfortable with a deployment block of 12965000 for mainnet, as confirmed earlier this week 🎉

TL;DR: London should hit mainnet August 4th (unless, as always, a critical security issue is found) 🇬🇧

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

The one final issue to discuss w.r.t. London was a technicality about where and when to store the gas price that actually gets paid by the user.

Because both fields in 1559-style transactions are *maximums* (max fee + max priority fee), the amount that's actually paid by users can only be determined post-execution, but that's still a pretty important thing!

To do this, we had agreed to add an `effectiveGasPrice` in the transaction receipt, which returns the price paid post-execution by the transaction (i.e. base fee + priority fee).

The question was whether this should also be returned for pre-London transactions (with just the gas price in that field). Not all clients were doing so, but we agreed that we should, as it will make building tooling that leverages this field easier.

Similarly, in order to keep things easy for tooling, the @go_ethereum implementation currently returns the "effective gas price" as a "gasPrice" field in a 1559-style transaction. This means that tools who rely on "gasPrice" won't necessarily need to adapt to support 1559.

Geth were the only ones doing this (others just have maxPriorityFeePerGas + maxFeePerGas in the transaction and then effectiveGasPrice in the receipt), but we agreed everyone should add it for consistency, AND, that we would mark that field as deprecated.

This means, if you build tooling that relies on the gasPrice field of a transaction, it should still work for 1559-style txns post-London, BUT YOU SHOULD EXPECT THAT FIELD TO GO AWAY AND USE EFFECTIVEGASPRICE FROM THE RECEIPT INSTEAD 😄

See this PR: github.com/ethereum/eth1.…

One more note on this: because the effective gas price can't be determined post execution, the "gasPrice" field of 1559-style txns will be set to the maxFeePerGas pre-execution, and then to the effectiveGasPrice after the txn is mined.

Similarly, if you eventually want to calculate effectiveGasPrice without querying a transaction receipt, you can do it with just the block header's base fee and the txn's maxPriorityFee + maxFee... and a bit of math :-)

Note: this is a small change for clients, and all teams expect to have mainnet-compatible London releases out early next week. Expect a proper announcement on blog.ethereum.org mid-week with the full list of versions 👀

Relatedly, a note for miners ⛏

London will double the block size on the network, because EIP-1559 aims to keep blocks 50% full. This will happen automatically on the fork block, but after it, miners will need to adjust their target gas limit!

If you want to keep having 15m gas of transactions on average, you will now need to target 30m. All mainnet-compatible mining clients have a JSON RPC call for this, linked in the next tweet 👇🏻

@go_ethereum: (docs PR, code merged) github.com/ethereum/go-et…
@ConsenSysQuorum: besu.hyperledger.org/en/stable/Refe…
@OpenEthereumOrg: openethereum.github.io/JSONRPC-parity…

Following from this, we had a discussion, prompted by @trent_vanepps about how clients handle the non-consensus parts of 1559, specifically transaction pool sorting and transaction replacement.

There was a lot of back and forth on this (which even led to finding a "bug" in a comment in the geth implementation live on the call!), so I recommend the livestream for nuance, but TL;DR, clients will sort the transaction pool by the effective tip going to miners.

Most clients are using a similar design for the pool, but @ErigonEth is working on another one, which is described in detail here: github.com/ledgerwatch/er…

As for transaction replacement, there are two approaches being used, both very similar, but with different implementations:

1. Require _both_ the maxPriorityFeePerGas and maxFeePerGas to be bumped by >=10% for a txn to be replaced

2. Require the "effective" priority fee (e.g. what the miner will be paid) to be bumped by >=10%.

Note: all clients use a 10% threshold, except OpenEthereum, at 12%.

One interesting thing, noted by @adietrichs is that because these things aren't as straightforward as sorting by the gasPrice value, we may see different clients prioritize different transactions in the pool (at the margin!).

This can be good, in that it "grows" the global transaction pool, but it's also worth keeping an eye on post-London to see if any client's implementation performs better, so that others can adjust.

And that was it for London! Next up on the call, we had @mkalinin2 walk us through the "merge readiness checklist" he and @dannyryan put together:

https://twitter.com/mkalinin2/status/1413171206858199050

He shared his screen and walked through it on detail in the call, so I recommend watching the recording if you are interested in the open questions related to the merge. I'll summarize the questions/comments people had about it !

The biggest one was about swapping the value of the DIFFICULTY opcode to the RANDOM value from the beacon chain. There were some concerns about "overloading" difficulty, and specifically about the fact that the current difficulty < 2^256 and RANDOM is a 256 bit value.

Given how much the difficulty value is used in the clients, there could be some problems if we pass a 256 bit number everywhere, and the impact of that should at least be investigated. There are also other options (e.g. set the DIFFICULTY to 1/0/last difficulty) post-merge.

One challenge with those is that, even though the DIFFICULTY opcode is bad source of randomness, most of its use is for pseudo-randommness today, so it could break applications to hard code its value.

Another thing that was mentioned by @peter_szilagyi is that the geth team is currently working on post-merge sync, and that eth/65 and lower versions of the eth protocol make it much harder to implement this.

Like they had previously announced, post-London, geth will be dropping eth/65 and lower in order to only keep eth/66 for networking. This version includes request IDs, which makes it easier to implement the post-merge syncing algorithm.

Lastly, @mkalinin2 asked what the next steps should be for him and others working on the merge, and it was agreed that writing (proto)EIPs, specs, etc. for the execution-layer changes made the most sense, as well as trying to provide as context around each item on the checklist.

The last thing we discussed was how we should generally approach planning, both specifically for The Merge vs. Shanghai, and then in general for Ethereum.

This was quite a "fuzzy" conversation, so it's hard to summarize well, but it's very accessible, so I recommend YT 📺

Some of my notes:

- It's very hard for client teams to make two things the top priority: if we focus on the merge now, we likely can't focus on Shanghai at the same time.

- Having fixed hard fork schedules maybe? could help, but we've kind of tried and failed before.

- Hard forks are very different for client teams to work on than "client maintenance", which tend to involve extensive refactors. When working on a HF, a lot of the maintenance work has to be put on hold.

- Consequently, you need downtime between network upgrades if you want to make significant improvements to the client, some of which can take several months/quarters/years..!

- That being said: there is a _lot_ on the Ethereum roadmap for the next 1-3 years, so we need to find a way to balance all of this (some comments in zoom mentioned we had the same conversation 2 years ago..!)

- One thing to note is we've probably scaled our throughput to the level we wanted it 2 years ago, but doing everything we want to do requires another increase in throughput.

- For London specifically, there were two things that were demanding: the large nature of the changes relative to previous upgrades, and the fact that people were trying to push even more in the upgrade.

- One cause of people pushing for their EIP to get in the current upgrade is there is a lot of uncertainty about when the next upgrade is going to come. Both in terms of time, and in terms of competing priorities in the roadmap.

- Another complicating factor is testing: proper testing requires ~every client team to have implemented the upgrade, and getting that done requires it to be prioritized, but ideally we'd want to prioritize things when they are well-tested, so chicken and egg 🐣

- Finally, there were some comments about how we'll handle post-merge upgrades, whether we can upgrade the consensus and execution layer separately, and what the dependencies are. In short, this is still a WIP and something we need to figure out in the coming months!

That discussion brought us all the way to the end of the call! There was no very specific conclusion, but this is definitely something I need to think about more, and I hope to have thoughts to share on the next ACD.

I'll see you then, on July 23, at 14:00 UTC 👋🏻