The London Hardfork: What Changed

This article was written before London. Berlin activated at block 12,244,000 in April 2021; the final London activation block was 12,965,000, announced for early August 2021 rather than the preliminary July schedule used in this preview.

So let's take a look at the new changes and what you need to know as a developer.

EIP-1559 has been discussed for a long time. In short it proposes a new way gas prices are handled. Instead of a simple auction where the highest gas prices will be included by miners resulting in high fees paid to miners, there's a base fee which is always burned.

This base fee along with the maximum block sizes are adjusted dynamically:

• Block sizes will  increase or decrease depending on the state of the network congestion with a maximum block size of 25 million and a target of 12.5 million.
• Likewise the base fees also change depending on congestion. The maximum difference from block to block is predictable which allows wallets to auto-set the gas fees for users in a highly reliable fashion. It's expected that most users will not have to manually adjust gas fees, even in periods of high network activity.

A critical point is also ensuring the miner of a block are not receiving the base fee, because it removes their incentive to manipulate the fee in order to extract more fees from users. This results in ETH becoming ultra-sound money as Justin Drake puts it:

Clarification: EIP-1559 sets an elastic gas target at half the block gas limit; 25 million is not a permanent protocol maximum. Base fees are burned, while priority fees go to the block proposer. Net ETH supply depends on total issuance and burning over the period, so burning alone does not guarantee deflation.

EIP-3198 adds a BASEFEE opcode that returns the value of the base fee of the current block. This means your contracts will be able to have direct access to this. Besides use cases for layer 2 technologies, you could further use this for:

• Contracts that need to set bounties for anyone to “poke” them with a transaction could set the bounty to be BASEFEE + x, or BASEFEE * (1 + x). This makes the mechanism more reliable, because they will always pay “enough” regardless of market conditions.
• Implement gas futures which are more precise than gas tokens (we've covered gas tokens previously here).

block.basefee is denominated in wei per gas. A reimbursement also needs an appropriate gas allowance and priority-fee policy; BASEFEE + x alone cannot guarantee that an execution bounty covers the transaction.

EIP-3554 adds a delay to the difficulty bomb. What is the the difficulty bomb you ask?

It's a design that will encourage miners to switch to Ethereum 2.0. This will raise the difficulty level of Ethereum's Proof of Work puzzles. This would result in longer block times and effectively cut the rate of ETH rewards for miners.

Seeing as this mechanism increases the mining difficulty exponentially over time, it will eventually lead to something known as the ”Ethereum Ice Age”. This is when the Ethereum chain becomes so hard to mine that it becomes unattractive for miners to do so.

Now EIP-3554 delays the Ethereum difficulty bomb so that it won’t occur until some time around December 2021. This is the optimistic timeline if ETH2.0 progression is going well. It's very likely that this could be pushed back further. Originally summer 2020 was planned for this, but just in case ETH2.0 is ready sooner, the difficulty bomb is planned to start already this year.

This difficulty-bomb discussion is historical. Ethereum completed the Merge in September 2022 and now uses proof of stake.

EIP-3529 removes gas refunds for the SELFDESTRUCT opcode and also reduces gas refunds for SSTORE to a lower level which prevents most refund exploits.

In general people rarely actually used refunds, but having them actually lead to two unwanted consequences:

• GasToken: While they allowed users to get low gas prices even during network congestion, this obviously has a negative effect for the network itself.
• Refunds increase block size variance.

London also included EIP-3541, which rejects deployment of new runtime code beginning with byte 0xEF; it does not retroactively remove previously deployed code.

Lastly, what do you need to consider as dev?

For you as a developer you should think about:

• EIP-1559: If you develop a Dapp, you will need to worry less about setting proper gas prices. Simply letting MetaMask or whatever wallet you're integrating handle this logic will be perfectly fine.
• EIP-3529: Don't worry about those selfdestructs anymore, they will not give you any gas. Also know that GasTokens will not work anymore.

• EIP-3198: Maybe you have a use case where you'd like to access the base fee directly in your contract.