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?
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.
We generally try to design things so that they continue working in adverse environments.
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).
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).
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.
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.
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.
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.
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.
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.
Oh right, whoops. But I think my argument still stands, a wallet can just include a minimum recommended tip which would be able to meet the marginal cost of the targeted block size (assuming it isn’t at 200% and in first-price auction mode.
Hi Aijan, I’ve looked at an analysis you shared on Medium. It is important to have a critical look at 1559 and not take its arguments wholesale, but there are also several issues with what you wrote. If you are willing to provide key reasoning, it would help to be more precise in the arguments you share. It is not always clear how you arrive at some of your conclusions and you seem to focus on a static analysis when 1559 is inherently a dynamic process.
You are right that the fee market is mostly out-of-equilibrium (by equilibrium I mean at a price where supply = demand), like all markets generally are. In some cases, users will overpay, when demand is lower than the current basefee quotes for instance. This is not an argument against 1559 however. This is a general property of “tâtonnement” mechanisms which dynamically discover prices. The point of 1559 is not to eliminate entirely the possibility that users might overpay since it is impossible unless you have perfect information on the demand curve at every point in time (which is impossible for multiple reasons). The point of 1559 however is to drastically reduce imprecision over the current equilibrium price, which is naturally changing as demand also changes. If you are intent on using this argument as a flaw of 1559, you must be able to show why you think this is worse under 1559 than under the current system.
It’s also not clear how you understand the tip. Are you saying in the quote above that marginal cost is an increasing function of the amount of gas in the block? Miners may have private information regarding their willingness to include transactions that pay them below a certain amount of tip in 1559, but this is fine.
If users are consistently rejected by miners because their tips are too low, they will increase the tips. If some miners reject tips above their marginal costs, any miner can deviate and take these rejected transactions for themselves, this is the argument behind showing that miner collusion (for instance, one that would never include transactions with tips below some level higher than the marginal cost) is unstable and implies a 51% attack for the collusion to truly work. Tips should equilibrate to whatever miners are willing to accept in an efficient market. You could argue that the market is not fully efficient as users usually go through wallets to make their transactions, so the wallet tip defaults is actually what matters. This would likely mean that should a wallet undershoot the marginal cost of the miner, its users would not be included, after which it would review the tip upwards. This is a slower adjustment process than the one I described before, but there is no reason to think the marginal cost to miners changes more rapidly than this, since it depends solely on client implementations. In other words, I do not see an argument why users or wallets shouldn’t be able to find a tip level that satisfies miner preferences.
Hi barnae, really happy you point out this. Yes, I agree with you that both 1559 and current mechanism cannot do that, and that is exactly what I want to say. But my questions remain: Where is the improvement? Or now you agree with that it is just as good as current mechanism in the terms of gas predictability?
Sorry, My English writting is not well [Cry]. Thanks for your patience.
I mean, the supply curve have a positive slope. (For example, when they are providing 500th unit of gas, the cost is 100 gwei, but when are providing 1000th unit of gas, the cost is 400 gwei: marginal cost of gas will increase with the amount of gas that they decided to provide in a certain time window.
So what is the difference between a post-eip-1559 world with current world?
Ehh, I guess you mistake what I said. Manipulation or collusion is irrelevant, I never see any importance to discuss such behaviors in this topic (because I believe that there would not esixt collusion or manipulation). No one has more confidence in market competition than me.
As you mention above, fee mechanism is just a context, in which market competition works to find out prices (cost). I am no saying that EIP-1559 will stuck market functions to find out miners’ marginal cost. I am saying that because protocol cannot find out the marginal cost (no matter we choose which mechanism), so EIP-1559 cannot provide improvement. It is at best as good as current mechanism, if not worse (think about the cases when demamd drops but base fee is still high).
Maybe you think that, it is as good as current mechanims, so it is no a flaw. But IMO, when we propose a change, we have to prove that there is some improvement worth the risk, right?
Thanks for your reply!
No worries, and also want to point out that this is not what hampered my understanding of your post. English isn’t my native tongue either so I can appreciate the difficulty. For instance on your plots in the post I couldn’t always distinguish the areas you refer to, though I could reconstruct the argument. The clarity I was seeking had more to do with arguing for your interpretation of 1559 as a tax and why you think the tip would not equilibrate.
Ok, so if you argue as you do in the post that
When demand increase rapidly, as EIP-1559 allow miners to produce 2x bigger block (‘slack mechanism’), consumers can get more benefits. But when demand decrease and base fee is still greater than zero, consumers have to pay more costs which is higher than current mechanism level.
then I disagree (or at least, I expect a reason why the change would be worse than the current mechanism, by some definition of worse you should provide). If you argue that since we are keen to change the mechanism, then the burden of proof is on us to show that it does improve things, I think it’s fair, but it’s significantly different from your first assertion. On this point the discussion with @mdalembert has more to do with how do we quantify these improvements (still thinking about some of the points raised).
You mention predictability, so I want to try and define what is meant by that. Predictability could mean that given the quoted price you observe (basefee + equilibrium tip), you can expect fast inclusion (typically next block). It does not mean that we know for sure what the gas price is ten or hundred blocks from now (I don’t think this is what you were arguing). Predictability fails in at least one case: whenever basefee is “excessively low” (taking Roughgarden’s definition here), there isn’t enough room to fit all the effective demand (effective = consumers with transaction values above the basefee + tip) in the next block.
This is a case that your analysis could distinguish more finely: there is a difference between “demand increases and so does basefee” and “demand increases beyond what the next block can accommodate and so does basefee, which is excessively low beforehand”. In the first case, there is no reason to think that tips would deviate from the marginal cost level: there is room for everyone, even though the block is filled beyond target (but not beyond limit!) In the second case, there is a legitimate argument to be made that we should see tips engage in a transient bidding war, until basefee catches up again. This is btw what one of my notebooks reproduces: when basefee is excessively low, users do have a strategic incentive to bid beyond the marginal cost tip to get in quicker. We can again differentiate two cases: Either the user does care about inclusion time, in which case it would bid to get in first, or the user doesn’t care at all and just wants inclusion. In the second case, the only reason for a user to overbid is to guarantee that they would get in before basefee reaches their maximum willingness to pay (encoded in 1559 transactions as the fee cap).
With that out of the way, the question should be “how often are we in the first case (effective demand increases, but the next block can accommodate everyone) vs the second case (effective demand rises faster and the next block is too small to accommodate everyone)?” If we are always in the second case, there is a point to be made that we are only reproducing the current model. I don’t have quantified arguments on this, but I don’t even think this is true. Basefee in that case is still a somewhat objective (laggy, sure) oracle of the current market price, and users who have low time preferences but high value for inclusion can “ride out” the market more easily than they could in the current model. The expectation is that we are not that often in the second case (Hasu and Georgios wrote it as “the 95% vs the 5% cases”, though these are not numbers obtained from empirical analysis). This is supported by looking at historical demand volatility and the fact that the basefee updates are governed by a parameter providing some control over how fast it catches up. There are questions on how the parameter should be set (I discussed some above) and they are legitimate, but at the time there are more reasons than not to think that basefee should adequately put us in the first situation (basefee is not excessively low, next-block inclusion can be guaranteed) most of the time. If you agree that 1559 provides substantial benefits in that case, then you should agree that it improves on the current paradigm.
Some stray points to conclude:
-
Even excessively low basefees are not unmanageable. There is an argument that we can even reuse current gas price oracles to help in this case, when users have a strategic incentive to overbid. For instance, a wallet detects that basefee is shifting upwards quickly, and switches to “expert mode” to propose to the user three defaults based on oracles for how competitive the bid should be.
-
Related: None of the above mentions how much simpler the bidding strategies are for users, including for wallets who provide fee estimation. Since this is more intangible, I believe @MicahZoltu 's post “A tale of two pricing schemes” (sorry Micah! i can’t link it, I have too many links in my post already apparently, but it’s easy to find) is the best way to frame it.
Ok, so I understand this as more than the supply curve has positive slope: you also mean that the first derivative of the curve is positive too (marginal cost increases with supply). I think this was quantified before, iirc you’re right that the supply curve is not completely linear (linear: same cost to go from 1M to 1.1M gas block than 10M to 10.1M gas block), but it’s also not far from it. Which supports an argument that users/wallets and miners would probably converge to some imprecise upper bound of the marginal cost per gas unit. Sure we could make models and estimate to the n-th decimal for what it is, but my hunch is we’ll all agree on a round number because Schelling.
Hello barnade, it is great to know your ideas. Thanks for reading my articles. Maybe we could have some shorter but more precise communicaion to make sure our opinions, to save our time and keep going.
IMO, effects brought by EIP-1559 can be classified into three category: UX, (equilbrium) tx cost and security. And the main purpose of our reasoning is to compare the EIP-1559 and current mechanism in these three dimension, to figure out where is improvement.
When it comes to equilbrium tx cost and security, we can use supply curve, demamd curve, consumers’ surplus and providers’ surplus to analyse the performance of current mechanism and EIP-1559 as a mechanism. Use these concept, you can see how much users get (or lost) and how much miners get(or lost) in different market conditions. (Yes, it is static analysis as it do not use simulation to observe dynamic processes. But it is completed as the analysis covers every cases need to be discussed.)
But when it comes to UX problems, mainly ‘the predictability of tx cost’, concepts I mentioned above cannot help. (I never argue that tips cannot equilibrate, no no no, we can just assume that both of gas prices and tips can equilibrate, or nether of them can equilibrate. Otherwise it is unfair. But here, it is imoportant to know that the equilbrium concept cannot help). My difinition of ‘predictability’ is that for those who just persuit inclusion for next block, don’t care about the rank in the block (which means a normal user, not a geek defi user, the same as your opinion), the minimum tx cost is as accurate as possible. EIP-1559 can not help, just like current mechanism can not help (can not provide these information, and I know you get it).
UX improvement is the main arguement of pros of EIP-1559. If there is a difinition of ‘predictability’ which can prove that EIP-1559 can bring improvement, I am very happy to know.
Yes, when demand rises suddenly, 2x bigger block can alleviate the upward pressure in tx cost.
But it is irrevelant to predictability problem. Micah had repeated several times this EIP would not highlight itself as a solutions to expensive tx costs. I had thought that we don’t need to talk about this.
Sorry for my long reply! But it may be necessary for clearness. And thank you for your effort.
I don’t think this is the UX improvement I’m describing. The linked article explains it best, but I think it could be summarized as: For people whose marginal utility of inclusion is in the top 12M gas worth of users, getting a transaction included quickly and reliably is very simple and you pay as close to as little as possible to achieve this.
I strongly recommend reading A Tale of Two Pricing Schemes. A User Story | by Micah Zoltu | Coinmonks | Medium for a more long form description of the UX problem and solution. The crux of it is that you can overbid without overpaying. First price auctions are incredibly hard for humans, especially in a chaotic bidding environment. 1559 allows users to effectively participate in form of uniform price multiunit auctions for block space, which enables them to bid their marginal utility (or at least much closer to it) without having to pay their maximum bid every time.
Hello Micah. I have read your article. IMO it just repeat some assertion you had posted several times, but still do not provide enough explaination. You just say that it can do this, it can do that, but you do not explain how and why.
For example, you said that EIP-1599 can help users ‘avoid overpaying’, but how? If we read carefully, we can find two key information:
- You introduce an additional field for tx called ‘Fee cap’, which difines the maximun protocols and miners can extract from this user; at the same time, user still need to set ‘tip’ manually (to incentive miner). After setting, when ‘base fee + tip’ < ‘fee cap’, the tx is minable; and when it go into blocks, user can get ‘fee cap - base fee - tip’ back. (Is it a correct understand?)
You can say that it can avoid overpaying as users can set the maximum value they are willing to pay as ‘fee cap’, so actual payment can not beyond their willing. But in current mechanism, no one will set a gas price higher than the maximun value thery are willing to pay.
At the same time, the possibility of overpaying still remains as user still need to guess tip level, just like in current mechanims that they need to guess gas price level.
Willing to pay base fee can not guarantee that the tx will be included. It is possible that a user set a sufficient fee cap, but can not be included as the tip he set is too low.