“Unveiling the London Mainnet: What it Means for Ethereum’s Future”

Significant Update

On July 21, 2021, a consensus complication was detected on the Ropsten network, where the go-ethereum, Erigon, and Nethermind implementations exhibited different transaction validation processes compared to Besu and OpenEthereum. New releases of the impacted clients have been distributed and are referenced in the “Client Versions” table below. The block number for London remains unchanged, still at 12 965 000. Node operators utilizing an affected client MUST upgrade to the latest release.

A summary of the issue is available in the “Ropsten Consensus Issue” section.

London

After a successful testnet deployment, the London upgrade is now prepared for activation on the Ethereum mainnet. It is anticipated to launch at block 12 965 000, expected between August 3-5, 2021.

Client Versions

To ensure compatibility with the London upgrade, node operators must update the client version they are running. The versions listed below for each client support the London upgrade on the Ethereum mainnet. These releases differ from the previously announced versions that were compatible with London on testnets. Older versions do not support London on mainnet.

Remarks:

• For miners: London will modify how the targeted gas limit is managed on the network. Please consult the “As a miner, what do I need to do?” section below for specifics.
• The Besu release was updated on August 4, 2021, due to a non-London related defect affecting the transaction pool. For further information, see here.
• The versions of go-ethereum, Nethermind, and Erigon were revised on July 23, 2021, resulting from the Ropsten consensus issue detailed below.
• The OpenEthereum client will be phased out following the London upgrade. The OpenEthereum team is collaborating with Erigon to ensure a seamless transition for users. Additional information can be accessed here.

London EIPs

The subsequent EIPs are incorporated in the London upgrade:

The Ethereum Cat Herders have published a blog post outlining the specifics of these EIPs.

It is important to mention that EIP-1559, while backward compatible with the current transaction format, introduces alterations to the block header, introduces a new transaction type, provides new JSON RPC endpoints, and modifies client behavior in several aspects (mining, transaction pool, etc.). It is highly advised that projects familiarize themselves with the EIP. A more comprehensive list of resources related to EIP-1559 can be found here.

Bug Bounty Bonus

To attract more scrutiny on the modifications coming with the London upgrade, all bounties for vulnerabilities related to the London upgrade will be doubled until the upgrade is executed. Issues that are eligible for the doubled bounty include cross-client consensus problems involving the following clients: Geth, Besu, Nethermind, OpenEthereum, and Erigon. For full particulars regarding the bug bounty’s scope and limitations, refer to https://bounty.ethereum.org/#rules.

Ropsten Consensus Issue

On July 21,2021, a consensus problem was identified on the Ropsten testnet. The complication arose from a missing validation for 1559-style transactions by several client implementations. In essence, a transaction where the account’s balance was greater than the effective gas utilized by the transaction, but lesser than the transaction’s maxFeePerGas multiplied by the gasPrice was mistakenly included in a block.

A comprehensive analysis of the issue can be found in the eth1.0-specs repository. The versions affected by this flaw are go-ethereum 1.10.5, Nethermind 1.10.77, and Erigon 2021.07.03-alpha. If you are utilizing one of these versions, please upgrade your client to the version specified in the table above.

FAQ

As an Ethereum user or Ether holder, is there anything I need to do?

If you utilize an exchange (such as Coinbase, Kraken, or Binance), a web wallet service (like Metamask, MyCrypto, or MyEtherWallet), a mobile wallet service (such as Coinbase Wallet, Status.im, or Trust Wallet), or a hardware wallet (like Ledger, Trezor, or KeepKey), you do not need to take any action unless instructed to do so by your exchange or wallet service. If you operate your own Ethereum node, an upgrade is necessary for your node. Please refer to 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?

Acquire the latest version of your Ethereum client as detailed in the table above.

As a miner, what do I need to do?

First, obtain the latest version of your Ethereum client, as indicated in the table above. Next, you will need to manually adjust your gas limit target to double the current value. This adjustment is necessary because once London is activated, the block size will be doubled, and EIP-1559 will maintain blocks at approximately 50% capacity. This modification can be performed via JSON-RPC, without restarting your node, on all clients that support mainnet-compatible mining.

For instance, if prior to London you were targeting a block size of 15,000,000 gas, you will now need to aim for a 30,000,000 gas limit to sustain the average number of transactions per block. If you do not adjust your gas limit target on or after block 12 965 000, you will inadvertently reduce the block size on the network. The following table contains the specific API calls for each client that you should utilize to update your gas limit target.

Note: Nethermind, Erigon, and EthereumJS do not presently 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 has not been updated to the most recent version (outlined above), your client will synchronize to the pre-fork blockchain when the upgrade takes place. You will find yourself trapped on an incompatible chain that follows the outdated rules, prohibiting you from sending Ether or operating within the post-upgrade Ethereum network.

What is a network upgrade in Ethereum-land?

A network upgrade represents a modification to the fundamental Ethereum protocol, establishing new regulations to enhance the system. The decentralized nature of blockchain technologies complicates network upgrades. Upgrades within a blockchain necessitate collaboration and communication with the community, alongside the developers of various Ethereum clients to ensure a smooth transition.

What occurs during a network upgrade?

Once the community reaches a consensus on which alterations should be integrated into the upgrade, the modifications to the protocol are implemented into the various Ethereum clients, such as geth, Erigon, Besu, and Nethermind. The protocol changes are activated at a predetermined block number. Any nodes that remain unupdated to the new regulations will be left behind on the older chain where the previous rules continue to apply.

Why “London”?

After Istanbul, we exhausted our naming options for the planned network upgrades. It was proposed to use Devcon city names for upgrades, and we embraced this idea! London is where Devcon 1 was held. It came after Berlin Devcon 0.

Thank You!

A heartfelt thanks to everyone involved in researching, planning, executing, testing, breaking, fixing, re-testing, deploying, stress-testing, and assisting in any other way to bring London to fruition 😁🇬🇧

Special thanks to Benjamin Davies for the cover image for this post!

Disclaimer

This is a rapidly evolving and highly technical domain. If you opt to implement the suggestions in this post and continue to engage, ensure that you comprehend how it affects you. Understand that risks are involved, including but not limited to unexpected bugs. By choosing to follow these recommendations, you alone bear the consequences of the outcomes. This post and its recommendations do not constitute a sale or create any warranties of any kind, including but not limited to anything related to the Ethereum network or the Ethereum clients referenced herein.