A transaction pricing mechanism that includes fixed-per-block network fee that is burned and dynamically expands/contracts block sizes to deal with transient congestion.
There is a base fee per gas in protocol, which can move up or down by a maximum of 1/8 in each block. The base fee per gas is adjusted by the protocol to target an average gas usage per block instead of an absolute gas usage per block. The base fee is increased when blocks are over the gas limit target and decreases when blocks are under the gas limit target. The base fee per gas is burned. 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 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.
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**: bids to include transactions on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. On Ethereum, minimum bids range between 1 nanoeth (10^9 nanoeth = 1 ETH), but sometimes go over 100 nanoeth and have reached over 200 nanoeth. 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 200x more when gas prices are 200 nanoeth than when they are 1 nanoeth; 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**: The current approach, where transaction senders publish a transaction with a bid a maximum fee, miners choose the highest-paying transactions, and everyone pays what they bid. This is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required. But even these algorithms often end up not working very well, leading to frequent fee overpayment.
* **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 issues with this that 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. When the network exceeds the target per-block gas usage, the base fee increases slightly and when capacity is below the target, it decreases slightly. Because these base fee changes 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 the base fee will be estimated by their wallet and a small gas premium, which acts as a 'bribe' to compensate miners taking on orphan risk (e.g. 1 nanoeth), will be automatically set. Users can also manually set the transaction fee cap to bound their total costs.
An important aspect of this fee system is that miners only get to keep the gas premium. The base fee is always burned (i.e. it is destroyed by the protocol). Burning this is important because it removes miner incentive to manipulate 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.
*`INITIAL_FORK_BLOCK_NUMBER`: TBD. Block number at or after which EIP-1559 transactions are valid.
*`MIGRATION_DURATION_IN_BLOCKS`: 800,000. Number of blocks the migration period will last, during which time both legacy transactions and EIP-1559 transactions are valid.
*`FINAL_FORK_BLOCK_NUMBER`: `INITIAL_FORK_BLOCK_NUMBER + MIGRATION_DURATION_IN_BLOCKS`. Block number on or after which only EIP-1559 transactions are are valid.
*`BLOCK_GAS_TARGET`: 10th item in the block header: The gas limit field, controlled by miner voting. Previously referred to colloquially as `gas limit`, now referred to as `gas target`. Controlled by miners in the same way as before where each miner can increase or decrease it by a very small amount relative to parent block.
*`CURRENT_BLOCK`: The current block that is being worked with (either being validated, or being produced).
*`EIP1559_INITIAL_GAS_TARGET`: `BLOCK_GAS_TARGET / 2`. The maximum amount of gas that EIP-1559 transactions can use in `INITIAL_FORK_BLOCK_NUMBER`.
*`LEGACY_INITIAL_GAS_LIMIT`: `BLOCK_GAS_TARGET / 2`. The maximum amount of gas that legacy transactions can use in `INITIAL_FORK_BLOCK_NUMBER`.
*`EIP1559_GAS_TARGET`: The target gas used by EIP-1559 transactions in a given block.
*`LEGACY_GAS_LIMIT`: `BLOCK_GAS_TARGET - EIP1559_GAS_TARGET`. The maximum amount of gas legacy transactions can use in a given block.
*`EIP1559_GAS_LIMIT`: `EIP1559_GAS_TARGET * 2`. The maximum amount of gas EIP-1559 transactions can use in a given block.
*`BASE_FEE`: 16th item in the block header. Represents the amount of attoeth burned for every unit of gas a transaction uses.
*`BASE_FEE_MAX_CHANGE_DENOMINATOR`: `8`
*`BASE_FEE_MAX_CHANGE`: `CURRENT_BLOCK.parent.BASE_FEE / BASE_FEE_MAX_CHANGE_DENOMINATOR`. The maximum amount the `BASE_FEE` can change between blocks (either up or down).
*`INITIAL_BASE_FEE` : 0.000000001 ETH (1 nanoeth)
*`BASE_FEE_CHANGE`: `CURRENT_BLOCK.parent.BASE_FEE`. The amount that the BASE_FEE will increase in `CURRENT_BLOCK` relative to `CURRENT_BLOCK.parent`.
### Process
* At `block.number == INITIAL_FORK_BLOCK_NUMBER` we set `BASE_FEE = INITIAL_BASE_FEE`
* Clamp the resulting `BASE_FEE` inside of the allowable bounds if needed, where a valid `BASE_FEE` is one such that `abs(BASE_FEE - PARENT_BASE_FEE) <= max(1, PARENT_BASE_FEE // BASE_FEE_MAX_CHANGE_DENOMINATOR)`
* EIP-1559 transactions are encoded as `rlp([nonce, gasLimit, to, value, data, gasPremium, feeCap, v, r, s])` where `v,r,s` is a signature of `rlp([nonce, gasLimit, to, value, data, gasPremium, feeCap])`.
* During the transition phase, legacy transactions (`rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])`) will continue to be valid and can be included as part of the `LEGACY_GAS_LIMIT` block of transactions.
* To produce an EIP1559 transactions, the new `GAS_PREMIUM` and `FEECAP` fields are set as follows:
* The `block.coinbase` gains `(GASPRICE - BASE_FEE) * GASUSED`.
* If `GASPRICE < BASE_FEE` (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.
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 decreases over this period.
This EIP will increase the maximum block size, which could cause problems if miners are unable to process a block fast enough as it will force them to mine an empty block. Over time, the average block size should remain about the same as without this EIP, so this is only an issue for short term size bursts. It is possible that one or more clients may handle short term size bursts poorly and error (such as out of memory or similar) and client implementations should make sure their clients can appropriately handle individual blocks up to max size.
### Transaction Ordering
With most people not competing on miner fees and instead using a baseline fee to get included, transaction ordering now depends on individual client internal implementation details such as how they store the transactions in memory. It is recommended that transactions with the same miner fee be sorted by time the transaction was received to protect the network from spamming attacks where the attacker throws a bunch of transactions into the pending pool in order to ensure that at least one lands in a favorable position. Miners should still prefer higher tip transactions over lower tip, purely from a selfish mining perspective.
### Miners Mining Empty Blocks
It is possible that miners will mine empty blocks until such time as the base fee is very low and then proceed to mine half full blocks and revert to sorting transactions by the gas premium. While this attack is possible, it is not a particularly stable equilibrium as long as mining is decentralized. Any defector from this strategy will be more profitable than a miner participating in the attack for as long as the attack continues (even after the base fee reached 0). Since any miner can anonymously defect from a cartel, and there is no way to prove that a particular miner defected, the only feasible way to execute this attack would be to control 50% or more of hashing power. If an attacker had exectly 50% of hashing power, they would make no money from gas premium while defectors would make double the money from premiums. For an attacker to turn a profit, they need to have some amount over 50% hashing power, which means they can alternatively execute double spend attacks or simply ignore any other miners which is a far more profitable strategy.
Should a miner attempt to execute this attack, we can simply increase the elasticity multiplier (currently 2x) which requires they have even more hashing power available before the attack can even be theoretically profitable against defectors.
### ETH Burn Precludes Fixed Supply
By burning the base fee, we can no longer guarantee a fixed token supply. This could result in economic instabality as the long term supply of ETH will no longer be constant over time. While a valid concern, it is difficult to quantify how much of an impact this will have. If more is burned on base fee than is generated in mining rewards then ETH will be deflationary and if more is generated in mining rewards than is burned then ETH will be inflationary. Since we cannot control user demand for block space, we cannot assert at the moment whether ETH will end up inflationary or deflationary, so this change causes the core developers to lose some control over Ethereum's long term monetary policy.
* [First and second-price auctions and improved transaction-fee markets](https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410)
* [The Challenges of Bitcoin Transaction Fee Estimation](https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72)
* [On the Instability of Bitcoin Without the Block Reward](http://randomwalker.info/publications/mining_CCS.pdf)
