Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fee market change for ETH 1.0 chain #1559

Closed
vbuterin opened this issue Nov 6, 2018 · 15 comments
Closed

Fee market change for ETH 1.0 chain #1559

vbuterin opened this issue Nov 6, 2018 · 15 comments

Comments

@vbuterin
Copy link
Contributor

vbuterin commented Nov 6, 2018

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
Copy link
Contributor

s|//|/|g?

@fulldecent
Copy link
Contributor

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
Copy link

tjayrush commented Nov 9, 2018

I think '//' means integer division.

@vbuterin
Copy link
Contributor Author

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

@alexvandesande
Copy link

alexvandesande commented Nov 23, 2018

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
Copy link
Contributor Author

vbuterin commented Nov 23, 2018

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
Copy link
Contributor

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
Copy link
Contributor

Arachnid commented Dec 6, 2018

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
Copy link
Contributor Author

vbuterin commented Dec 8, 2018

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
Copy link
Contributor

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
Copy link

azeroz commented Mar 2, 2019

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

cool

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

11 participants