London Fork

The widely anticipated London fork is fast approaching and it is scheduled for block 12,965,000 (August 5th).

The Ethereum clients you need to be running in preparation for the fork (includes the fix that led to the consensus split on the Ropsten network):

The London Fork has several important protocol upgrades, most notably EIP-1559, that changes the underlying fee auction mechanism for enticing block producers to include transactions in their block. The upgrade includes changes to existing data structures, a new transaction format and a new JSON RPC call that may impact your project.

We’ll take this opportunity to briefly explain EIP-1559 before highlighting the changes your project may need to consider for the upcoming fork.

What is EIP-1559?

EIP-1559 is a fundamental change to how the network fee is specified for a transaction. It aims to provide a better user experience as there is a predictable clearing price for transactions, and to help shift the network’s monetary policy towards a deflationary supply over time - sometimes called “ultra-sound money” - more on that later.

The most significant change relates to setting the gas price for a transaction.  Prior to the fork, all pending transactions on the network (transaction pool) participated in a first-price auction and the transaction’s single gas price (e.g 100 gwei) represented a single bid in the auction. After the fork, most of the time, a transaction only needs to pay a clearing price alongside a small tip to entice block producers to include it. In a nutshell, the majority of transactions no longer need to compete in a first-priced auction and picking a competitive network fee should be easier for the user.

EIP-1559 transactions require three values to be considered when picking a network fee:

• Base fee. A fee that floats based on the network congestion and the most recent value can be fetched via a new JSON RPC call eth_feeHistory.
• Priority fee (tip). A fee to entice a block producer to include the transaction.
• Max fee. The highest network fee the user is willing to pay.

The final gas price paid by the user is computed:

transaction fee = baseFee + min(maxFee - baseFee, priorityFee)

To learn more about EIP-1559 and to understand the impact of the auction mechanism and associated deflationary supply policy, you can check out this article by Consensys.

Technical changes due to EIP-1559 (and EIP-3198)

We cover the technical changes for EIP-1559 (and EIP-3198) that may impact your project. This includes a new block format, a new transaction format, the new values for selecting a gas price, a new JSON RPC call and changed behaviour for several JSON RPC calls. Thanks to Tim Beiko for a list of API changes and other  resources.

Changes to the block header

Impacts the following JSON RPC calls:

• eth_getBlockBy*
  • A new field baseFeePerGas is included for post-London blocks
• eth_getUncleBy*
  A new field baseFeePerGas is included for post-London blocks

The block data structure includes a new field:

• baseFeePerGas is the base fee paid by all transactions in this block.

The field is empty for all blocks before the fork. If your project constructs a block header to verify it is following the longest chain (e.g., hashing a block header), then you may need to update your project to consider the new field. Otherwise, your project will fail to recognise the longest chain.

New transaction format and gas price mechanics

Impacts the following JSON RPC calls:

• eth_getRawTransaction
  • May return RLP encoded EIP-1559 transactions
• eth_sendRawTransaction
  • Supports sending RLP encoded EIP-1559 transactions
• eth_getTransactionBy*
  • A returned transaction may include the new fields maxPriorityFeePerGas and maxFeePerGas

The transaction data structure includes two new fields:

• maxPriorityFeePerGas specifies the tip (priority fee) to entice a block producer to include your transaction.
• maxFeePerGas is the maximum fee the user is willing to pay the block producer for including this transaction.

Legacy transactions that only include a gasPrice are still valid and they will be accepted into the blocks. The user will simply pay the entire proposed network fee and as a result they may pay a premium compared to other users on the network.

New transaction receipt format

Impacts the following JSON RPC calls:

• eth_getTransactionReceipt
  A new field ReceiptEffectiveGasPrice is included in a receipt.

The transaction receipt includes a new field:

• ReceiptEffectiveGasPrice is the final gas price per gas paid by the user.

It is recommended to wait a number of confirmations before considering the effective gas price as final. This is because any block re-orgs at the tip of the chain may change its value.

Computing the gas price (network fee)

The following JSON RPC call is considered legacy (deprecated):

• eth_gasPrice: It returns a competitive gas price including a priority fee and the current base fee.
  It is replaced with:
• eth_feeHistory: Returns transaction fee data for up to 1024 blocks. For each block, it includes the base fee, a percentile list of effective priority fees and the ratio of gas used/limit. Note the required base fee for the next block is returned as well.

The new JSON RPC call is designed to provide transaction fee data to allow developers to implement their own fee estimation algorithm. This should be sufficient for most transactions sent on the network. Of course, if the user is participating in a priority gas auction, then they will still be required to use data from the transaction pool.

Simulating transaction execution and the required gas limit.

Impacts the following JSON RPC calls:

• eth_call
  • May require the developer to specify the gas price or new 1559 gas pricing to reflect true execution of a transaction,
• eth_estimateGas
  • May fail to estimate the gas if the gas price or new 1559 gas pricing is not filled in (i.e., greater than 0).

The London Fork implements EIP-3198 which is a new opcode BASEFEE that returns the base fee of the current block it is executing in. It is recommended for developers to explicitly set the gas pricing for both JSON RPC calls to avoid a failed JSON RPC call response.
The geth team have put together a detailed explanation for changes to eth_call and it can be summarised as follows:

• Set no gas price.
  • The transaction will execute assuming the gas price was set to 0.
• Set a gasPrice (pre-1559):
  • It interprets the gas price as the max fee (includes priority tip and base fee).
• Set a gas pricing (post-1559):
  • It is interpreted as expected for the gas pricing.

Our infrastructure is ready

If you’re an Infura user, don’t worry — we’re ready.

Infura has been running reliable Ethereum infrastructure for over four years and we’re adept at handling large-scale updates during network hard forks. We’ll take care of the upgrade so you can continue building great software.

We hope this article will help you prepare your project for the upcoming London fork and to take full advantage of EIP-1559. As always, we’re here to help. If you have any questions about the upgrade, please reach out to the team via our Community page or drop us an email at support@infura.io.