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

  • Migrating from Truffle to Buidler

    And why you should probably keep both.

    Why Buidler? Proper debugging is a pain with Truffle. Events are way too difficult to use as logging and they don't even work for reverted transactions (when you would need them most). Buidler gives you a console.log for your contracts which is a game changer. And you'll also get stack traces...

    Read more

  • Contract factories and clones

    How to deploy contracts within contracts as easily and gas-efficient as possible

    The factory design pattern is a pretty common pattern used in programming. The idea is simple, instead of creating objects directly, you have an object (the factory) that creates objects for you. In the case of Solidity, an object is a smart contract and so a factory will deploy new contracts for...

    Read more

  • How to use IPFS in your Dapp?

    Using the interplanetary file system in your frontend and contracts

    You may have heard about IPFS before, the Interplanetary File System. The concept has existed for quite some time now, but with IPFS you'll get a more reliable data storage, thanks to their internal use of blockchain technology. Filecoin is a new system that is incentivizing storage for IPFS...

    Read more

  • Downsizing contracts to fight the contract size limit

    What can you do to prevent your contracts from getting too large?

    Why is there a limit? On November 22, 2016 the Spurious Dragon hard-fork introduced EIP-170 which added a smart contract size limit of 24.576 kb. For you as a Solidity developer this means when you add more and more functionality to your contract, at some point you will reach the limit and when...

    Read more

  • Using EXTCODEHASH to secure your systems

    How to safely integrate anyone's smart contract

    What is the EXTCODEHASH? The EVM opcode EXTCODEHASH was added on February 28, 2019 via EIP-1052. Not only does it help to reduce external function calls for compiled Solidity contracts, it also adds additional functionality. It gives you the hash of the code from an address. Since only contract...

    Read more

  • Using the new Uniswap v2 in your contracts

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

    Note : For Uniswap 3 check out the tutorial here. What is UniSwap? 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...

    Read more

  • Solidity and Truffle Continuous Integration Setup

    How to setup Travis or Circle CI for Truffle testing along with useful plugins.

    Continuous integration (CI) with Truffle is great for developing once you have a basic set of tests implemented. It allows you to run very long tests, ensure all tests pass before merging a pull request and to keep track of various statistics using additional tools. We will use the Truffle...

    Read more

© 2024 Solidity Dev Studio. All rights reserved.

This website is powered by Scrivito, the next generation React CMS.