London Hard Fork Analysis

Aug 12, 2021

London Hard Fork / EIP-1559 Analysis

As of August 5th 2021, Ethereum’s London hard Fork has officially gone live! Read on for a brief overview of what’s in EIP-1559, or skip down to the analysis section to see how it’s impacting the Ethereum mainnet.


The most important feature of the London Hard Fork is that it enables EIP-1559 which fundamentally changes the gas mechanics of Ethereum. Changing the gas mechanics impacts everyone, changing what Ethereum users pay to transact and what Ethereum miners are paid to mine.

Wait, what’s gas?

Ethereum has always had the concept of transaction gas which prevents users from abusing the network. Since full Ethereum nodes must execute all transactions, and transactions may contain arbitrary logic, without gas malicious users could waste the network’s time by performing complex pointless operations which clog the network. Further, even for legitimate transactions, the value of the gas paid is used to help prioritize which transactions are included into a block, establishing a market equilibrium between the value of transactions to users and the cost paid in gas.

What’s changed?

Prior to the London Hard Fork, Ethereum had a hard limit of 15 million gas per block, and Ethereum miners (those solving Ethereum’s cryptographic hash puzzle and generating new blocks) were rewarded with all of the fees charged for gas in the mined block. Blocks were consistently full, and at times of high demand, gas prices could soar by orders of magnitude. These soaring gas prices did little to aleviate congestion, and addressing this deficiency was one of the primary targets of EIP-1559.

EIP-1559 splits the gas fee into two pieces. The first, the ‘base fee’ is set algorithmically per block derived from properties of the previous blocks. The second, is the ‘tip’ given to miners as an incentive to include the transaction with a higher priority. The Ether used to pay the base fee is burnt, while the Ether from the ‘tip’ is given to miners.

Side Note: It’s not quite as simple as looking at the tip to determine what miners are paid. Described in EIP-1559 is the ‘effective gas tip’, which can be less than the specified tip where some of the tip is burnt if the user’s specified max fee does not cover both the base fee and tip.

It is the burning of the base fee which has attracted so much attention for EIP-1559, because introduces a new deflationary mechanic into Ethereum.

Additionally, the 15 million hard gas limit has gone away, and the gas limit, and base fee are now linked, allowing for blocks to become significantly larger and accomodate more transactions for short periods of time. Maintaining larger blocks for any duration rapidly becomes economically prohibitive.

First, we’ll take a look at the impacts of burning the base fee, and next, we’ll take a look at how the new gas mechanics is influcencing the composition of new Ethereum blocks.


The charts below are being generated based on data collected from the Unbounded Network. They contain data from August 1st 2021, through today’s date, and can be regenerated simply by executing this notebook. This post will be periodically updated to reflect the most up to date data available.


The burn!

Let’s take a look at just how much Ether is being burnt per block, and what that translates to in terms of dollars.


To generate these charts, we compute two things for each block:

  1. The total gas fees burnt in Ether as the base price of the block multiplied by the total gas used in that block.
  2. The total gas fees paid to miners in Ether as the sum of the ‘Effective Gas Price’ for all transactions.

Then, we sum up these values for each hour and multiply each by the average volume weighted price for Ether for USD pegged stablecoins across different decentralized exchanges. This computation gives us value burnt and paid to miners each in USD.


Although it’s fairly clear that most fees are now burnt in the first charts, we can see here that on average, miners are making only about 20% of the gas fees that they used to make. But before feeling too bad for the miners, let’s take a look at what EIP-1559 has done for mining revenue in terms of raw dollars (since the deflationary nature of EIP-1559 seems to have triggered a bull run on Ether).


Computed above is the miner income in terms of Ether (including transaction fees and block rewards both base and uncles) multiplied by the hourly average price for Ether in terms of USD. So, as we can see, despite the decrease in transaction fees, Miners have actually seen steady to increasing revenues.

So it’s deflationary?

Not so fast. EIP-1559 triggers a deflationary mechanic, and as you can see above, there’s a huge value of Ether that’s now being burnt daily, but transaction fees are only half of the picture. In addition to the transaction fees, miners are rewarded with 2 Ether for each block, plus possible uncle fractional rewards. These block rewards have always dwarfed the transaction fees, and will continue to be an inflationary force.


The above chart may look awfully scary for anyone holding Ether, but, it’s important to remember that the creation of Ether is capped at 2 Ether for the base block reward (plus up to two more fractions of that 2 Ether for possible uncles, though uncles are not the common case), so over time, newer blocks contribute a proportionally smaller amount of inflation. With the overall supply of Ether standing at 117 million (at the time of this writing), the annual minting of Ether has kept the inflation rate at around 5% and falling.


The above plot assumes a starting supply of 117mm Ether, and computes the annualized rate of inflation over a 4 hour window accounting for the creation of new Ether as block rewards (primary and uncles). Despite not turning Ether truly deflationary, it does illustrate that the burn associated with EIP-1559 is impacting the inflation rate in a meaningful way.

Beyond the burn

As we mentioned in the introduction, the new base fee burn mechanics have dominated the news with respect to EIP-1559, but that’s not the only significant change introduced by EIP-1559. There’s also the block composition changes. The Friday after the London Fork went live, Vitalik sent out this tweet showing how full blocks are relative to the research predictions, and we thought it would be interesting to try to reproduce Vitalik’s plot and see if we could find any additional insights.

So, without further ado, let’s recreate Vitalik’s chart.


Great! So now we’ve reproduced Vitalik’s original chart, and we know our interpretation of block utilization matches what Vitalik was describing. To generate it, we computed the block utilization for each block by dividing the total gas used in each block by its gas limit. Then, we split those utilizations into 50 equal buckets (between 0% and 100% utilization) and plotted the resulting histogram you see above.

So, can we do better? We know that historically Ethereum blocks have been pretty full, but, how full? Is the set of blocks Vitalik picked typical, or is this distribution stable?

To give us a bit more insight, we’ve recomputed the the block utilization, broken into buckets (note, not uniformly distributed as before), and sampled the distribution each hour.

The result is fairly obvious and striking. Prior the London Hard Fork, almost every block was between 99% and 100% full. Those blocks which were less full were almost always still at least 90% full. Immediately after the hard fork, we see the distribution drastically change. Just like in Vitalik’s plot, we see that many (though not most) blocks are almost entirely full (99%-100%), but it’s clearer than the previous plot, that partially full blocks are actually the common case. About half of the blocks are less than 50% utilized, and half are more than 50% utilized. The fact that there is routinely space available in blocks means that a user knows that if they pay the computed transaction fee, there’s a strong likelihood that their transaction will get into a block.

But wait, if blocks are no longer near full, then we must be wasting capacity on the network, leading to an overall drop in throughput, that’s bad right?