EIP-1559: Fee market change for ETH 1.0 chain

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.

:+1:t2:

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:
https://doi.org/10.1111/j.1468-0262.2004.00531.x

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
maxInclusionFeePerGas
maxFeePerGas

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.

2 Likes

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.

Thanks for bringing this up, I think it should get a lot more attention in light of the many efforts in the community to lower the barriers to entry for users.

Hi everybody,
Sorry, I didn’t read the 373pages of comments before posting, but I thought this is important for u to discuss(apologies if someone already mentioned it before)

1-I know u r familiar with Tim Roughgarden report, but here’s another paper with Simulation studies (one of the 4 authors is from the Ethereum org)

From a fast reading of the paper, they emphasize:
A)-The impact of the pool eviction policy ( which I believe contradicts with their 1st assumption that a non chosen TX is considered just a new arrival for next block; what about analysis which will wait, which will increase Fee cap, which will donate secretly to miners & that’s a black market I don’t know if u discussed the prob of its existence even in bitcointalk which is pure POW I found someone asking about the donation details)

B)-The uniform distribution of fee caps in a given interval, so u know better than me if this is possible or users will tend to imitate each other to get a better chance by “going with the flow & doing what everybody do”???


“The previous convergence results critically depend on the provided thresholds. If the step-
size exceeds these bounds, then the base fee adjustment rule may lead to chaotic updates.
As mentioned above, these bounds depend on the number of arrivals, λ, and in the range of
valuations, w. If λ increases or w decreases, i.e., if the system becomes more congested or if the
valuations become more concentrated around a specific value, then the thresholds go down and
a given step-size may not be enough to guarantee convergence. In fact, as we will show, for any
step-size, there exists a (reasonably large) λ and a (reasonably small) w so that the dynamics
become chaotic.”
.

For more remarks, and also Tim Roughgarden replies to what is said about Deflation, check

Summary of EIP-1559, base fee dynamics, what to look for when EIP-1559 launches, and interesting question & answer session by @timbeiko @barnabe @MicahZoltu