EIP-1559: Fee market change for ETH 1.0 chain

From what I have observed in real-world ethereum fee data, most of the time, transaction gas prices form a concentrated distribution except for a few outliers that are overpaying by much more. This means that not only changing the median but also manipulating the second price auction is in no way profitable, even with a small fraction of the base fee being burned. The median is known to be very robust but even for the minimum, it is only enough to set this fraction to be of the same order as the number of transactions times the typical fee increment size for the last few transactions included in a block which is very low. Note that, after reducing volatility this will be even lower than before, thus stability helps security here.
However, I know that currently, there are other points like deflationary economy considered here. Having said that, this is a whole new story, for instance, you can burn everything except for one-tenth of the premium which will go to the miner to get an amplified version of this deflation.

1 Like

I am writing EIP-3416: Median gas premium based on EIP-1559 (August 22nd 2020 version). Differences are:

  • For Gas Premium a Weighted Median is used based on (FeeCap - BaseFee)/2 provided by sender.
  • There is not need to change Txs adding more fields. Is backward compatible with Wallets. Only Miners change.
  • The Base Fee multiplicative update function is made additive, to reduce Base Fee volatility and some attacks (based on simulations).
1 Like

@mtefagh, I was just wondering about a closely related attack when I came across this discussion.

I agree with your analysis that the conditions for it to occur don’t require a hostile adversary, a large enough number of mildly strategic users trying to save some gas could lead to this sort of instability causing unexpectedly high state growth and/or unexpectedly low base fees. However it isn’t difficult to see that the base fee drop across a single cycle of the base fee oscillation is substantially smaller than the amplitude of such oscillation (assuming that the adversary controls a relatively small share of transactions), so I was thinking that a strategic user would have a perverse incentive to delay transactions and send them as batches of double-full blocks in order to both profit off the periodic gas price drops due to the base fee oscillation and amplify any preexisting oscillation, even if they have no interest in depressing the base fee in a long-term attack as you were describing in your post.

This has the potential of negating any usability improvements from this proposal, because: 1/ The oscillation would increase the chances of users overpaying above the “fair” market-clearing price, giving them a perverse incentive to bid below their marginal utility (which would reinforce any preexisting oscillation). 2/ Because it would potentially create periodic times of congestion where the pricing mechanism reverts to a first-price auction. 3/ Because of the rather unpredictable state growth I was complaining about earlier in this thread.

I agree that making the base fee update formula path-independent as in EIP-3416 is a move in the right direction: It would certainly fix the state growth unpredictability and the long-term base fee drop you were describing. However it wouldn’t remove the incentive for users to cause such oscillations, because, if my understanding is correct, in EIP-3416 the base fee paid by the transactions of a block is only dependent on the gas usage of the previous blocks (just as is the case for this proposal), so the submitter of a double-full block doesn’t pay any penalty whatsoever (only the subsequent blocks get to pay the price…), and this short-term attack would still be profitable with either proposal.


You are right but let me remind you that this is only because of 1) the coefficient 1/8 and 2) the hard cap of block size equal to two times the gas target. I have seen discussions about removing this block size limit or changing this coefficient. We should be very careful about these subjects in the future, as they both have the potential to make this attack driving the base fee to zero in a matter of minutes!

Absolutely right! This is actually the original version of this attack which I explained two years ago in this very same thread! Note that, even if you don’t want to tolerate this one single block delay, you can still simulate the same behavior by any kind of gas token.

Yes, like any other pump-and-dump scheme, you either join it or lose money otherwise. I agree with all your points that a long-time equilibrium seems to be every other block will be full with a very low base fee and first-price auctions determining the transactions, and the other blocks will have higher gas prices only for the urgent transactions which can’t wait to join the next cycle of oscillation.

Again, I have mentioned this very point two years ago in here (last paragraph)! I have also explained it more recently in here and here. However, I didn’t mention this in EIP-3416 trying to not deviate too much from the original EIP-1559 making it too difficult to review for other people.

Yes, that’s right, this attack is increasingly profitable with decreasing BASE_FEE_MAX_CHANGE_DENOMINATOR, so it should be possible to mitigate the problem with a high enough denominator, however that doesn’t come without disadvantages because it would also make the base fee less responsive to changes in demand and cause it to revert more frequently to a first-price auction of miner tips.

Hm. Removing the block size limit would make this attack massively more profitable since it would allow the adversary to batch up an arbitrarily large window of transactions without paying any price for it. We should definitely be very careful about that.

Incidentally I’m also of the opinion that gas tokens do more harm than good, but I don’t think that the parallelism between them and this attack of EIP-1559 goes very far, on the one hand because all gas tokens I’m aware of have some significant inefficiency, so the user always pays some non-negligible price for shifting some gas liquidity from block M to N, while this attack can transfer gas liquidity from block N+1 to N without incurring an increase in its total gas usage. On the other hand because the user of a gas token still needs to compete for space in both blocks M and N (and this is the crucial advantage of not having a delayed gas price computation), so they would incur some substantial slippage if the amount of liquidity they’re trying to displace is anywhere close to a full block worth of gas, while by taking advantage of this attack they would be able to hoard up to ~12.5M gas per block at constant price that only the transactions from future blocks will have to pay a penalty for (or an unlimited amount of gas if the block size limit is removed as you were saying :expressionless: ). The other critical difference is that to my knowledge gas tokens don’t lead to long-term state growth beyond the expected bounds, while this attack almost certainly would due to the path-dependence you describe (which, yes, would be fixed by EIP-3416).

Because of these differences I had the impression that gas tokens could be more of an aggravating circumstance rather than a simulation of this attack: Imagine a mining pool trying to recoup some of the revenue lost to EIP-1559 by taking advantage of any oscillations of the base fee and sending a block double-full with gas tokenization transactions anytime the base fee is particularly low. Then they could resell these tokens at a profit whenever the base fee climbs back up and overshoots the average market-clearing price without causing their users the inconvenience of having to wait for the base fee to come down again. While doing this they would constructively interfere with the base fee oscillation they’d simultaneously be profiting off – And the greater the amplitude of this oscillation the greater their profits and the lower the usability of this proposal to the non-strategic user naïf enough to send a transaction with their “honest” marginal utility specified as max fee per gas…

That’s fair. I agree that this is a serious problem, it’s unfortunate that it hasn’t gotten more attention so far buried behind a wall of comments.

True, however, there are proposals like EIP-3322 to enshrine them into the protocol which makes them extra-efficient.

Sure, I didn’t mean to say simulate this attack under current conditions! What I was trying to say was that if you don’t want to schedule your transaction execution because you hate delays, or even if you don’t have any transaction to pay for (and therefore can’t profit from the vanilla version of this exploit), then again, trading gas tokens can be used to make way more money under EIP-1559 than today, which is exactly what you have explained in your next paragraph.


Today, I was reading more about the market impact theories in the economy, and not only they define the permanent price impact which is the same as our discussion here (affects the current transaction and the ones after that), but also they introduce a temporary price impact which translates to affecting only the current block and not the next ones! Moreover, even there are theories of elastic markets in which the magnitude of temporary price impact dominates permanent price impact which is quite the opposite of EIP-1559. BTW, I have not found anything in which there is zero market impact for the transaction itself.

This brings me to suggest that we can still use EIP-1559 for the temporary price impact if we want to have a multiplicative formula that is supposedly more responsive, but for the permanent price impact, it is absolutely necessary to consider a path-independent update rule! Moreover, we can have an exponential path-independent dynamic pricing formula that is super responsive. For a thorough comparison from the economic literature, see here.

@vbuterin @hexzorro Yet another hidden gem from the economic literature:

Just quoting some lines from the abstract and concluding remarks:

We show that when the price impact of trades is permanent and time-independent, only linear price-impact functions rule out quasi-arbitrage and thus support viable market prices. When trades have also a temporary price impact, only the permanent price impact must be linear while the temporary one can be of a more general form.

… On the other hand, if the price-impact and price-update functions are independent, then only the price-update function must be linear in trading volume, while the temporary price impact can have various forms without offering quasi-arbitrage opportunities.
The theoretical microstructure literature usually assumes that the change in prices is time-independent and reacts linearly to trading volume. This paper demonstrates that the assumption of time independence of price changes already implies the linearity of the price-update function.

Translation to our case:

  • Round trips are the fluctuations and oscillations we are talking about.
  • The price manipulation strategy translates to our path-dependence attack.
  • I have already explained the temporary (only affects the individual transaction that has also triggered it) and permanent price impact (affects all current and future transactions equally) in my previous post. Furthermore, there exist transient price impacts that will decay over time.
  • Altogether, this suggests using the additive linear term in EIP-3416 which does not admit price manipulation, while we can add other terms as temporary price impacts.
1 Like

Interesting reads, thanks.

I suspect that this form of attack (or shall I say abuse, intentional or not) provides a counter-example to the thesis that this proposal is incentive-compatible for users. Tim Roughgarden has a proof for its user incentive-compatibility in page 27 of his article, however his proof is local to a single block, so it doesn’t consider the possibility of a user maximizing their utility by not submitting the transaction and waiting until the next block if they can determine that the base fee is decreasing due to blocks being under-full.

Ironically the strictly delayed price impact that makes this attack particularly profitable (even in a relatively stable market close to the steady state) seems to be intended to make the pricing mechanism incentive-compatible for miners (there’s plenty of commentary about this in Tim’s article as well), so this seems like a case of inadvertently giving users a tool for price manipulation while trying to prevent miners from doing the same.

That means that there is a theoretical benefit from the delay but I think that it also comes at a cost of economic efficiency. Suppose that the market is initially near equilibrium with a base fee close to its optimal market-clearing price (call it p0) when the network is perturbed with a double-full block added to the blockchain at time t0, causing a temporary price impact lasting between t1 and tn, at which point the base fee drops back to within some arbitrary threshold dp of the previous equilibrium price: In such a scenario a total of ~12.5M gas capacity of the blocks between t1 and tn will have been auctioned off at p0, displacing ~12.5M gas worth of users with higher marginal utility of the order of p0+dp – An example of economic inefficiency.

I don’t think that’s inconsistent with @vbuterin’s argument justifying the economic efficiency of this pricing mechanism in his article. His argument seems to be mostly concerned with this mechanism being efficient on the average (e.g. the average cost paid by users approximating the average social cost born by the operators of the network). However a pricing mechanism may seem to be efficient on the average while remaining highly inefficient locally if you focus on any specific case, e.g. if the price paid by different users is largely disconnected from their share of responsibility in the social cost of running the network, or if the revenue obtained from users is disproportionately distributed to speculators (through the base fee burn) instead of to the individuals actually bearing the cost of running the network.

I understand that the initial intuition behind this delay was that the current block producer cannot manipulate the base fee. However, this brings me to another suggestion. Why should we design the system in such a way that miners detest the base fee and then make other design decisions in order to protect this base fee from their manipulation?

1 Like

NEW UPDATE on EIP-3416 (Median Gas Premium):

Simplified so we can add these changes after/with EIP-1559, so we can include the needs fields, so can be included in the following fork. Technically, even if we are not fans of the wallet changes, our EIP can be added on top of EIP-1559 as the two improvements: Premium Pricing and Base Fee calculation.

1 Like

are u256 ?

Yes, 256-bit unsigned integers. There is a practical limit at the current total supply of ETH / 21000 (the current cheapest transaction), but that number is complicated/non-trivial to calculate so there is no consensus level hard cap.

If miners feel less profitable, they will switch to other coins. Without enough miners, ETH is dangerous. That’s the biggest risk.


One image…

can we rename gasTarget to gasLimit and reevaluate all formulas in the eip paper with gasLimit instead of gasTarget.
then we need to specify what are the values of
gasLimit (gasTarget) and baseFee of the first eip1559 block.

There is a pull request out to make the value in the block header be gasLimit. It sounds like almost everyone is in agreement with it, though we need to figure out how to deal with miners who have set --gas-limit to 15,000,000 as we don’t want the block size to cut in half shortly after the fork (which is what this change will do if we don’t do something about the CLI parameter).

gasLimit of the first block will be 2 * gasLimit of the parent block.

This is already defined: the parent_block of the fork block is assumed to have a base_fee of 1,000,000,000, and the first 1559 block will then have a base fee calculated off of this.

It is worth noting that I believe at the moment every client implements this incorrectly. :confounded:

Hi everyone. What if we use the basefee as a means to incentivize the miners to future hard fork activity?

Fee volatility is due to the fee bidding war. And it seems the progressively growing basefee would do the job well.

The focus is on where the basefee goes. Burning it seemed like a good way to keep the incentives of multiple parties since ‘nobody’ gets it.

But what if these basefee could accrue in a ‘bank’ and this amount is used for the miners(and validators) for the future protocol upgrades? The basefee accrued could be evenly distributed to the miners once the hard fork is done as the general ethereum community intended.

This could work as an incentive to align and organize the overall miners whenever there is a hard fork.

If there is any MEV opportunity available, it’s gonna happen anyway. So 1559 doesn’t fix this. Only slows it down.

How I see is 1559 isn’t mean to punish anyone or hurt anyone’s opportunity to, let’s say, profit. If the basefee, which is meant not to be used as a cause of deviation, does the job well for keeping the fee volatility within a predictable range, this could have more utility if it had other uses.

The protocol can mint coins freely, so if we need to incentivize some particular behavior in the future we can just mint to achieve that. It is generally better to keep each mechanism design separate and not co-dependent when possible.