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?
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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.
- The other key reasoning is that base fee can be sufficient high to ensure that blocks will be not full. As it is not full, due to profit-maximized strategies excuted by miners, they will include any tx willing to pay base fee and a positive tip (no matter how low is it). So every tx willing to pay base fee can be included. (Is is a corrent understand to your arguement？)
This arguement is much important than the 1）.
But it is still wrong. As a profit-maximized strategy require a miner just include those txs whose tip can cover his/her marginal cost of gas production, rather than include any txs with a positive tip.
And, marginal cost of gas production is a dynamic value. Theoretically, it will increase with the amount of gas the miner decided to provide at that time. (e.g. When he/she provide the 500th gas, the marginal cost is 30gwei, but when he/she provide the 1000th gas, the marginal cost must be higher than 30gwei).
If wo do not hold the assumption that the marginal cost of gas production is a fixed value, base fee can not tell us any useful information to help users avoid overpaying. They still need to guess, just like in current mechanism
There are two fields in an EIP-1559 transaction: max_fee and inclusion_fee. Each block has a base_fee that applies to all transactions in a block and is extremely expensive to manipulate (unless executing a censorship attack).
A transaction will cost between base_fee and inclusion_fee + base_fee. A user can set the max_fee to be 1 ETH per gas, and they’ll still always only pay between base_fee and inclusion_fee + base_fee.
In a transaction today there is only the gas_price. A user will always pay gas_price, even if they set it way too high, like to 1 ETH per gas.
The big difference here is that under EIP-1559, a user can set max_fee to be their marginal utility for inclusion. If congestion increases between the time of clicking the button and the time their transaction is mined, the cost of inclusion may increase but as long as it is still under their marginal utility (max_fee) they’ll be included.
Under the current system, users are strongly incentivized to bid what they believe the market rate is. Since the market rate for gas is incredibly volatile, this means that users often fail to be included. The way for users to combat this failure today is to over pay for transactions by setting the gas_price to a value that is substantially higher than the market rate.
I believe all major clients are being programmed to allow the miner to configure a minimum_inclusion_fee which will be constant for that miner. From a mechanism design/game theory standpoint, the opportunity cost of inclusion is effectively linear, which means there is no rational reason to have any kind of dynamic minimum_inclusion_fee. A miner could write a custom client that has some kind of variable/dynamic minimum_inclusion_fee, but the only real reason to do that that I can think of would be to be a dick.
It is also rational for miners to set the minimum_inclusion_fee to just above opportunity cost of inclusion. The last estimates for this were around 1 nanoeth (gwei) per gas, though I suspect it is lower now.
This means that it is strongly expected that the minimum_inclusion_fee distribution across miners will become known pretty quickly, and it is expected to hover around the 1 nanoeth range. Some miners may set it to 2, and some may set it to 0.5, but it would be mildly surprising to see any miners set it to 100 (this would not be a profitable strategy) and it would be even more surprising to see any miners set it dynamically (this would not be a profitable strategy).
Those two things combine to mean that we should see a quite stable minimum_inclusion_fee across most miners (meaning, most blocks will have a fairly predictable minimum_inclusion_fee) and users can bid their marginal utility on max_fee without fear of overpaying by more than ~1 or 2 nanoeth per gas.
1 Like
This is incorrect. Profit seeking miners not executing a censorship attack against the network should include all transactions where:
max_fee > base_fee + minimum_inclusion_fee && inclusion_fee > minimum_inclusion_fee
minimum_inclusion_fee should be set by profit motivated miners to just over opportunity cost of inclusion (expected to be around 1 nanoeth).
This is also incorrect. Marginal cost of inclusion is approximately linear with gas used. In fact, a major aspect of gas pricing is trying to ensure this is true.
1 Like
Now I know your opinion.
I believe that my opinion and reasoning is clear enough. And your reply didn’t provide any important new ideas I should response to.
I will leave the right of review to the community. People will find out how my last response can cover our discussion.
I find @editor-Ajian 's blog post does a pretty good job at showing that essentially the same market forces are going to be driving gas prices around equilibrium, it was badly needed given the amount of misinformation there is falsely claiming that this proposal is going to reduce gas prices (Thank you for it!). That said I also think that @barnabe and @MicahZoltu have a point showing that the auction mechanism proposed in this EIP has certain theoretical advantages in its dynamic behavior away from equilibrium.
For instance, I agree with @barnabe that the proposed auction mechanism is likely to reduce the pricing imprecision of the current mechanism, and I agree that the base fee can be made to track some stable and more or less objective market price predictably enough (which is critical to keep users from overpaying under significant block-to-block demand volatility), with the caveat I already hinted at that both of these benefits are to some extent mutually exclusive (best stability requires BASE_FEE_MAX_CHANGE_DENOMINATOR to approach infinity which causes the pricing mechanism to revert back to a first-price auction negating the pricing precision benefit, and vice versa, best pricing precision requires BASE_FEE_MAX_CHANGE_DENOMINATOR to approach zero which can lead to high base fee volatility exposing users to overpaying more than they do today), so the practical realization of this proposal is necessarily going to have to make some sort of compromise between the benefits it promises to deliver, which is why I’ve been such a PITA trying to agree on some precise enough definition of what we mean by “improving usability”, since only that way can we answer the question of whether this proposal is going to be cost-effective to the community by some quantitative metric (even while compared with the simplest alternative imaginable of slightly increasing gas limits which incidentally would have advantages near equilibrium that this proposal lacks).
I think that expressing the intended benefits of this proposal in some objective scale is made all the more urgent due to the intertwining of the intended usability improvements with a monetary policy change. Any monetary policy amounts to a redistribution of value from one sector of the community (e.g. whoever is burning their ETH) to another one (e.g. whoever is holding significant amounts of ETH), so I don’t think that @editor-Ajian 's depiction of the base fee as a tax is particularly far-fetched. I believe that the fact that these two changes are being proposed as a single EIP (IMHO without a technical necessity to do so) has greatly contributed to polarization and hampered consensus so far, because it’s extremely difficult for people to judge a proposal based on its actual merits and risks to the greater community whenever they have something to personally win or lose out of it, even if they’re doing it with their best intentions to contribute something positive to the community.
So I suspect that a roughly orthogonal route to get this proposal to gain more traction would be to separate those two aspects into two different proposals (E.g. by implementing the proposal of rolling-average banking and redistribution of the base fee suggested by Tim Roughgarden, which would incidentally also address the incompatibility between this EIP and a fixed-supply monetary policy). At the very least that would fully dissipate the perception of a conflict of interests behind any argument for or against the fee structure reform being discussed here.
1 Like
That sounds like your purpose with this proposal is just to optimize the gas cost of a fixed-size 12M gas worth subpopulation of the population I was optimizing for, with the constraint that their transactions be included “quickly and reliably”. (I’m a little surprised to hear that after you’ve told me several times you don’t care about optimizing gas costs… But okay I’m fine with that… 
)
What should “quickly and reliably” mean? Having more than a certain high probability of being included into the next block? Or something else?
As I see it, there are three salient cases that entirely cover the space of transitions from one basefee to the next:
- Current effective demand is higher than target, but lower than block limit.
- Current effective demand is higher than target and higher than block limit.
- Current effective demand is lower than target.
(maybe Case 4: effective demand is equal to target is simple enough)
In cases 1. and 2., basefee increases. In cases 1. and 3., users can bid the marginal cost (or some upper bound) and receive immediate inclusion. In case 2., users have a temporary incentive to deviate from the marginal cost tip, and possibly to bid against each other.
The cases where basefee is 0 doesn’t seem relevant, but making the distinction between 1. and 2. is important to see the tip dynamics.
There still appears to be a fundamental misunderstanding here, so I’ll try and formalise the argument. I am a miner and it is my turn to mine a block. I have a cost for supplying the block and gas, which we’ll call f(S), where S is the amount of gas supplied in the block. What is that cost? The most important part is the risk of my block becoming an uncle. The larger the block is, the slower the propagation, the higher the risk.
f(0) = b, where b is some constant, meaning that if I mine an empty block (no transactions), I still have to send around a few bytes, so the risk of being uncled is non-zero. If there are increasing marginal costs, say, linear in the gas already supplied, then f(S) = b + a * S2, where a is some coefficient.
Here is how I understand your argument: a user doesn’t know where on that supply curve their transaction falls. The transaction may be included after the miner supplied S1 gas in the block, or after S2, S1 < S2. The marginal cost to the miner for including the transaction is respectively 2aS1 and 2aS2, with 2aS1 < 2aS2. If the user sets their tip to 2aS2 but are included at S1, then they are overpaying: the miner would have been satisfied by 2aS1, since it is their marginal cost.
Do you agree that setting your tip to 2aG, where G is the maximum supply of gas a miner can provide in a block, guarantees that you always satisfy the miner marginal cost?
Now, you have not provided evidence why the marginal costs would be increasing (please do if you have it!), but there are reasons to believe that 1 Gwei is an upper bound of 2aG: whatever the location of your transaction on the supply curve, a 1 Gwei per gas unit tip covers my marginal cost. You could probably make the argument in fact that G (the total tips received by the miner if the block is full and tip = 1 gwei per gas) is greater than b + a * G2 (the total cost to the miner of supplying G gas), which would even cover the fixed cost of sending the block empty (if not for 1 Gwei, then for another value close to that).
This value however is residual compared to what users are currently paying in the current system. Users more than cover the marginal cost. The only question is whether they are overpaying compared to some price that would equalise supply and demand in the current market, and the answer is likely that in some cases yes, in others no.
How about in 1559? The price a user pays, P, can be decomposed into basefee B plus the tip T (P = B + T). The miner doesn’t receive B (in the vanilla version), but receives T. Should T be set to 1 Gwei (or an upper bound we are both happy with), the marginal cost MC to the miner is always covered. I think you are claiming that there are cases where MC < T, in which case the user is overpaying. Although this is technically correct, there are three things to keep in mind:
- The supply curve is probably close to linear: the more linear it is, the less “room” for tips to deviate from some fixed marginal cost.
- Assuming all users converge on an identical “default tip” T Gwei per gas for cases 1. and 3. above, and miners reject any transaction that does not cover at least T, the true overpayment of the user is exactly T - MC, which if point 1 holds, implies T ~ MC.
- Let’s assume that MC is fixed for now and look at two situations. In the first, T = MC, users pay the exact marginal cost to the miner, basefee moves to make supply = demand, users are priced at P = B + MC. Second situation, assume that for some reason, users and miners have decided that T* = 10 x MC. At P*, supply = demand. Basefee will always naturally converge to the equilibrium point, so that P* = B* + T*. Users burn less (B* < B) and more is given to miners (T* > T). But P* = P. Users are overpaying the tip (T* > MC) but they aren’t overpaying for inclusion. I’ll allow that should the marginal costs be increasing, and not fixed, then there technically is room for overpaying for inclusion too. But I maintain that this effect is negligible (and all the more negligible the more marginal costs are fixed, which I believe is a good approximation unless proven otherwise), and not a flaw of 1559.
But no one sets their maximum willingness to pay either, this is an important property of pay-as-you-bid mechanisms: they are not incentive compatible.
I don’t think mutually exclusive is necessarily the correct description. I agree with the extreme cases you mention (the rate set at infinity or at zero), but there is no evidence that a happy middle doesn’t exist. You’ll probably counter: no evidence that it exists either afaiac, I don’t think the exact slope of that tradeoff (is it mutually exclusive as you say, or possible to aim for a healthy mix of the two) will be found before deploying. Until then, accumulating evidence that some forces push the tradeoff one way or another. I am enjoying your posts because you provide tangible ways to do so (I like the counterfactual of increasing the block limit for instance), but I don’t have analysis yet (busy writing walls of texts, promise to stop after this one). We should recognise that even then we’ll need to make some assumptions on the demand (how should they react to increased block space vs a change of bidding mechanism?) so an objective measure of how much better/worse things are is probably unattainable. But evidence of what makes some things better/worse, sure.
Here is one: This discussion obscures the way 1559 bidding strategy works, which was well described by @MicahZoltu as “paying the least amount possible at the time of inclusion”. So the “stability” side of the basefee isn’t its more salient component. In case 1. above, we guarantee next-block inclusion at the quoted price. In case 2., we guarantee that your transaction will be considered for inclusion as long as basefee doesn’t top out your max fee (minus the tip). This is more than can be said of the current bidding grammar: you place a single number, and if you are in case 2., since you most likely have not bid your willingness to pay (because who does in this economy??), your chances at inclusion are dimmer than they would be under 1559, unless of course you are nursing your bid, diligently following the latest oracles and replacing as the market moves.
As I understand it, this is not the only way it was described. In the post basefee is also referred to as a consumer tax that arbitrarily adds cost to the item (transaction inclusion), thereby deviating the equilibrium from its natural point. We’ve spoken at length about its dynamics but since its target is the point where supply = demand, I don’t think this interpretation is correct. As a redistributive transfer, sure.
Yes, I don’t rule out the existence of a middle point people may consider provides acceptable results, my point is just that such a middle point is necessarily going to have to make a compromise between the key advantages people are using as justification for EIP-1559, so it seems worth checking that the result is going to measure up against the simpler alternatives based on some quantitative model.
I agree that it won’t be possible to fine-tune the trade-off based on simulations alone, but it would be fairly risky to move to production completely blind without at least some preliminary evidence that such a happy point may exist and where it might be. I think quantitative modeling should at least enable us to come up with upper and lower bounds for the averaging parameter, e.g. by plugging in a wide range of averaging parameters and demand curves and seeing at which point the system starts developing instability – Indeed it would be intractable to search the space of demand curves exhaustively, but one could expect the damping of any oscillations to be mostly determined by the slope of the demand curve to a first order of approximation, so it would be a good start to use a varied enough set of straight lines as demand curve.
I find on the contrary that the “stability” component is essential for “paying the least amount possible at the time of inclusion”. Such an idealized description of the bidding strategy also seems somewhat misleading because the base fee applied to a transaction has nothing to do with the actual demand at the block where the transaction is included, it’s fully determined by the demand during previous blocks, so without a fair stability trade-off the base fee is going to be disproportionately influenced by the demand at the immediately previous block, which is a random variable that might add substantial variance to the price you pay at the time of inclusion. Furthermore, even if one neglects these random block-to-block fluctuations, this mechanism is essentially going to act as an oscillatory system with an equilibrium point at the target demand, and depending on the marginal demand and price level it might take substantial damping to get the system to converge to any particular value (which you can achieve with a weighting parameter closer to the “stability” end of that trade-off I was discussing). Instability is your enemy if you’re trying to pay the least amount possible at the time of inclusion (of course unless you’re trying to game the system and take advantage of the oscillations in order to pay a price below the market price, but then you get to give up any usability benefit ).
I think it’s technically possible for the imposition of a base fee to disturb the equilibrium point between supply and demand, particularly under increasing centralization of hashpower. That said I agree with you that under present conditions it’s unlikely for the base fee to significantly alter the equilibrium point between the supply and demand curve, but only because the hard supply cap causes the supply curve to look pretty close to a vertical line in a neighborhood of the current equilibrium point, so it’s unlikely for a shift up or down to significantly disturb it: However the same can be said about any consumer tax for a good whose supply curve has the same peculiarity, so I don’t think that invalidates @editor-Ajian 's analogy (E.g. compare it with the effect of a government heavily taxing some luxury good with essentially fixed supply, wouldn’t make it less of a tax ).
1 Like
I just want to add to this post.
I know some of the devs here do not look favorably towards GPU miners. But when the time comes to switch to PoS you’ll be better off with a network made up of GPU miners, than a network filled with these ASIC monstrosities.
Since other Ethash-based currencies are worthless, these horrors would become instant paperweights. As such, ASIC miners will have every incentive to delay, derail and prevent PoS. We saw the force of the ASIC propaganda machine when they essentially killed EIP-1057 (ProgPow).
GPU miners, meanwhile, will have other options**.
EIP-1559, as it currently stands, threatens to slash miner profits by making a flawed attempt at hardlining the “minimum necessary issuance” policy through fee burning. Essentially weeding out the (least profitable) hobby miners and promoting a network of large-scale centralized ASIC dominance.
Minimum issuance fosters minimum security.
Keeping a stable issuance, as Ethereum has always had (and EIP-1559 can continue with the ℓ-smoothed mechanism), promotes a healthier, more decentralized, PoS-ready network.
** Mining a different coin, selling the GPUs to gamers / creators / researchers, giving back by doing Folding@Home or similar.
2 Likes
On this I’ll just say that this actually ongoing work, please reach out with you are interested! (I can’t DM here yet because I am new to this forum, but you can also find me on other platforms) We are starting to get some interesting results too.
I’d also like to look at how deployed instances of eip1559 work, with the caveat that their environment differs from Ethereum’s of course (Filecoin and Celo are the two I know of), but it’d be cool to see if that instability is present.