Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). These nodes are real computers in the real world, communicating directly from peer to peer.
The purpose of the greater Ethereum apparatus is to offer a single shared computing platform - the Ethereum Virtual Machine (EVM).
The EVM exists within the nodes that make up the Ethereum network; every computer is running software that has a live copy of the EVM.
A block contains a list of changes within the EVM (transactions). Every node processes every new block, keeping all the EVMs in sync.
Every 12 seconds a new block is created, and so every node must be capable of processing every block (syncing their EVM) in less than 12 seconds.
The more complicated the blocks, the higher the minimum specs (and therefore barriers to entry).
Ethereum expresses these computational requirements with an accounting unit know as gas.
(From the protocol's perspective) gas represents the amount of real-world computer resources each transaction takes to process.
Each block has a gas limit, representing the maximum amount of computation (or other resources, like storing some kinds of data) a node is expected to do every 12 seconds.
And so, the question becomes "how can Ethereum allocate these resources fairly and efficiently?"
The answer depends on when you are asking about: before or after August 2021 (London Hard Fork).
Today, we live under a fee system governed by EIP-1559 - a huge overhaul from the genesis system. But it's worth reviewing what came before.
In the pre-EIP-1559 system, every block had a fixed gas limit of 10MM gas.
Each transaction uses a certain amount of gas; a builder is free to choose whichever pending transactions they want as long as the net gas used by all transactions is less than the limit.
When a user generated a transaction, s/he specified a price they are willing to pay per unit of gas.
This was multiplied by the total gas used by that transaction is the fee offered to the builder as an incentive for including that transaction in the next block.
When a builder built a block, (normally) they would sort all the pending transactions by the total fee and go down the list, filling the block as full as possible.
Then the builder added a transaction, moving all the fees from transactions in that block the proposer.
Now the block is ready for the proposer (possibly the same entity). The proposer digitally signs and broadcasts it to the network.
Each node receives the block and processes every transaction. By the end, every EVM is in sync and the process is ready to begin again.
The old system worked, but its simplicity led to a suboptimal experience for users (imagine bidding significantly more than 2nd place)
The most pressing issue lies in the distinction between two types of auction systems: first-price and uniform-price.
First Price Auction |
Uniform Price Auction |
A type of auction where the winning bidder pays the amount of their final bid, as opposed to second price auctions where the winning bidder pays the amount of the highest unsuccessful bid. This is what we colloquially think of as an auction - you pay what you bid. |
A type of auction in which a fixed number of identical items are sold for an identical price. Bidders place a bid for the quantity they want, indicating what price they are willing to pay for each unit. These bids are concealed from other bidders. Once the auction has ended, the auctioneer assesses the bids made, and decides at which price the total quantity of units on offer should be sold. |
The old fee markets were incredibly inefficient. Per Vitalik Buterin,
The difference between average gasprice and 10th percentile gasprice in a regular block is something like 3x for median and 5-8x for mean. People needlessly overpay massively.
Everyone who does not overpay suffers a delay of 1-2 minutes or even longer, and this delay does not actually benefit anyone; the total load to the chain is the same regardless of whether a given unit of load hits the chain at time N or time N + 60. There is no actual social benefit from participants “expressing a low time preference” in the fee market mechanism, at least under normal conditions; it is pure deadweight loss. We would all be better off if more transactions were just included immediately, which EIP 1559 allows.
There is a lot of nuance under these systems, it's worth digging in to understand the incentive structures that fill up every Ethereum block (before and after EIP-1559).
Here's the best detailed breakdown of the what and why by Ansgar Dietrichs.
But EIP-1559 is even more important than auctions, the system it installed was what enshrined ETH as the asset used to pay fees on Ethereum.
Without EIP-1559, there was no requirement to pay in ETH; in fact some didn't.
Which brings us to the system we have today: the EIP-1559 Fee System.
From the 30k ft view, things look roughly the same. Users create transactions and set fees. Block builders create blocks based on the fees their earn.
But this system is much more powerful.
EIP-1559 splits the fees paid to proposers into two categories: base fees and priority fees.
When generating a transaction, a user now indicates two number: the maximum base fee per unit of gas they are willing to pay, and the tip (priority fee) for the proposer.
Base fees are set by the protocol, fluctuating with demand.
Post EIP-1559, blocks have a variable size. The average block target is 15MM gas, but can increase by up to 2x in periods of high demand.
These two mechanisms work balance Ethereum's computational load.
When lots of people want to use Ethereum, the maximum gas limit increases and creates block space. However, the base fee will also increase.
This increase is exponential and indefinite. Soon it becomes too high for anyone to be willing to pay, and so demand subsides.
Under EIP-1559, the base fee is set once per block; all transactions that set a maximum base fee high enough are eligible for conclusion.
Different transactions may pay different total base fees if they use different amounts of gas, but they pay the same unit cost.
The biggest difference between pre and post EIP-1559 is what happens to the base fee: today, the base fee collected from every transaction is sent to an unrecoverable address - lost forever.
We call this "burning;" it's like they were lit on fire and destroyed.
This is a huge deal - the EIP-1559 burn represents revenue earned by the protocol.
We choose to "destroy" it in order to offset the ETH issued by Proof of Stake to secure Ethereum, but there are plenty of other ways the community could choose to use that revenue.
I cannot overstate just how big the EIP-1559 burn is. Since the move to Proof of Stake (and the drop in ETH issuance), the burn is often larger than issuance, leading to an (often) deflationary ETH.
The other kind of fee that exists post EIP-1559 is the priority fee. This is the fee paid to the block proposer as an incentive to include the transaction in the next block.
As in the previous system, this fee is transferred directly to the proposer within each block.
(Normally) block builders are focused on maximizing the total priority fees possible within the gas limit the protocol gives the for that slot.
Builders don't really care about the base fee, other than how it affects the overall demand (and therefore price).
While this priority fee could feasibly be paid in any asset, the base fee must be paid in ETH, ensuring that ETH retains the extra premium it gains from its role as payment asset for Ethereum.
As an added bonus, the base fee becomes a reliable oracle for gas fees.
That completes the EIP-1559 system. Here are the big takeaways:
But EIP-1559 is not the final state of the Ethereum fee system. In fact, there are already important upgrades being developed by the Etherean magicians.
The EIP-1559 you know today is just he beginning; wait until you see the endgame.
Source Material - Twitter Link