EIP-1559: Fee market change for ETH 1.0 chain

EIPs
,
225

And that’s great. Right? You will have made the network accessible to even more users. Resulting fees will still be lower (or equivalently since that’s what you seem to care about the most: delays will still be lower at a given price point) since otherwise those new low-marginal-utility users you have attracted won’t have any reason to stick around.

I agree that the cost of state growth is a serious problem that affects most blockchain networks currently in production, but like any cost it can be quantified and folded into the equation I was referring to as “whatever usability metric you do care about here”. The experiment still makes sense if we consider that additional term, right?

Vitalik’s article “Blockchain Resource Pricing” has some interesting discussion about the marginal social cost to the network as a function of the block size, and apparently he concludes that the curve is relatively flat in a neighborhood of the block size values commonly used today. Ironically this assumption lies at the very core of EIP-1559: At the promise that it will achieve better economic efficiency, and within the assumption that it’s acceptable to double the allowed block size overnight (the indirect market incentive introduced to try to keep that from happening is no guarantee that there won’t be substantial state growth – But maybe that’s okay for the time being until Ethereum 2 is fully functional).

So as far as I can tell if you turn out to be right and even a small increase in block size leads to an unmanageable explosion of social cost, this proposal is inevitably flawed, too.

I agree that this is a really hard problem, but my intuition also tells me that if you have been able to construct a more efficient gas price estimator on-chain one should also be able to replicate that estimator off-chain with at least similar properties. Why not try to verify that experimentally?

1 Like
226

There still seems to be a misunderstanding about the purpose of EIP-1559. Its purpose is not to lower gas prices for anyone, nor to speed up transaction inclusion at a given price point. Its purpose is to make it so a user can reliably (within some bounds) get a transaction included, and remove the need for users to participate in a first price auction (which is a notoriously difficult auction type to be good at).

We aren’t trying to attract low marginal utility users with EIP-1559. We are trying to attract users who care about simplicity and usability. Removing the first price auction mechanism allows users with high marginal utility for block space who care a lot about simplicity and usability to utilize the platform.

If the dev team’s plate wasn’t so full I would lobby to lower the current block size. That is to say, in my opinion the block size is already way too high at the moment, and there is no room (in fact negative room) for additional increases to block size.

Every analysis I have seen and done indicates that state growth (over sufficient time periods for averages to work out) does not change with EIP-1559. If you believe there is a flaw in the logic that leads to this conclusion I would definitely like to hear it. So far I haven’t heard any complete/sound arguments that state growth will increase overall with the introduction of EIP-1559.

Many people, including myself, have tried to solve this problem. If you have a better solution than what is out there I strongly recommend either building a tool that utilizes your solution, or proposing the solution to the community (e.g., on ethresear.ch). All of the block price estimation tools out there are experimental attempts to address the gas price estimation issues, and they all fail in one way or another so far.

1 Like
227

The most valuable thing that miners will have is the tx order in blocks. It’s extremely valueable for Defi.
In the current system, users can fight to be #1 in the blocks by outbidding each other transparently through the mempool (if miners do not trade themselves). I would not be surprised if this becomes an non-transparent market and defi people can bribe miners off chain for a specific spot in the block which can be asked on top of the tip_fee where the “tx_order_fee” is an offchain bidding market, - essentially getting back the ~30% income decrease which was introduced by EIP-1559.

EIP-1559 will encourage miners to decrease transparency.

Miners will fill base_fee 0 blocks with their own tx’s (miner payouts) and indirectly push the tip_fee higher … which is what they could do now as well. However, with 1559 this is their only way to not pay any of the base_fee.
The incentives to include other tx’s into base_fee 0 (and other low base_fee) blocks are very little (fee_tip), the complete opposite of what is happening now.

If miner’s instead would receive a piece of the base_fee, things look differently.

1 Like
228

Miners will fill base_fee 0 blocks with their own tx’s (miner payouts) and indirectly push the tip_fee higher … which is what they could do now as well. However, with 1559 this is their only way to not pay any of the base_fee.

If the base fee is 0, then that means that demand for block space is low at the moment. That’s when time-insensitive users, including miners, should be pushing txs. Imo this is the system working as intended. In practice though, a non ghost chain probably will rarely or never have zero base fee.

229

Mining pools will need to payout at some point, if the costs of the base_fee become to high it will outweigh the incentives to not empty blocks and will encourage them to drive the base_fee to 0.

230

This seems unlikely to me for three reasons

  1. Losing a lot of tips
  2. Gradual transition to base_fee zero requires prolonged miner collusion
  3. Gas optimized payouts should be able to make this a non-issue (not totally sure about this)
1 Like
232

Payouts need to be paid at some point. The tip_fee is independent from the base_fee, so driving it to 0 makes sense depending on the amount of payouts that are queued up…

233

I wasn’t trying to change your mind about the purpose of EIP-1559, nor convince you to attract low marginal utility users except possibly as a side effect, I was just trying to show the contradiction in your argument that increasing supply by a finite amount is useless – It will still have a lasting impact on how reliably users can get transactions included (hopefully I got right what you want this time) at any given price point, which might be comparable to the benefit obtained by this proposal according to the same metric. And if it is, isn’t it worth considering that alternative seriously given that it’s a massively simpler proposal which will also incidentally benefit low-marginal-utility users?

Reducing block sizes would hurt a lot of users. If the necessity to reduce block sizes is as urgent as to justify such a compromise then the worst thing that could possibly happen now is a proposal lifting the block limits to 2x the current values…

I don’t think it’s fail-proof, like most market incentives trying to steer people away from doing bad things. I can think of several potential externalities completely out of our control that could lead to violent price movements (not necessarily of ETH/USD itself but even of other assets relative to ETH) which could disturb that feed-back loop by shifting the equilibrium base fee by orders of magnitude.

E.g consider what could happen if you do declare a nuclear war ( :wink: ) on the miners and they truly form a cartel and retaliate by taking advantage of their majority hashpower in order to do something really bad, causing the price of ETH to plummet due to the markets losing confidence in it. This would momentarily make the base fee really cheap in absolute terms and give people a strong incentive to sell off, suddenly making most blocks double-full and further decreasing the value of the currency, possibly to the extent that the price drop neutralizes the effect of the hard-coded base fee increase, allowing people to continue filling up blocks to 200% for an extended amount of time. At the end of this downwards spiral a new equilibrium price may be reached, at which point blocks will return to 100% full, but there is no guarantee that it will be followed by a period of <100% full blocks, since there is no guarantee that neither the base fee nor the currency it’s denominated in will ever retrace their way back to their original values, leading to a net state growth larger than the present one.

And no this doesn’t mean that I’m pessimistic nor “bearish” on Ethereum, I’m just trying to understand how this market feed-back mechanism would behave under large unexpected price movements (call it a form of risk management).

Incidentally state growth isn’t the only reason why I think that the steep dependency you are depicting between block size and social cost would imply a serious flaw in this proposal: As you can see from page 19 of Vitalik’s “Blockchain Resource Pricing”, the key requirement for the present proposal delivering an economic efficiency improvement is C’’ < D’’ (or the absolute value of the slope of the marginal social cost being strictly lower than that of the demand function). If you’re right and there is a catastrophic increase in social cost anywhere close to the current block size value then we are way better off setting a hard cap at whatever level of supply we can consider sustainable, rather than relying on market feed-back mechanisms to regulate it.

1 Like
234

Payouts need to be paid at some point. The tip_fee is independent from the base_fee, so driving it to 0 makes sense depending on the amount of payouts that are queued up…

I think one of us is misunderstanding how the EIP works. My understanding is that base fee is driven down when prior blocks are unfilled. In order to artificially reduce it, it would require miners to not include transactions which could have been so. In this way, they are losing out on tips that they could have obtained.

E.g consider what could happen if you do declare a nuclear war ( :wink: ) on the miners and they truly form a cartel and retaliate by taking advantage of their majority hashpower in order to do something really bad, causing the price of ETH to plummet due to the markets losing confidence in it. This would momentarily make the base fee really cheap in absolute terms and give people a strong incentive to sell off, suddenly making most blocks double-full and further decreasing the value of the currency, possibly to the extent that the price drop neutralizes the effect of the hard-coded base fee increase, allowing people to continue filling up blocks to 200% for an extended amount of time. At the end of this downwards spiral a new equilibrium price may be reached, at which point blocks will return to 100% full, but there is no guarantee that it will be followed by a period of <100% full blocks, since there is no guarantee that neither the base fee nor the currency it’s denominated in will ever retrace their way back to their original values, leading to a net state growth larger than the present one.

This is like saying, “consider in a nuclear war, fishery stocks could fall really low”. This is kind of besides the point. If drastic changes occur in the ecosystem, then obviously a lot of assumptions go out the window.

235

Heh, maybe you don’t consider the rather dramatic scenario I was using as example to be particularly likely (I don’t know what to think anymore after seeing the mutual threats of escalation around the internet…), but I guess you agree that drastic irreversible price movements happen all the time in the cryptocurrency world, and under such conditions the rate of state growth would significantly deviate from the expected one for this proposal. I don’t personally consider that to be a big problem unless @MicahZoltu is right and even a small increase in the rate of state growth would pose an unmanageable problem to the network, in which case we should probably prefer one of the alternatives that are able to deliver predictable state growth, right?

1 Like
236

If there currently exists 100M gas worth of demand for Ethereum block space with a marginal utility that is over the opportunity cost to miners for inclusion, then any increase in supply short of around 100M will result in no meaningful usability improvements. As you approach 100M you may get to a place where seasonal demand changes allow for some users to experience under full blocks, but during peak season you still have perpetually full blocks and thus you have the exact same problem. Adjusting the supply below the demand threshold (less than 100M in the above example) does effect gas prices, but that isn’t what we are trying to solve.

Also, we have hopes that Ethereum will continue to increase demand, which means that even if we increase the supply enough to satisfy demand today via block size increases, it will just be back to the same problem tomorrow. That is to say, minor tweaking of block size isn’t a long term viable solution here. We need real scalability solutions (like rollups and sharding) to solve the supply problem as they give us orders of magnitude increases rather than linear increases, and with very different cost profiles than block size increases.

EIP-1559 does not increase the average block size by 2x. It remains flat. See Why I think EIP 1559 block variance is nothing to worry about - HackMD for why that is what matters, not transient block sizes.

You are correct that if there is a base_fee increase that doesn’t come back down then over some window of measurement then there will be a net increase in block size. Similarly, if there is a net base_fee decrease, we’ll see an average block size decrease over a time window that includes that net decrease. To put it another way, while the base fee is increasing, average block size will increase. While the base fee is decreasing, average block size will decrease.

Given a particular time window, we know that if the base fee is higher at the end than the start, then we ended up with the average block size being over target. If the base fee is lower at the end than the start, then we ended up with the average block size being under target. The amount the base fee changed, and perhaps the speed it changed (I am not sure if speed of change matters here, but would be interesting to find out) will determine how much over or under we are for that time window. This is generally considered acceptable because the chain growth is quite well bounded.

You do bring up a good point though that the base fee is denominated in ETH, while the marginal utility of inclusion may not be denominated in ETH for users. This means that the price of ETH relative to whatever user marginal utility is denominated may decline steadily over time which would result in the base fee steadily increasing over time. In such a world, any given time window selected would result in a higher base fee at the end compared to the beginning, which means there would be an average increase in block space utilization.

This is certainly an interesting facet that I hadn’t previously considered. I’m not sure that I’m terribly worried about it, but it is definitely worth thinking about further.

1 Like
237

We generally try to design things so that they continue working in adverse environments.

1 Like
238

In order to try to resolve this disagreement let’s try to define more precisely what we mean by a usability improvement: Does it mean, for instance, increasing the amount of transactions sent per individual in a given population that make it into the blockchain within a “reasonable” timeframe of, say, 5min? (If you’re still not satisfied by the metric I’m trying to optimize feel free to suggest a different one which can be expressed quantitatively) If that’s the case then increasing the gas limit by a small factor can be expected to decrease the minimum gas price of each block by a similar factor (which is related to the former by the price elasticity of demand), allowing it to fall below the marginal utility threshold of more users that are now able to ensure immediate inclusion of their transaction into the next block, thereby improving the usability metric I was referring to above.

Under increasing demand the usability metric above is expected to decrease steadily due to the increasing denominator with a roughly fixed numerator, but at any given point in time usability will be greater than it would be for the same demand if the change was reverted, so it’s not like you’re “back to the same problem”. Incidentally, the same thing can be said about this proposal: Usability will increase by a finite amount initially, and then steadily decrease from that point on for the exact same reason. Which of the two will give a greater usability improvement? It’s hard to say a priori, which is why it would be interesting to address the matter quantitatively: If a substantially simpler change is able to provide a greater benefit at a comparable cost you’ll have a clear sign that something is wrong and the proposal needs to be corrected (or fully replaced with the simpler alternative).

Yes, only the hard block limit is increased by 2x. Regarding the average block size, it’s not at all clear that with this proposal it will remain the same as today in the long run. If the price of ETH has a certain momentum, it wouldn’t be unexpected for the base fee to develop a similar but opposite momentum (since their product is tied to the marginal utility users extract out of the network, pretty much as you point out in your last comment), which would allow blocks to remain systematically above or below 100%. The resulting average block size may substantially deviate from the present one, and it’s hard to say in which direction it might go and how much without being able to predict the future pricing of ETH, so this proposal requires us to have some tolerance to the average block size deviating from the expected result, which is why it seems natural to me to compare its “usability” performance with the much simpler alternative that increases the block size by a small factor (Under the assumption that such deviations from the current block size will be small which is by no means guaranteed, the worst-case behavior of this proposal is only bounded by the 2x hard limit).

239

This is the long form of the UX problem: A Tale of Two Pricing Schemes. A User Story | by Micah Zoltu | Coinmonks | Medium

Note that it has nothing to do with the magnitude of the gas price. It entirely has to do with predictability of inclusion. We get the usability benefit anytime blocks are full (which is effectively 100% of the time for a while now).

240

Thank you very much for your unremitting efforts to point out flaws in defend of EIP-1559.

IMO, if EIP-1559 is for fixing UX problems, which means providing reliable information about tx inclusion cost to users so that they can skip guess tx cost, it is trying to address a question cannot be addressed at protocol level.

Whenever user try to send a on-chain tx, their payment to miners have to cover miners’ marginal cost for producing that gas otherwise it cannot go into blocks. But the protocol cannot know miners’ marginal cost, so it can not provide enough information to improve UX. Base fee can not tell you how much tips you need to pay.

An important arguement from pro is that when block is not full (which is attributed to self-adjusting base fee), users whoever willing to pay base fee and a small amout tips can be included due to profit-maximized strategies excuted by miners.

It is true only if we assume miners’ marginal cost of gas production is zero, or a well-known constant value (which is obviously unrealistic) . Miners’ marginal cost must be incremental with the amout of gas already provided. Once again, the marginal cost is a private information cann’t be determined unless they make it public by themseves, no matter whether block is full or not.

2 Likes
241

Actually, it is also true that if we want to improve this UX, EIP-1559 cannot do anything, but better gas price oracles can.

Nowadays, the well-known gas price oracles ues historical date to predict inclusion cost in the near future. It is highly limited. Rather, we have https://gasnow.org, whose paradigm is mining nodes open gas prices of transactions being mining in their mempool, which can provide more accurate prediction of incert cost.

P.S. You cannot use data and simulation to prove something is true when these thing is wrong theorically, because there would not exist a right theory can intepret these data. Just like pros of EIP-1559 use inefficiency of existing gas price oracles to prove current mechanism is inefficient.

1 Like
242

As far as I know, almost every arguement from pros of EIP-1559 is proved to be questionable (if not incorrect), including UX-around arguements and security-around arguements.

I am willing to provide key reasoning from view of economics.

And I believe that the open and transparent environment for policies debating in ethereum community can take us close the truth further.

2 Likes
243

If I understand your argument correctly, you are saying that when the base fee is sufficiently low, miners will only partially fill the block because of the marginal cost is insufficiently covered by the base fee, leading to an artificially low base fee in future blocks and large numbers of pending txs.

When the base fee is high, this is obviously not an issue, as it more than covers the marginal cost up to a full block. When the base fee is low, the easy solution is for wallet ui to recommend a minimum basefee + tip value, regardless of the value of the base fee. For the end user, this is still a better UX than what is currently being done.

244

Right, so does the usability metric suggested in my previous reply sound like a reasonable benchmark for the effectiveness of this proposal, or do you have something else in mind? It’s pretty much in the spirit of providing a quantitative measure of the predictability of inclusion.

245

Emm…you mistake the arguement. What they said is that base fee could be sufficiently high, so tx can be mined would not make a full block (willing to pay base fee is a precondition to be mined). It is not relevant with manipulation.

By the way, as base fee will be burned, it can not incentive miners (can not help to cover miners’ cost), just can limit tx can be mined.

By the way, if you prove a better UX, you can rethink about your reasoning. And you may find that, the improvement do not come from EIP-1559, but come from a better gas cost oracles.

1 Like