Gas on Avalanche
Dame mas gasolina!
As a web3 participant (at current prices, we call them ‘community members’) you’re probably aware that when you send a transaction ‘gas’ is spent from your account.
But it’s likely that you don’t actually understand too much about the mechanics of how much you’re paying and why. Hell, even the people running one of the largest protocols on Avalanche don’t seem to understand how it works.
So I’ve written up a short explainer on the topic! I’ll try to keep it ELI5, enjoy.
Transaction types
The EVM has two different ‘transaction types’.
Type 0 is the ‘legacy’ type, where you specify the exact gas price you want. You always pay exactly what you specify, assuming your transaction is accepted.
Type 2, aka EIP-1559, where you specify a ‘max price’ and a ‘tip’. The max price is the most you’re willing to pay; in practice you will end up spending less. The tip, on Avalanche, is mostly relevant for in-block transaction ordering.
If you’re writing software to send transactions, you should (almost) ALWAYS use type 2 transactions to save users gas.
Don’t ask what happened to type 1 transactions.
RPC nodes, validators, mempool
When you submit a transaction, you’re typically sending it to an ‘RPC node’, not a validator directly. The RPC node will propagate it to multiple validators, who will also gossip it to other validators.
The validators all have a pool of unmined transactions (the mempool) that need to get included into blocks. Every 1-2s the next ‘leader’ will build a new block from the contents of the mempool and broadcast it out to other validators to reach consensus.
Block building
The leader wants to build a block containing as many transactions as possible (assuming they pay enough gas). It won’t randomly skip a transaction it knows about in the mempool that could be included. Two things limit the TX that can be included.
Gas price vs units vs cost
People say ‘gas’ a lot but they’re not always specific about what they’re talking about. There are four things they could be referring to:
Gas units - when a TX is executing, it consumes ‘units’ of gas. It costs 21,000 units of gas to do any transaction, e.g. to transfer native. It costs more depending on what you do; e.g. to send native to 2 addresses, it will cost about 26,000 units.
Gas limit - a TX needs to specify how many gas units it’s willing to consume to complete. If the gas limit is less than the actual amount of gas used, the transaction fails.
Gas price - the amount the TX spends PER UNIT to execute.
Gas fee - the total amount the TX actually consumes, which is gas price * gas units.
Block gas price
Each block has a ‘base fee’ that needs to be met in order for a transaction to be included. This fee is dynamic, updating over time depending on load.
Assuming every TX in the mempool is willing to pay the minimum fee, the leader will attempt to fit every transaction available into the block. TX in the pool specifying below the current fee will be delayed to future blocks.
Gas limit
Every block has a limit on the amount of gas that can be included. Historically this limit is 15M units of gas, but recently became dynamically adjustable.
Every TX also has a gas limit, but the thing that matters to the block is the amount of gas USED by the TX. The sum of all gas limits for all TX in the block could be enormous, but the sum of gas used for all TX in the block needs to be below the limit.
The leader
Every validator knows which validator is eligible to produce the next block (their ‘slot’) through some complicated math. If that validator doesn’t produce a block, other stuff happens but it’s not that important, slots are rarely skipped.
All you need to know is that typically it’s the job of one specific validator at a time to stuff transactions into a block.
Inclusion and ordering
On Ethereum and some other chains this is more complicated, but on Avalanche it’s pretty straightforward.
The transactions the leader knows about (its mempool) are filtered by fee (every tx willing to pay the current block fee), then sorted by fee (total amount for type 0, base cost + tip for type 2), and processed in order until the gas limit is reached.
The fee you pay determines which TX comes ‘first’, but as long as the gas limit isn’t reached, any TX willing to pay the minimum fee gets in.
Block fees
Great, so how do we determine what the actual fee is for a block? You might remember that for the last few years, the minimum fee you could pay was 25 gwei.
Recently, ACP 125 updated this fee to 1 gwei.
Even more recently, ACP 176 reduced the minimum fee further (I have no idea how it works now)!
But the fee has always been dynamic above that minimum, in proportion to the amount of gas consumed by recent blocks. The old mechanism used a pretty ridged windowing system that checked the amount of gas consumed against a ‘target’ value.
I don’t fully understand the ACP 176 update, but it seems to use a more flexible mechanism that will scale up more smoothly and scale down more quickly. You can review the simulations if you want.
The goal of increasing the gas price is to keep validator requirements reasonable. The TLDR is ‘more gas used, higher gas price’.
Case study
It was by no means a new and unique idea, but at one point I wrote some scripts to consume all the gas used on the chain for about a minute, effectively blocking out a series of lower priced transactions so I could win a contest.
During this exercise, I ended up spiking the gas price and costing myself a big chunk of avax to pay those fees (worth it). But this was under the old regime of 25 gwei minimums and the fixed window size gas pricing.
Typically nowadays gas price only spikes high when there are violent price fluctuations, as bots race to liquidate people’s positions and arbitrage liquidity pools. The ‘normal’ elevated load rarely exceeds 50 gwei, even during token launches.
But I am curious to know how this works now during a period of significant demand. Rather than speculate, let’s test! I wrote a quick script to consume a lot of gas and send out some TX from a few different accounts.
I consumed enough gas to do about 350 swaps, plus there were some other user TX in there. Let’s check what happened to gas before and after.
It only went up by .5 gwei, not a particularly significant increase.
Back to the start
Alright, so let’s review what actually happened during the $boi launch. What was gas usage like?
Pretty easy to spot where trading opened, and you’ll notice that all the blocks after that are well under target gas, much less the actual gas cap. Starting gas was .12 gwei, 30s later it was .26 gwei, 30s later it was .38 gwei.
I don’t know what you consider a ‘snipe’ but 60s after launch seems well out of snipe range to me.
So very, very wrong
Let’s review the cryptofish special from yesterday (that’s when you double down every time you’re confronted with evidence instead of admitting fault).
Yes, blame the user for your shitty code, off to a great start.
Would take less time to look at the explorer and disprove this than it took to type.
The TX being delayed by a single block seems obviously unrelated to the TX failing.
Why would you give an example that is so blatantly incorrect?
You can pay any fee you want to get included, it has nothing to do with the amount it COSTS to get included.
No… no I did not. And I didn’t ask that because that information isn’t relevant to the issue at hand.
This is obviously someone using Chat GPT (poorly) to reply. My money is on cryptofish but maybe they hired a retarded intern after Blue left, who knows.
Anyway, very ballsy of a web3 protocol to go the route of insulting their users, provide factually incorrect information, and double down after being corrected.
A ella le gusta la gasolina
golf clap