Closed vbuterin closed 5 years ago
s|//|/|g
?
Regarding ethpricing.pdf and your notes on time-value of storage. Please consider this concrete implementation of a solution: https://github.com/ethereum/EIPs/issues/1418. This implements lazy evaluation and does not require pokes.
I think '//' means integer division.
This proposal is completely separate from storage maintenance fees; it's purely about gas as it exists within the current 1.0 chain.
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.
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.
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)
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.
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.
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 :)
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?
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")
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
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
cool
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 https://github.com/zcash/zcash/issues/3473 for more detailed arguments for why this is a good idea.
Parameters
FORK_BLKNUM
: TBDMINFEE_MAX_CHANGE_DENOMINATOR
: 8TARGET_GASUSED
: 8000000Proposal
For all blocks where
block.number >= FORK_BLKNUM
:GASLIMIT
field in the block header with aMINFEE
field (the same field can be used)PARENT_MINFEE
be the parent block'sMINFEE
(or 1 billion wei ifblock.number == FORK_BLKNUM
). A validMINFEE
is one such thatabs(MINFEE - PARENT_MINFEE) <= max(1, PARENT_MINFEE // MINFEE_MAX_CHANGE_DENOMINATOR)
tx.gasprice
field is used: definetx.fee_premium = tx.gasprice // 2**128
andtx.fee_cap = tx.gasprice % 2**128
tx.origin
and the gain to theblock.coinbase
as follows:gasprice = min(MINFEE + tx.fee_premium, tx.cap)
. Thetx.origin
initially paysgasprice * tx.gas
, and gets refundedgasprice * (tx.gas - gasused)
.block.coinbase
gains(gasprice - MINFEE) * gasused
.As a default strategy, miners set
MINFEE
as follows. Letdelta = block.gas_used - TARGET_GASUSED
(possibly negative). SetMINFEE = 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:
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.