Closed saurik closed 3 years ago
...if the value of AVAX were still closer to $6 (as it was for a while right after launch) the cost would be only around 1/9th.
(Right now, AVAX is on its way up, currently trading at $4.59; meanwhile, ETH is holding at $345 its gas prices are down to 55 Gwei... so, we are now already at the point where the cost advantage of using AVAX is down to under 1/9th.)
(With Ethereum prices continuing to go down--Ether is at $339.46 and gas is down to 33 Gwei--despite AVAX also being down to $3.44, the cost advantage of Avalanche over Ethereum is now under 1/7th... it would now really suck if AVAX starts trading up, lol ;P <3.)
OK, so a month later: Ether is up to $383.27, but gas prices are down... to 15.1 "standard"; with Avalanche holding at $3.35, this means Ethereum is now only 3.65 times as expensive as Avalanche (this is getting into some pretty dangerous territory ;P).
Came here to say this issue aged very well indeed :). AVAX $52, ETH $1,745 Crazy times we live in.
Are there any explainers as to exactly why gas price is fixed? What makes dynamic gas prices difficult to implement?
@smartcontracts I am not from Avalanche, but I'm the person who filed this issue (and I doubt at this point that they will show up to talk about it even we mention them some more, as it has been half a year of silence at this point, so let's see if me musing on the subject for a while causes them to show up and correct me ;P).
When I asked them about this a while ago on Discord, I'd gotten the following response back from @danlaine.
This is a good point and something we've though about. We might change the tx fee model going forward to ensure they don't get out of hand. We want txs to be cheap. Unlike Ethereum, the block "miner" in Avalanche doesn't get a reward so the market economy for gas prices doesn't map nicely.
So, unlike in a system such as Ethereum, Avalanche doesn't quite have a similar notion of a block gas limit, and there is (likewise) no target rate of block production, which makes it non-obvious how to exactly describe any potential scarcity on gas, and without scarcity you don't really have a market. I mean, even higher-level: since Avalanche isn't currently even remotely "loaded", why isn't the fee nearly 0, right??
The "usual" solution to this on most chains is that block producers know their costs and insist on getting paid a fair rate, and then only put transactions in blocks that make them profitable: if a transaction bids so low that no one is really willing to put it in a block as it costs more money to process it than it would to execute it, then none of the block producers are going to include it... but Avalanche doesn't pay the people who put together and make blocks--FWIW, I think that just doesn't map well to their consensus algorithm--and so this natural economic control system doesn't exist.
This means that you instead need to have solutions that are independent of miners to decide which transactions get included, bringing me to having mentioned EIP-1559 earlier... but the issue I've been realizing with that is that there isn't quite a block rate you could target with Avalanche, even based on time or something, as the system is so asynchronous (which is a good thing: like, that property is one of the key things that made me really care about Avalanche in the first place).
The result--and this is such a cop-out--is that they just hardcoded it :/. And like, they had to have something, as they need a reason for people to bother running the system, and I don't think they really have any kind of inflation on the system (which is actually a bit awkward, as I don't really understand the economics of how the system works when it is quiescent, something they had been adamant they supported correctly). The alternative would probably be the standard "deus ex machina" of blockchain: "decentralized governance" (which is almost always something coming in the future, and not a concrete plan).
We've largely had the discussion around this internally, but this is a fair critique both of the current fee system and not being more transparent with our roadmap. We are currently working on a dynamic fee system to address this in the very near future.
(I was asked by @danlaine to bring this issue, which I noted a few days ago and which has been coming up occasionally both from myself and from someone else I don't know who was looking at the economics of running their DEX on Avalanche, from Discord to GitHub.)
The gas price on the various Avalanche EVM chains (C-chain, Athereum, etc.) is hardcoded; and I see #39, but in addition to only applying to other subnets, this is still just letting the subnet select a different genesis-hardcoded price, not resulting in a change of model. What makes this extremely problematic is that it means the transaction price of your network is thereby tied to your token price's volatility--which could fluctuate based on things like speculation and news/political cycles--as opposed to being any reasonable indicator of the cost of computation or bandwidth. In contrast, on Ethereum, if the price of ETH doubles, the cost of gas should quickly halve. With Avalanche, if the price of AVAX doubles, so does the cost of using the network, which has literally meant that I'm rooting for the value of the token to crash and stay depressed, so that the network is more usable... "awkward" ;P.
To provide what is hopefully a useless example of the kind of discussion surrounding this, I work on a project (Orchid) that sells bandwidth, and having this hardcoded gas price concept would be akin to the naive assumption many people seem to have about our product: that bandwidth costs are somehow fixed in OXT at like, 1 OXT / GB, and so people then ask us "how will the volatility of your token affect the viability of payments" and the answer is "it won't, as this is all based on market economics: if the token goes up the price of bandwidth as measured in that token will go down, as in some real sense the price of bandwidth is fundamentally measured in something like the price of bread and other staples; the amount of value from the user required to get bandwidth should only change if the price of networking in the world changes". Only, for Avalanche, this naive model is in fact how it works and is in fact going to be a problem.
As this value is currently hardcoded at 470 (a very recent change from 47 in https://github.com/ava-labs/coreth/commit/dd6b0315849e2383e715e9c0ade50aaca68435f0), the price of transactions on Avalanche are only 1/14.5th the cost of Ethereum right now; and it must be noted that the spread is actually only this high because the value of AVAX has been falling... if the value of AVAX were still closer to $6 (as it was for a while right after launch) the cost would be only around 1/9th. If the value of your token (awkwardly, "heaven forbid") goes up, that means that the usefulness of it over Ethereum will actually decline--and possibly quite quickly--if anyone deploys anything important that actually uses it (as opposed to merely encouraging people to start staking and running validators before you even have users, which is what you have been doing ;P).
I mean, already, the prices of Avalanche are kind of ridiculous for a system claiming to be so much fundamentally more economically viable than Ethereum, as while <10x is still better than nothing--and I appreciate that a key property of Avalanche is that it will (supposedly) scale to a lot more users and keep that same price--the price of Ethereum is and was already way too high for a lot of people, so merely being more scalable but not actually being drastically cheaper is, at least in the short term, kind of a massive let down: there are numerous other systems out there that have been in production longer with real users and which are also Ethereum compatible but which are offering prices that are already 10-100x lower than Avalanche, and that's with so-far zero usage of Avalanche (as the C-chain hasn't actually launched yet) and a falling token price.
FWIW, EIP-1559 has a mechanism proposed for Ethereum which is in many ways similar to the gas model used by Avalanche, which has people burning their fees rather than paying it to miners. In it, Vitalik et al discuss a model of shifting this fee based on the "percentage of the previous block" that is used. Now, I appreciate that Avalanche doesn't have blocks that work like this, but if you re-model gas target as "gas used per time" instead of "gas used per block" then you can probably use very a very similar algorithm to the one from EIP-1559 to auto-calibrate your gas price over time. (Not saying this is what you should do; I'm actually more a fan of the recently-released EIP-2593, which happens to be almost identical to the solution we had come up with for our layer 2 nanopayments--interestingly, ours is also in terms of time, while theirs is in terms of blocks ;P--but the current hardcoded concept and specific value are both unreasonable/concerning).
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md