If the transactions included end up optimizing for the “tip” added to a transaction, then how have we not re-created the existing fee market, but worse because of this burning requirement?
Currently, a miner has two reasons NOT to include a transaction:
- Opportunity cost (ie. other transactions)
- Increased uncle rate risk
(2) is predictable, (1) is unpredictable. This proposal brings (1) out of the equation, so we should expect miners to be satisfied by a constant level of tip even as basefee fluctuates.
will result in anything but the miners becoming reluctant to include transactions.
We can actually calculate the size of this the marginal uncle rate risk (ie. increase in change your block becomes an uncle from including an additional 1 million gas in a block).
The thing we would do before is run a linear regression of gas usage vs uncle rate data here to see what the marginal risk of being uncled is if you add more than 1 million gas. Unfortunately, this is temporarily complicated because we recently upgraded network block propagation, and there’s still relatively little data post-change. So what we can do is use the formula U = (k1 + k2 * G) / T where U is uncle rate, T is block time and G is gas usage of a block (see Decker and Wattenhofer 2013 for some of the arguments that lead to this). We have a natural experiment in Constantinople bringing T down, so we can use block, uncle and gas usage before and after the fork. Before we had 220 uncles and 4200 blocks per day, so U_pre = 0.0523, after we have 500 uncles and 6400 blocks per day, so U_post = 0.078. Block time = 86400 / blocks per day, so we get T_pre = 20.57 and T_post = 13.5. G_pre = 7.5m, G_post = 6.2m (see here). So we get:
0.078 = (k1 + k2 * 6.2m) / 13.5
0.0523 = (k1 + k2 * 7.5m) / 20.57
Solving the linear system gives:
k1 = 0.944
k2 = 0.0175 * 10**-6
To get an incremental uncle rate per million gas, you would need to divide k2 by the block time (13.5) so you get 0.0013 per million gas. Another way to see how k2 is tiny is that a 2/3x reduction in block time leads to a 3/2x increase in uncle rate, showing that “base” (ie. not usage-dependent) uncle rate by itself explains almost all of the uncle rate.
If you enter x=AVG_BLOCK_UTIL and y=UNCLE_RATE in etherchain’s correlation utility and set the date to Jan 16 (first Constantinople attempt, which is what forced everyone to update), you can see the line doesn’t slope up quickly at all.
Note that as an absolute upper limit, marginal uncle rate risk is 0.01 per million gas, because that’s what it would be if all of the current uncle rate were explainable by the k2 * G term. So we have two estimates for marginal uncle rate risk: 0.0013 per million (aggressive) and 0.01 per million (maximally conservative).
We can compute the expected loss to a miner of including a transaction via U' * (R_B - R_U) (marginal uncle rate risk * block reward minus uncle reward). The average uncle reward is ~1.67 (note that this means that most uncles are getting the full 7/8 reward; a year ago this was not true, which is part of why a year ago many miners were not including blocks). So R_B = 2, R_U = 1.67 and U' = 0.0013 per million gas, so expected loss per million gas is 0.000433 ETH (or 0.433 gwei per gas). Under conservative estimates this goes up to 3.33 gwei per gas.
TLDR: the disincentive that miners have against including txs is currently already quite low, somewhere between 0.4 and 3.3 gwei, which is only a small portion of transaction fees seen today.