EIP-1559: Fee market change for ETH 1.0 chain

gas

#21

I will unfortunately have to present remotely; it’s too close to EthCapetown for me to fly in personally. But will be very happy to do be around on call for as long as needed.


#22

Great, remote is fine. Is this the best place to work out logistics? or I can use email / telegram / whatever works.

We will need to know your time zone to schedule you at a reasonable time.


#23

I love this proposal! I am a non-developer who has performed several thousand transactions in the last few months, and paid gas prices ranging from 1 to 40 Gwei via metamask. The current system actually works fairly well for me, since I have become an expert in picking the correct gas price, but I would like to not spend so much time gaming the gas prices.

Rather than adjusting the MINFEE by 1/8 in each block, is there a reason we can’t adjust it once a day to remove fluctuation even more? I would like to see a target of 50 Billion gas per day rather than 8 million per block, and triple the max size of each block to 24 million gas (uncles allowing). That way if a big ICO or surge of spam hits, we could see 100 Billion in gas for 24 hours, and then MINFEE increases once every 6200 blocks (like Bitcoin-style difficulty adjustments) until the daily gas usage falls below the target…at which point it slowly starts coming back down. This would have the nice effect of doubling current transaction capacity during busy periods while keeping the state size growth where it is now.

If anyone has a super urgent transaction, they could pay 2x MINFEE to (nearly) guarantee it in the next block. Metamask could then simplify the choice of fee to Normal and Fast (2x).


#24

Exciting research overall and the big picture is crystal clear, but from what I understand the choice of the actual update rule for dynamic pricing is not justified very well. For this specific proposed formula, I have an attack in which a small number of users with only 10% of transaction volume can halve the price in less than 1000 blocks only by a particular timing for broadcasting their transactions.







#25

Replied on the Zcash thread, copying my replies here:

I think I see the flaw in your attack strategy. Your attack basically says that the attacker (with 10% of all transactions) concentrates their transactions in every tenth block, so nine blocks out of ten, the attacker’s share is empty and the block size is 90% of the target, and the tenth time the attacker sends all their transactions so the block size is 190% of the target. This means that gas usage adjusts down by 1.25% nine blocks out of ten and adjusts up 11.25% the tenth time, but because of (x-a)*(x+a) < x**2 inequalities, this leads to a slight decrease on average (0.9875 ** 9 * 1.1125 ~= 0.9934 per 10-block period). Applying this 100 times, we get the observed 50% decrease. So it is true that it’s possible to send the same transaction volume with slightly different consequences to demand, but this ignores the fact that demand adjusts with fees, and once the fee drops a few percent others will come in and the equilibrium re-established. All that this means is that in equilibrium average usage will be about 0.5% higher than the target; not a big deal.

That said, if we want to eliminate this issue entirely, we can do that by replacing minfee *= (1 + excess * adjSpeed) with minfee *= e ** (excess * adjSpeed). Doing exponentiation in consensus is hard, but if we apply a quadratic Taylor approximation e ** x = 1 + x + x**2 / 2, so we do minfee *= (1 + excess * adjSpeed + (excess * adjSpeed) ** 2 / 2) , then the discrepancy drops from 1 - 0.9934 to 1 - 0.99978. I’m not sure if it’s worth the extra complexity, I think either way works fine.

Users are paying for the burden which the previous users put on the network rather than their own

This is intentional for incentive compatibility. It’s a common technique in game theory for the price that a user pays to be explicitly only based on other users’ activity, so that incentive-compatibility for the user can be proven trivially as a simple matter of “if the price is favorable the user gets it, otherwise the user does not”. Otherwise, a user’s “real price” is higher than the “set price” because a user has to take into account the fact that their own transaction pushes up the real price for themselves.


#26

Replied on the Zcash thread, copying my replies here:

Otherwise, a user’s “real price” is higher than the “set price” because a user has to take into account the fact that their own transaction pushes up the real price for themselves.

Yes, I agree with your observation. However, I think this can actually be a good point and should be exploited because it incentivizes a user to avoid executing a lot of transactions in a single block. This is similar to the problem of liquifying a large volume of some asset in game theory, in which whenever you sell some amount the price goes down, and as a result, you are incentivized to sell little by little. I think the same mechanism design helps to avoid network congestion.

To be more specific, I have already mentioned the paper “Optimal Execution of Portfolio Transactions” in which the authors prove that if we have a very similar additive update formula, the optimal strategy is to execute transactions over a long period of time. Maybe we can use the same formula in here.

That said, if we want to eliminate this issue entirely, we can do that by replacing minfee *= (1 + excess * adjSpeed) with minfee *= e ** (excess * adjSpeed).

If I rewrite your formula as log(minfee) += excess * adjSpeed your alternative suggestion is just to have the same additive update rule and then exponentiate it to get minfee. As I said in the previous comment the additive framework is well-known in economics but why the exponential? In other words, suppose that minfee += excess * adjSpeed, and then we charge everyone a fee of f(minfee). f could be the identity function, an affine mapping, or any other positive increasing function including the exponential function, but I am not sure why exponential seems like a canonical choice to you?

This is intentional for incentive compatibility. It’s a common technique in game theory for the price that a user pays to be explicitly only based on other users’ activity, so that incentive-compatibility for the user can be proven trivially as a simple matter of “if the price is favorable the user gets it, otherwise the user does not”.

Even in the new settings corrected by the exponential or additive formula, I still believe that users should also be charged for their own transactions as well as the aggregated previous usage. Today, I was reading about the gas token and any such smart contract exploiting storage refund in Ethereum can be used for hoarding which is immediately profitable if the gas price you pay is independent of the gas cost of your smart contract.