Full List of Ethereum London Upgrade Changes
The Ethereum (ETH) London network upgrade is fast approaching, and the core developers have released the final list of the Ethereum Improvement Proposals (EIPs) it’s comprised of – and one of them you’ll certainly recognize.
The London upgrade follows April’s Berlin upgrade, and is set for July.
This time around five EIPs will be included, and the first to be discussed is the much-talked-about, somewhat-criticized, and highly-anticipated EIP-1559. Per the Ethereum Foundation community manager Tim Beiko, this one is also the largest among the five changes to be introduced. What it will do, simply said is:
- burn a part of the transaction fees;
- bring a “base fee” in blocks on the network which will track the gas price the network accepts from transactions based on demand for blockspace, making it easier for wallets and users to estimate the right price for their transactions;
- add a new transaction type so users can specify the maximum fee they are willing to pay and the maximum miner tip, as well as get a refund for the difference between that maximum and the base fee and miner tip.
As a companion to this EIP comes EIP-3198. It adds a BASEFEE opcode, which returns the value of the base fee for the block it is executed in, enabling smart contracts to access this value on-chain, thus helping with fraud proofs submissions and trustless gas price derivatives creation.
This change will help offset some of the additional block size variance introduced by EIP-1559, which allows block to use up to twice the current gas limit, per Beiko. Before the London upgrade, up to 50% of the refunded gas could be used to execute further computation within the same block, he said, adding that this means that the maximum block size could be up to 1.5x the gas limit.
EIP-3541 is meant to set the stage for broader Ethereum Virtual Machine (EVM) improvements, as described in EIP-3540. It will prevent new contracts starting with the 0xEF byte to be deployed. While EIP-3540’s launch will require another network upgrade, even if it never gets deployed, EIP-3541 can also be used to reserve starting bytes for use in another scheme, said Beiko.
And lastly, we have another familiar one: the difficulty bomb delay. This time, EIP-3554 delays the difficulty bomb, aka the ice age, to December 1 – shorter than usual, given that by that date, “either the transition to proof-of-stake [PoS] will happen, or another network upgrade will need to take place on the network,” Beiko stated. As a reminder, the difficulty bomb needs to be delayed from going off until the transition from a proof-of-work consensus algorithm to PoS is ready, as it’s a mechanism that will ‘freeze’ mining.