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), Rick Dudley (@AFDudley), Matthew Slipper (@mslipper), Ian Norden (@i-norden)	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 base fee value in protocol, which can move up or down by a maximum of 1/8 in each block. The base fee value is adjusted by the protocol to target an average gas usage of 10 million, increasing base fee if usage is higher and decreasing it if usage is lower. Transaction senders specify their fees by providing two values:

• A gas premium which gets added onto the base fee to calculate the gas price. The gas premium 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 base fee gets burned, the gas premium is given to the miner.

• A fee cap which represents the maximum total (base fee + gas premium) that the transaction sender would be willing to pay to get their transaction included.

The current miner-voting based gas limit is changed to a hard-coded gas limit of 16 million. Instead of miners directly adjusting the gas limit in response to changes in network demand, the protocol adjusts the base fee to apply economic pressure towards a target gas usage of 10 million.

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 base fee amount which is adjusted up and down by the protocol based on how congested the network is. To accommodate this system, the total network capacity would be increased to 16 million gas. When the network exceeds the target 10 million gas usage, the base fee increments up slightly and when capacity is below the target, it decrements down slightly. Because these increments are constrained, the maximum difference in base fee 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 post 1559 implementation the base fee will be estimated by their wallet and a small gas premium- which acts as a 'tip' to compensate miners (e.g. 0.5 gwei)- will be automatically set. Users can also manually set the transaction fee cap to bound their total costs.

An important aspect of this upgraded fee system is that miners only get to keep the tips. The base fee 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. Additionally, this burn counterbalances Ethereum inflation without greatly diminishing miner rewards.

The transition to this gas price system will occur in two phases, in the first phase both legacy and EIP1559 transactions will be accepted by the protocol. Over the course of this first phase the amount of gas available for processing legacy transactions will decrease while the amount of gas available for processing EIP1559 transactions will increase, moving gas from the legacy pool into the EIP1559 pool until the legacy pool is depleted and the EIP1559 pool contains the entire gas maximum. After all of the gas has transitioned to the EIP1559 pool, the second- finalized- phase is entered and legacy transactions will no longer be accepted on the network.

Specification

Parameters

• INITIAL_FORK_BLKNUM: TBD
• MIGRATION_DURATION_IN_BLOCKS: 800,000
• FINAL_FORK_BLKNUM: INITIAL_FORK_BLKNUM + MIGRATION_DURATION_IN_BLOCKS
• EIP1559_INITIAL_GAS_TARGET: BLOCK_GAS_TARGET / 2
• LEGACY_INITIAL_GAS_LIMIT: BLOCK_GAS_TARGET - EIP1559_GAS_TARGET
• EIP1559_GAS_TARGET:

  if CURRENT_BLKNUM >= FINAL_FORK_BLOKNUM then
    BLOCK_GAS_TARGET
  elif CURRNT_BLKNUM < INITIAL_FORK_BLKNUM then
    0
  else
    EIP1559_INITIAL_GAS_TARGET + LEGACY_INITIAL_GAS_LIMIT * (CURRENT_BLKNUM - INITIAL_FORK_BLKNUM) / MIGRATION_DURATION_IN_BLOCKS
  

• LEGACY_GAS_LIMIT: BLOCK_GAS_TARGET - EIP1559_GAS_TARGET
• EIP1559_GAS_LIMIT: EIP1559_GAS_TARGET * 2
• BASEFEE_MAX_CHANGE_DENOMINATOR: 8
• INITIAL_BASEFEE : 1,000,000,000 wei (1 gwei)

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

For the gas limit:

• The field in the block header previously referred to as GASLIMIT will now be referred to colloquially as GAS_TARGET. Its value will still be controlled by miners in the same way as previously. It represents the total gas available to the legacy gas pool as well as the target gas of the EIP1559 gas pool.
• EIP1559_GAS_LIMIT is the space available for EIP1559 transactions (EIP1559 gas pool) and it is a function of BLOCK_GAS_TARGET and blocks since INITIAL_FORK_BLKNUM. It becomes equal to BLOCK_GAS_TARGET * 2 for blocks >= FINAL_FORK_BLKNUM
• The gas limit for the legacy gas pool is BLOCK_GAS_TARGET - EIP1559_GAS_TARGET. As EIP1559_GAS_TARGET increases towards BLOCK_GAS_TARGET, gas is moved from the legacy pool into the EIP1559 pool until all of the gas is in the EIP1559 pool
• At block.number == INITIAL_FORK_BLKNUM, let EIP1559_GAS_LIMIT = (GASLIMIT / 2) so that the gas maximum is split evenly between the legacy and EIP1559 gas pools
• As block.number increases towards FINAL_FORK_BLKNUM, at every block we shift 1/MIGRATION_DURATION_IN_BLOCKS gas from the legacy pool into the EIP1559 gas pool (effectively doubling it as it moves, since the EIP1559 gas target is half of the limit)
• At block.number >= FINAL_FORK_BLKNUM the entire BLOCK_GAS_TARGET is assigned to the EIP1559 gas pool and the legacy pool is 0

For the gas price:

• We add a new field to the block header, BASEFEE
  • BASEFEE is maintained under consensus by the ethash engine
• At block.number == INITIAL_FORK_BLKNUM we set BASEFEE = INITIAL_BASEFEE
• BASEFEE is set as follows
  • Let delta = block.gas_used - TARGET_GASUSED (possibly negative).
  • Set BASEFEE = PARENT_BASEFEE + PARENT_BASEFEE * delta // TARGET_GASUSED // BASEFEE_MAX_CHANGE_DENOMINATOR
  • Clamp the resulting BASEFEE inside of the allowable bounds if needed, where a valid BASEFEE is one such that abs(BASEFEE - PARENT_BASEFEE) <= max(1, PARENT_BASEFEE // BASEFEE_MAX_CHANGE_DENOMINATOR)
• We add two new fields to transactions: GAS_PREMIUM and FEECAP
• During the transition phase, these fields can be left nil and a tx.gas_price can be set as usual to generate a backwards compatible legacy transaction
• To produce an EIP1559 transactions, tx.gas_price is set to nil while the new GAS_PREMIUM and FEECAP fields are set whereby:
  • GAS_PREMIUM serves as a "tip" to the miner
  • FEECAP serves as the absolute maximum that the transaction sender is willing to pay
• During transaction execution, for EIP1559 transactions we calculate the cost to the tx.origin and the gain to the block.coinbase as follows:
  • Set GASPRICE = min(BASEFEE + tx.GasPremium, tx.fee_cap)
  • Let GASUSED be the gas used during the transaction execution/state transition
  • 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 FEECAP), this means that the block.coinbase loses funds from this operation; in this case, we check that the post-balance is non-negative and throw an exception if it is negative.

Backwards Compatibility

We split the EIP1559 upgrade into two phases with a transition period during which both legacy and EIP1559 transaction can be accepted so that compatibility with wallets and other ETH-adjacent software is maintained while their maintainers have time to upgrade to using the new transaction type. During this transition period legacy transactions are accepted and processed identically to the current implementation, with the only difference being that the amount of gas (gas limit) dedicated to processing legacy transactions is calculated as above and incrementally decreases over this period.

Test Cases

Implementation

Go-ethereum implementation by Vulcanize Inc: https://github.com/vulcanize/go-ethereum-EIP1559

Security Considerations

The security considerations for this EIP are:

1. The consequences of raising the gas limit
   • This concern was brought up here
   • This EIP currently proposes to raise the total gas limit from 8,000,000 to 16,000,000
2. The consequences of the new gas pricing on total transaction order
   • This concern was brought up here
   • This issue is avoided by maintaining a single total ordering of transactions by price and nonce, where the derived EIP1559 gas price is used like the legacy gas price
3. The effects on miner incentives
   • This concern was brought up here
   • This concern is addressed here
4. Concerns of BASEFEE manipulation
   • This concern was brought up here
   • To avoid this, the BASEFEE is included as part of the header structure and is maintained under consensus by the ethash engine
5. Implications of BASEFEE burning on proposals to cap the total ether supply (e.g. EIP-960).
   • This concern was brought up here

Resources

• Call notes
• Original Magicians thread
• Ethresear.ch Post w/ Vitalik’s Paper
• Go-ethereum implementation
• Implementation-specific Magicians thread

Copyright

Copyright and related rights waived via CC0.