What's coming in the London Hardfork?

Looking at all the details of the upcoming fork

The Berlin Hardfork only just went live on April 14th after block 12,224,00. Next up will be the London Hardfork in July which will include EIP-1559 and is scheduled for July 14th (no exact block decided yet).

London Schedule

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

EIP-1559: Fee market change for ETH 1.0 chain

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:

Ultrasound ETH

Since the Berlin hardfork, we also have the EIP-2718 which allows for an easy way to add more transaction types. This standard can be used to create new EIP-1559 compatible transactions. For now EIP-1559 is fully backwards compatible and it will only work once tools and libraries have added functionality for this new transaction type.

You can see on the right that currently most libraries haven't even started with their implementations. An up-to-date list for support by tools in the ecosystem can be found here. One WIP example would be the EthereumJS pull request here.

EIP-1559 Support

EIP-3198: BASEFEE opcode

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

EIP-3554: Difficulty Bomb Delay to December 2021

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.

Too Difficult

Now EIP-3238 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.

EIP-3529: Reduction in refunds

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.

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.

Markus Waas

Solidity Developer

More great blog posts from Markus Waas

  • Binance Smart Chain

    How to use Binance Smart Chain in your Dapp

    Deploying and onboarding users to the Binance Smart Chain (BSC)

    Defi has been a major contributor to the Binance Smart Chain taking off recently. Along with increasing gas costs on Ethereum mainnet which are actually at one of the lowest levels since a long time at the time of this writing, but will likely pump again at the next ETH price pump. So how does...

  • Using the new Uniswap v3 in your contracts

    What's new in Uniswap v3 and how to integrate Uniswap v3

    If you're not familiar with Uniswap yet, it's a fully decentralized protocol for automated liquidity provision on Ethereum. An easier-to-understand description would be that it's a decentralized exchange (DEX) relying on external liquidity providers that can add tokens to smart contract pools and...

  • Computer Deployment Terminal

    The Ultimate Ethereum Mainnet Deployment Guide

    All you need to know to deploy to the Ethereum mainnet

    We all love Ethereum, so you've built some great smart contracts. They are tested intensely with unit-tests and on testnets. Now it's finally time to go to mainnet. But this is a tricky business... 1. What exactly is a deployment transaction? First let's quickly discuss what a contract deployment...