EIP-1559 Fee market reform (introduction of the base fee) (Fee market change for ETH 1.0 chain)
Final · Fees & gas · EIP status Final · created 2019-04-13
Replaces the auction-determined transaction fee with a base fee that the protocol computes per block, which is then burned. Block size can also grow up to twice the target in response to demand.
Why it is needed
Previously, Ethereum set fees through a simple auction in which users bid a gas price directly and miners included the highest bids first. This approach had four problems. First, fees swung by a factor of ten even though the actual marginal cost of including one more transaction barely changed. Second, because block size was fixed, transactions could wait through multiple blocks whenever demand spiked briefly. Third, a first price auction, where you pay exactly what you bid, is highly inefficient, requiring complex fee estimation algorithms that still frequently led to overpayment. Fourth, it is known that a blockchain with no issuance becomes unstable if miners are compensated solely through fees. This proposal lets the protocol raise or lower the base fee gradually based on network congestion, so wallets can set fees automatically and reliably.
What changes
Today
- Users bid a gas price directly to compete, and pay the full amount they bid
- Fees are hard to predict, so overpayment happens frequently
- Because block size is fixed, transactions wait through multiple blocks when demand spikes
- The entire fee goes to the miner
After EIP-1559
- The protocol sets a base fee per block, and wallets adjust to it automatically
- The base fee's change between blocks is capped, making it predictable
- Blocks can grow up to twice the target gas usage, absorbing demand spikes
- The base fee is burned, and miners receive only the priority fee
Who is affected
- Users: Wallets estimate and set the base fee automatically, so users rarely need to adjust fees by hand even during congestion. A max fee can also be set to cap total cost.
- Wallet & app developers: Requires support for the new type 2 transaction format and a switch from auction-based fee estimation logic to one based on the base fee. The header structure used to compute the block hash also gains an additional field.
- Miners (block producers): They do not receive the base fee, only the priority fee and the block reward. The incentive to manipulate the base fee upward to raise it disappears.
- Client teams: Because the maximum block size increases, clients must be able to process maximum-size blocks without errors such as running out of memory.
In depth
Type 2 transaction format and signature
Starting at FORK_BLOCK_NUMBER, EIP-2718 TransactionType 2 is introduced. The TransactionPayload is rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s]), and the full format is 0x02 || rlp([...]). The signature is a secp256k1 signature over keccak256(0x02 || rlp([the 9 items excluding the signature])). The intrinsic cost, carried over from EIP-2930, is 21000 + 16 * nonzero calldata bytes + 4 * zero calldata bytes + 1900 * number of access list storage keys + 2400 * number of access list addresses. The ReceiptPayload is rlp([status, cumulative_transaction_gas_used, logs_bloom, logs]).
Base fee adjustment formula
A base_fee_per_gas field is added to the block header. The gas target is the block gas limit divided by ELASTICITY_MULTIPLIER (2). If the parent block's gas usage equals the target, the base fee stays the same; if it exceeds the target, the base fee rises by parent_base_fee_per_gas * gas_used_delta // parent_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR (8), with a minimum increase of 1; if it falls short of the target, it falls by the same formula. At the fork block, the base fee starts at INITIAL_BASE_FEE (1000000000), and the gas target uses the parent's gas_limit directly so it is not unfairly halved. The per-block change in the block gas limit is capped to less than 1/1024 of the parent's limit, with a minimum limit of 5000.
Fee settlement and burning
A valid transaction must satisfy max_fee_per_gas >= block.base_fee_per_gas and max_fee_per_gas >= max_priority_fee_per_gas, and the signer's balance must be at least gas_limit * max_fee_per_gas. The actual tip is set as priority_fee_per_gas = min(max_priority_fee_per_gas, max_fee_per_gas - block.base_fee_per_gas), and the price per unit of gas the user pays is effective_gas_price = priority_fee_per_gas + block.base_fee_per_gas. Unused gas is refunded based on effective_gas_price. The block producer receives only gas_used * priority_fee_per_gas, and the base fee portion goes to no one and is burned. Denying producers the base fee removes the incentive to manipulate the base fee upward to collect more.
The GASPRICE opcode and changes to the block hash
The GASPRICE (0x3a) opcode must return effective_gas_price. Previously this value simultaneously meant both the ETH per gas the signer pays and the ETH per gas the miner receives, but after this change it refers only to the amount the signer pays, and the amount the miner actually receives can no longer be read directly within the EVM. Also, one field (base_fee_per_gas) is added to the data structure used in computing the block hash, so applications that assemble headers from their components must add the new field at the end. Cases that hash the header bytes directly continue to work unchanged.
Legacy transaction compatibility
Transactions in the old format continue to work and are still included in blocks. During processing, gas_price is normalized into both max_fee_per_gas and max_priority_fee_per_gas. As a result, a legacy transaction's gas_price is entirely consumed by the base fee and the tip, and it does not directly benefit from the advantages of the new pricing scheme (setting a total cost cap and the tip separately). EIP-2930 type 1 transactions have their gas_price normalized into the two fields in the same way.
Security considerations
Because the maximum block size grows, clients need to reliably handle short term bursts of larger blocks. The source expects the average block size to stay similar to before over the long run. Transaction ordering becomes more dependent on client internal implementation since tip competition decreases, but to prevent spam attacks, sorting by arrival time when tips are equal is recommended. A collusion attack in which miners mine empty blocks to drive down the base fee is analyzed as impractical, since defectors gain more by not participating, requiring over 50% of hashpower to be theoretically profitable, at which point double spending would be more profitable anyway. If such an attack is attempted, raising the elasticity multiplier (currently 2x) is also a possible response. In addition, burning the base fee means ETH supply can no longer be guaranteed to stay fixed, and depending on the amount burned versus the size of mining rewards, the result could be deflationary or inflationary.