Here are the issues Ethereum Core devs are working on before London

The much-anticipated London upgrade to the Ethereum network, one designed to change the controversial Ethereum fee structure, is on track to launch on 4 August. As part of the London hard fork, Tim Beiko, the lead coordinator of several Ethereum upgrades, along with other core developers, recently provided a recap of the developments around the upcoming hard fork.

The meeting kicked off by highlighting Goerli & Rinkeby Forks. For the former (Goerli), the two developers, Marius VanDerWijden (@vdWijden) and another developer from @ConsenSysQuoru within the Ethereum space,

“…spammed the network before the fork block and after it to make sure things went smoothly, which they did.”

While for the latter, the Go Ethereum

team discovered a small setback in their validator configurations. “The minimum gas price that miners/validators accept in Geth is 1 gwei and post-London this is calculated with the priority fee instead,” the recap noted.

Due to this, however, “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 gwei, so the priority fee received by validators was 0.999999993 gwei, not 1.”

According to the developers, this problem was solved by lowering the benchmarks set by validators.

Additionally, different clients also agreed

with a deployment block of 12965000 for the mainnet.

Another issue that was discussed during the meeting revolved around the storage of gas price paid by the user. As things stand, both fields in 1559-style transactions include maximum fees (max fee + max priority fee). Again, to overcome this obstacle, the team has now added an ‘effectiveGasPrice’ in the transaction receipt to only incorporate the price paid after the execution of the transaction (base fee + priority fee).

On the back of these updates, Beiko also had an update for the network’s miners.

See more

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!

— Tim Beiko | timbeiko.eth ?? (@TimBeiko) July 9, 2021

Moving on, the discussion also shed some light on clients handling the non-consensus parts of 1559 as well, specifically transaction pool sorting and transaction replacement. While most of the clients used a similar design for the pool, for the latter, two different approaches were used. Both very similar, “but with different interpretations.”

See more

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%.

— Tim Beiko | timbeiko.eth ?? (@TimBeiko) July 9, 2021

The complexity of the same was highlighted by one of the developers, Ansgar.eth (@adietrichs), who noted, 

“…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!).”

Tim Beiko closed the London update discussion by opining,

“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.”