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

Open
vbuterin opened this Issue Nov 6, 2018 · 10 comments

Comments

Projects
None yet
6 participants
@vbuterin
Collaborator

vbuterin commented Nov 6, 2018

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

This comment has been minimized.

Contributor

fulldecent commented Nov 9, 2018

s|//|/|g?

@fulldecent

This comment has been minimized.

Contributor

fulldecent commented Nov 9, 2018

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

This comment has been minimized.

tjayrush commented Nov 9, 2018

I think '//' means integer division.

@vbuterin

This comment has been minimized.

Collaborator

vbuterin commented Nov 10, 2018

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

@alexvandesande

This comment has been minimized.

Contributor

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Contributor

AlexeyAkhunov commented Dec 6, 2018

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Contributor

AlexeyAkhunov commented Dec 16, 2018

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment