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


 294 total views

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.

Source: GitHub

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.

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

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

Adblock test (Why?)

Disclaimer: does not endorse any content or product on this page. While we aim at providing you all important information that we could obtain, readers should do their own research before taking any actions related to the company and carry full responsibility for their decisions, nor can this article be considered as investment advice or recommendations. Every investment and trading move involves risk, you should conduct your own research when making a decision.