(1/30) @ethereum basics: Fee Systems, Before and After EIP-1559
Ethereum is limited by the hardware & bandwidth of its nodes; fee systems work to fairly distribute these resources to any interested in using the World Computer
The original, and the what, why and wow of EIP-1559
(2/30) More of a long-form reader? No problem!
Check out this same article at its permanent home on my website, Inevitable Ethereum!
inevitableeth.com/en/home/ethereum/network/consensus/eip-1559
(3/30) @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.
inevitableeth.com/home/ethereum/world-computer
(4/30) The purpose of the greater @ethereum apparatus is to offer a single shared computing platform - the Ethereum Virtual Machine (EVM).
The EVM provides the context for transactions (computation); everything you "do" on-chain happens within the EVM.
inevitableeth.com/en/home/ethereum/evm
(5/30) 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.
(6/30) 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).
inevitableeth.com/home/ethereum/network/consensus/time
(7/30) @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.
inevitableeth.com/home/concepts/gas
(8/30) 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?"
(9/30) 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.
inevitableeth.com/en/home/ethereum/history
(10/30) 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.
(11/30) 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.
(12/30) 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.
(13/30) 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.
(14/30) 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.
Summary below.
(15/30) The old fee markets were incredibly inefficient. Per @VitalikButerin, "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."
notes.ethereum.org/@vbuterin/eip-1559-faq
(16/30) 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 @adietrichs.
hackmd.io/@adietrichs/eip-1559
(17/30) 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... right, @TimBeiko?
ethereum-magicians.org/t/transactions-without-gas/6064
(18/30) 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.
(19/30) 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.
(20/30) 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.
(21/30) 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.
(22/30) 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.
(23/30) 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.
(24/30) 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.
(25/30) I cannot overstate just how big the EIP-1559 burn is - @drakefjustin would never forgive me.
Since the move to Proof of Stake (and the drop in $ETH issuance), the burn is often larger than issuance.
I'll let @ultrasoundmoney fill you in.
š¦š
ultrasound.money/
(26/30) 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.
(27/30) (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).
(28/30) 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.
(29/30) That completes the EIP-1559 system. Here are the big takeaways:
- block size is flexible up to 2x, but targets a 15MM gas limit
- base fee, set by the protocol, scales with block space demand
- together both block size and base fee control demand
- base fee is burned
(30/30) 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.