Fee market change for ETH 1.0 chain

[vbuterin]

The final standard can be found here: https://eips.ethereum.org/EIPS/eip-1559

---

Motivation

Provide a concrete proposal for implementing the fee market proposed in https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838 on the current 1.0 chain.

See zcash/zcash#3473 for more detailed arguments for why this is a good idea.

Parameters

• FORK_BLKNUM: TBD
• MINFEE_MAX_CHANGE_DENOMINATOR: 8
• TARGET_GASUSED: 8000000

Proposal

For all blocks where block.number >= FORK_BLKNUM:

• Impose a hard in-protocol gas limit of 16 million, used instead of the gas limit calculated using the previously existing formulas
• Replace the GASLIMIT field in the block header with a MINFEE field (the same field can be used)
• Let PARENT_MINFEE be the parent block's MINFEE (or 1 billion wei if block.number == FORK_BLKNUM). A valid MINFEE is one such that abs(MINFEE - PARENT_MINFEE) <= max(1, PARENT_MINFEE // MINFEE_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(MINFEE + tx.fee_premium, tx.cap). The tx.origin initially pays gasprice * tx.gas, and gets refunded gasprice * (tx.gas - gasused).
  • The block.coinbase gains (gasprice - MINFEE) * gasused.

As a default strategy, miners set MINFEE as follows. Let delta = block.gas_used - TARGET_GASUSED (possibly negative). Set MINFEE = PARENT_MINFEE + PARENT_MINFEE * delta // TARGET_GASUSED // MINFEE_MAX_CHANGE_DENOMINATOR, clamping this result inside of the allowable bounds if needed (with the parameter setting above clamping will not be required).

Further explanation

There is a MINFEE 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 MINFEE if usage is higher and decreasing it if usage is lower. Transaction senders specify their fees by providing two values:

1. A "premium" gasprice which gets added onto the MINFEE 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 MINFEE gets burned, the premium is given to the miner.
2. A "cap" which represents the maximum total that the transaction sender would be willing to pay to get included.

Ultra-short-term volatility in transaction demand or block times will now translate mostly into ultra-short-term volatility in block sizes instead of volatility in transaction fees. During normal conditions, fee estimation becomes extremely simple: just set the premium to some specific value, eg. 1 gwei, and select a high cap. If a transaction sender highly values urgency during conditions of congestion, they are free to instead set a much higher premium and effectively bid in the traditional first-price-auction style.

[fulldecent]

s|//|/|g?

[fulldecent]

Regarding ethpricing.pdf and your notes on time-value of storage. Please consider this concrete implementation of a solution: #1418. This implements lazy evaluation and does not require pokes.

[tjayrush]

I think '//' means integer division.

[vbuterin]

This proposal is completely separate from storage maintenance fees; it's purely about gas as it exists within the current 1.0 chain.

[alexvandesande]

In every block, a miner gets a reward equal to 1/N (eg. 1/10000) of the money remaining in the pot (note that this amount does NOT depend on the transactions they include in their block).

Doesn't this creates an incentive to mine empty blocks? Since the miner gets only a 1/1000 of the current transaction fees, and instead they go to a public commons, while a naive miner is incentivized to put as much as possible in the pot so they can get more in the future, a selfish miner could decide to save computation time by ignoring all transactions. They still get the fee and it's the next miner that will get penalized for his actions. Of course, it's a prisoner's dilemma: if all miners refuse transactions it's worse for everyone, but if others cooperate and you refuse, then you get rewarded.

[vbuterin]

Doesn't this creates an incentive to mine empty blocks?

Ah sorry, I did not mean to say that the incentive to include transactions is literally zero. The tx.fee_premium component still goes 100% to the miner. It's up to the market to determine how much of a premium is incentive enough, but the key point is that the value that we can expect to be a sufficient incentive can be expected to be roughly constant over time, and not change block by block with changing levels of congestion/demand or even just bad luck of the Poisson process.

[AlexeyAkhunov]

What do you think about introducing smoothing (aggregating gasused over multiple blocks) and some lag (aggregating over past blocks rather than very recent blocks)? Smoothing would increase the price of manipulation, and lag would make MINFEE more predictable (for better usability)

[Arachnid]

Anyone wanting to tweak the parameters on something like this would be well advised to read Feedback Control for Computer Systems.

I think this will need some simulation to determine the correct parameters.

[vbuterin]

What do you think about introducing smoothing (aggregating gasused over multiple blocks)

There is already implicit smoothing because each block only moves the fee by a relatively small amount.

and some lag (aggregating over past blocks rather than very recent blocks)? Smoothing would increase the price of manipulation, and lag would make MINFEE more predictable (for better usability)

That's definitely interesting! I guess the goal would be to make MINFEE predictable N blocks in advance instead of just one? Certainly doable though it would add complexity.

[AlexeyAkhunov]

Anyone wanting to tweak the parameters on something like this would be well advised to read Feedback Control for Computer Systems.

I am getting this book tomorrow :)

[azeroz]

Anyone wanting to tweak the parameters on something like this would be well advised to read Feedback Control for Computer Systems.

I think this will need some simulation to determine the correct parameters.

Are you kidding, this has to be a horrible book for Feedback or Control Theory.

Is this the principal forum for discussion on these matters?

[fubuloubu]

What do you think about introducing smoothing (aggregating gasused over multiple blocks) and some lag (aggregating over past blocks rather than very recent blocks)? Smoothing would increase the price of manipulation, and lag would make MINFEE more predictable (for better usability)

I think an applications of Controls Theory concepts is very interesting here. In order for it to work though, you have to identify a few things in the system: what are we optimizing for? what are our "control variables" (things we can control in the protocol)? what are our sensory inputs we can read (things we can observe)? how do we want to model the system we are controlling (the "plant")?

There are tons of very interesting things that can be done, very simply and very effectively (especially since we have a TON of data to analyze about the current system), but applying controls theory works best when you go through the exercise of defining the system in the framework.

It might be good to start by modeling the existing system using a Controls Theory model (State Space or "classical")

[fubuloubu]

Is this the principal forum for discussion on these matters?

I vote we move discussion to https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783

It's a better forum for these types of discussions

[nicksavers]

Closed now that the EIP is specified here
https://eips.ethereum.org/EIPS/eip-1559

and the discussion-thread is here
https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783

[aliyifei]

cool