EIPs/EIPS/eip-1559.md

eip	title	author	discussions-to	status	type	category	created
1559	Fee market change for ETH 1.0 chain	Vitalik Buterin (@vbuterin), Eric Conner (@econoar)	https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783	Draft	Standards Track	Core	2019-04-13

Simple Summary

The current "first price auction" fee model in Ethereum is inefficient and needlessly costly to users. This EIP proposes a way to replace this with a mechanism that adjusts a base network fee based on network demand, creating better fee price efficiency and reducing the complexity of client software needed to avoid paying unnecessarily high fees.

Abstract

There is a BASEFEE value in protocol, which can move up or down by a maximum of 1/8 in each block; initially, miners adjust this value to target an average gas usage of 8 million, increasing BASEFEE if usage is higher and decreasing it if usage is lower. Transaction senders specify their fees by providing two values:

• A "premium" gasprice which gets added onto the BASEFEE gasprice, which can either be set to a fairly low value (eg. 1 gwei) to compensate miners for uncle rate risk or to a high value to compete during sudden bursts of activity. The BASEFEE gets burned, the premium is given to the miner.

• A "cap" which represents the maximum total that the transaction sender would be willing to pay to get included.

Motivation

Ethereum currently prices transaction fees using a simple auction mechanism, where users send transactions with bids ("gasprices") and miners choose transactions with the highest bids, and transactions that get included pay the bid that they specify. This leads to several large sources of inefficiency:

• Mismatch between volatility of transaction fee levels and social cost of transactions: transaction fees on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. On Ethereum, minimum fees are typically around 2 gwei (10^9 gwei = 1 ETH), but sometimes go up to 20-50 gwei and have even on one occasion gone up to over 200 gwei: https://etherscan.io/chart/gasprice. This clearly creates many inefficiencies, because it's absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 100x more when gas prices are 200 gwei than when they are 2 gwei; in both cases, it's a difference between 8 million gas and 8.02 million gas.
• Needless delays for users: because of the hard per-block gas limit coupled with natural volatility in transaction volume, transactions often wait for several blocks before getting included, but this is socially unproductive; no one significantly gains from the fact that there is no "slack" mechanism that allows one block to be bigger and the next block to be smaller to meet block-by-block differences in demand.
• Inefficiencies of first price auctions: see https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 for a detailed writeup. In short, the current approach, where transaction senders publish a transaction with a fee, miners choose the highest-paying transactions, and everyone pays what they bid, is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required, and even these algorithms often end up not working very well, leading to frequent fee overpayment. See also https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 for a Bitcoin core developer's description of the challenges involved in fee estimation in the status quo.
• Instability of blockchains with no block reward: in the long run, blockchains where there is no issuance (including Bitcoin and Zcash) at present intend to switch to rewarding miners entirely through transaction fees. However, there are known results showing that this likely leads to a lot of instability, incentivizing mining "sister blocks" that steal transaction fees, opening up much stronger selfish mining attack vectors, and more. There is at present no good mitigation for this.

The proposal in this EIP is to start with a BASEFEE amount which is adjusted up and down by the protocol based on how congested the network is. To accommodate this system, the network capacity would be increased to 16 million gas, so that 50% utilization matches up with our current 8 million gas limit. Then, when the network is at >50% capacity, the BASEFEE increments up slightly and when capacity is at <50%, it decrements down slightly. Because these increments are constrained, the maximum difference in BASEFEE from block to block is predictable. This then allows wallets to auto-set the gas fees for users in a highly reliable fashion. It is expected that most users will not have to manually adjust gas fees, even in periods of high network activity. For most users, the BASEFEE will be automatically set by their wallet, along with the addition of a small fixed amount, called a ‘tip’, to compensate miners (e.g. 0.5 gwei).

An important aspect of this upgraded fee system is that miners only get to keep the tips. The BASEFEE is always burned (i.e. it is destroyed by the protocol). Burning this is important because it prevents miners from manipulating the fee in order to extract more fees from users. It also ensures that only ETH can ever be used to pay for transactions on Ethereum, cementing the economic value of ETH within the Ethereum platform.

Specification

Parameters

• FORK_BLKNUM: TBD
• BASEFEE_MAX_CHANGE_DENOMINATOR: 8
• SLACK_COEFFICIENT: 3
• TARGET_GASUSED: 8,000,000

Proposal For all blocks where block.number >= FORK_BLKNUM:

• Impose a hard in-protocol gas limit of SLACK_COEFFICIENT * TARGET_GASUSED, used instead of the gas limit calculated using the previously existing formulas
• Replace the GASLIMIT field in the block header with a BASEFEE field (the same field can be used)
• Let PARENT_BASEFEE be the parent block's BASEFEE (or 1 billion wei if block.number == FORK_BLKNUM). A valid BASEFEE is one such that abs(BASEFEE - PARENT_BASEFEE) <= max(1, PARENT_BASEFEE // BASEFEE_MAX_CHANGE_DENOMINATOR)
• Redefine the way the tx.gasprice field is used: define tx.fee_premium = tx.gasprice // 2**128 and tx.fee_cap = tx.gasprice % 2**128
• During transaction execution, we calculate the cost to the tx.origin and the gain to the block.coinbase as follows:
  • Let gasprice = min(BASEFEE + tx.fee_premium, tx.fee_cap). The tx.origin initially pays gasprice * tx.gas, and gets refunded gasprice * (tx.gas - gasused).
  • The block.coinbase gains (gasprice - BASEFEE) * gasused. If gasprice < BASEFEE (due to the fee_cap), this means that the block.coinbase loses funds from this operation; in this case, check that the post-balance is non-negative and throw an exception if it is negative. As a default strategy, miners set BASEFEE as follows. Let delta = block.gas_used - TARGET_GASUSED (possibly negative). Set BASEFEE = PARENT_BASEFEE + PARENT_BASEFEE * delta // TARGET_GASUSED // BASEFEE_MAX_CHANGE_DENOMINATOR, clamping this result inside of the allowable bounds if needed (with the parameter setting above clamping will not be required).

Backwards Compatibility

Transactions published before this EIP or by wallets that do not support this EIP will be interpreted by the above formulas as having a fee_premium of zero and a fee_cap of the fee that they submit. Provided that at least some miners are temporarily willing to be altruistic and accept zero-fee-premium transactions for a short period of time after the fork, this should not greatly affect usability. There is an invariant that a gasprice constructed "the old way" still constitutes an upper bound on the amount that a user will pay.

Test Cases

Implementation

Copyright

Copyright and related rights waived via CC0.