On July 21, 2021, a consensus issue was identified on the Ropsten network, where the go-ethereum, Erigon and Nethermind implementations had different transaction validation logic than Besu and OpenEthereum. New versions of the affected clients have been released and are linked in the “Client Versions” table below. The block number for London is unchanged, and still is 12 965 000. Node operators using an affected client MUST upgrade to the latest version.
An overview of the issue is provided in the “Ropsten Consensus Issue” section.
After a successful testnet deployement, the London upgrade is now ready to be activated on the Ethereum mainnet. It will go live on block 12 965 000, which is expected between August 3-5, 2021.
In order to be compatible with the London upgrade, node operators will need to update the client version that they run. The versions, listed below for each client, support London on the Ethereum mainnet. These releases are different from the previously announced releases that supported London on testnets. Previous versions do not support London on mainnet.
|Client||Version Number||Download Link|
|Erigon (f.k.a. TurboGeth)||Download|
|OpenEthereum (f.k.a. Parity)||v3.3.0-rc.4||Download|
- For miners: London will change how the target gas limit is handled on the network. Please see the “As a miner, what do I need to do?” section below for details.
- The Besu version was updated on August 4, 2021. This was due to a non-London related bug affecting the transaction pool. See more here.
- The go-ethereum, Nethermind and Erigon versions have been updated on July 23, 2021. This was due to the Ropsten consensus issue, detailled below.
- The OpenEthereum client will be deprecated after the London upgrade. The OE team is working with Erigon on a smooth transition path for users. More information can be found here.
The following EIPs are included in the London upgrade:
- EIP-1559: Fee market change for ETH 1.0 chain
- EIP-3198: BASEFEE opcode
- EIP-3529: Reduction in refunds
- EIP-3541: Reject new contracts starting with the 0xEF byte
- EIP-3554: Difficulty Bomb Delay to December 1st 2021
The Ethereum Cat Herders have put out a blog post going over the details of these EIPs.
It is worth noting that EIP-1559, while backwards compatible with the current transaction format, introduces changes to the block header, adds a new transaction type, comes with new JSON RPC endpoints, and changes the behavior of clients in several areas (mining, transaction pool, etc.). It is highly recommended that projects familiarize themselves with the EIP. A more extensive list of resources related to EIP-1559 can be found here.
Bug Bounty Bonus
In order to get more eyes on the changes coming in the London upgrade, all bounties for vulnerabilites related to London upgrade will be doubled, up until the upgrade happens. Examples of issues that would be eligible for a doubly are cross-client consensus issues between the following clients: Geth, Besu, Nethermind, OpenEthereum and Erigon. For full details about the bug bounty’s scope and restrictions, see https://bounty.ethereum.org/#rules.
Ropsten Consensus Issue
On July 21, 2021, a consensus issue was found on the Ropsten testnet. The issue was caused by a missed validation for 1559-style transactions by some client implementations. In short, a transaction whose account’s balance was larger than the effective gas used by the transaction, but lower than the transaction’s
maxFeePerGas multiplied by the
gasPrice was included in a block erroneously.
A full postmortem of the issue is available in the eth1.0-specs repository. The affected versions containing this bug are go-ethereum 1.10.5, Nethermind 1.10.77 and Erigon 2021.07.03-alpha. If you are running one of these versions, please update your client to the version listed in the table above.
As an Ethereum user or Ether holder, is there anything I need to do?
If you use an exchange (such as Coinbase, Kraken, or Binance), a web wallet service (such as Metamask, MyCrypto, or MyEtherWallet), a mobile wallet service (such as Coinbase Wallet, Status.im, or Trust Wallet), or a hardware wallet (such as Ledger, Trezor, or KeepKey) you do not need to do anything unless you are informed to take additional steps by your exchange or wallet service. If you run your own Ethereum node, you need to upgrade your node. See the “As a non-mining node operator, what do I need to do?” section below.
As a non-mining node operator, what do I need to do?
Download the latest version of your Ethereum client, as listed in the table above.
As a miner, what do I need to do?
First, download the latest version of your Ethereum client, as listed in the table above. Then, you will need to manually change your gas limit target to twice what it currently is. This is because once London is live, the block size will be doubled and EIP-1559 will keep blocks about 50% full. This can be done via JSON-RPC, without restarting your node, on all clients which offer mainnet-compatible mining.
For example, if prior to London you were a targetting a block size of 15,000,000 gas, you will now need to target a 30,000,000 gas limit to maintain the same amount of transactions per block, on average. If you do not change your gas limit target on or after block 12 965 000, you will start lowering the block size on the network . The table below provides the specific API call for each client you should use to update your gas limit target.
|Client||JSON RPC API|
|OpenEthereum (f.k.a. Parity)||
Note: Nethermind, Erigon and EthereumJS do not yet support mining on the Ethereum mainnet.
What happens if I am a miner or node operator and I do not participate in the upgrade?
If you are using an Ethereum client that is not updated to the latest version (listed above), your client will sync to the pre-fork blockchain once the upgrade occurs. You will be stuck on an incompatible chain following the old rules and you will be unable to send Ether or operate on the post-upgrade Ethereum network.
What is a network upgrade in Ethereum-land?
A network upgrade is a change to the underlying Ethereum protocol, creating new rules to improve the system. The decentralized nature of blockchain systems makes a network upgrade more difficult. Network upgrades in a blockchain require cooperation and communication with the community, as well as with the developers of the various Ethereum clients in order for the transition to go smoothly.
What happens during a network upgrade?
After the community comes to an agreement concerning which changes should be included in the upgrade, changes to the protocol are written into the various Ethereum clients, such as geth, Erigon, Besu and Nethermind. The protocol changes are activated at a specific block number. Any nodes that have not been upgraded to the new ruleset will be abandoned on the old chain where the previous rules continue to exist.
After Istanbul, we ran out of names for our planned network upgrades. It was suggested to use Devcon city names for upgrades, and we did! London is where Devcon 1 took place. It followed the Berlin Devcon 0.
A big thanks to everyone who has been involved in researching, planning, implementing, testing, breaking, fixing, re-testing, deploying, stress-testing and assisting in any other way getting London deployed 😁🇬🇧
Shout out to Benjamin Davies for the cover image for this post!
This is an emergent and evolving highly technical space. If you choose to implement the recommendations in this post and continue to participate, you should make sure you understand how it impacts you. You should understand that there are risks involved including but not limited to risks like unexpected bugs. By choosing to implement these recommendations, you alone assume the risks of the consequences. This post and recommendations are not a sale of any kind, and do not create any warranties of any kind including but not limited to anything related to the Ethereum network, or the Ethereum clients referred to herein.