feat: gas costs

[mds1]

Data to include

• The 21,000 intrinsic gas cost, calldata costs, etc
• Opcode gas cost differences. We already have their gas costs are in the opcode section, but differences should be listed here for completeness. We can import the opcode data as a starting point, since it has gas costs.
• Things like memory expansion cost, SSTORE rules, access lists, refunds. This and this are good references for mainnet gas costs.
• L2s post calldata on L1 which should be accounted for
• Gas limit
• Comparison of EIP-1559 parameters, since they can be adjusted
• Maybe can show estimated transaction costs using something like https://l2fees.info/ (however we don't currently have any async calls and I'd like to keep it that way for now)

There's a lot here, so consider splitting this into multiple PRs for simplicity. There also might be some duplicate data from #35 so consider how to reuse the data

Between #35, #37, and the existing opcode data, I think this PR will add little new data and simply reformat existing data

[PaulRBerg]

This would be so, so helpful.

There are several configuration parameters in Sablier that depend on (i) the block gas limit and (ii) the EVM execution costs.

We are currently relying on several heuristics to estimate the proper config values for L2s, one of which is to assume that the block gas limit is lower than what it actually is.

The 21,000 intrinsic gas cost

Any thoughts on referring to this as the Minimum Transaction Gas?

[PaulRBerg]

Sharing some relevant documentation sites:

• Optimism: Transaction Fees on OP Mainnet
• Arbitrum: Gas and Fees
• Scroll: Transaction Fees
• zkSync: Fee Model

And some relevant findings:

• Optimism and Scroll are the most similar to Ethereum Mainnet since they have L1 gas limit and price fields in txs
  • Optimism uses EIP-1559, but Scroll doesn't
  • The L1 data fee is automatically deducted from the user's account; there's currently no way for users to opt out of this, although Optimism is working on a new standardized transaction type that will fix this
• Arbitrum bakes the L1 data fee into the L2 gas limit, which means there are no additional L1-related fields in txs, but the minimum transaction gas is higher (based on my latest estimations, it's 37k gas now)
• zkSync is the most complicated fee model of the bunch. Gas consumption fluctuates a lot due to their bespoke VM design, especially (i) native Account Abstraction and (ii) state diffs.
  • For example, two consecutive simple ETH transfers on zkSync cost 183k gas and 124k gas

Related:

• Do all EVM chains use the same minimum transaction gas of 21000?
• Is there any comprehensive documentation on how gas metering works across EVM chains?

[PaulRBerg]

More references from the Sablier code base:

• The heuristic to subtract 1 million gas to estimate max counts is OK sablier-labs/lockup#932
• test: add gas benchmarks sablier-labs/lockup#908 (comment)
• Robust script for estimating the max segment and the tranche counts sablier-labs/lockup#872

[mds1]

Notes:

• Gas scheduling is complex and it will be hard to cover everything perfectly.
• feat: add tests for opcode behavior #67 may include opcode level gas tests as well.
• Minimal useful implementation of gas data is to just run a handful of eth_estimateGas calls for common, simple transactions and compare the resulting gas costs. I suspect most chains support state overrides so we should be able to use those to inform the results.
• For chains that bake L1 gas costs into their gas limit (e.g. Arbitrum), the JSON files will change every time bun fetch-data is run. We will need to add handling for this expected difference to avoid the hourly CI checks from constantly reporting diffs.

[fvictorio]

From #4:

1559 data is tracked as part of #31, unsure yet if its feasible to detect parameter values automatically.

While I suspect that 1559 parameters are hard to detect automatically, it would be relatively easy to check that some given parameters are correct, right? We can fetch the last n blocks ans assert that the sequence of basefees behave as expected.

[mds1]

That's true. I plan to refactor things a bit so each chain has an input file, and 1559 parameters could be an input. But then the question becomes: What to report when the check fails? These parameters are not always well documented, so manually finding and updating them might be hard.

Actually, maybe the 1559 params can be backed out by looking at the last n blocks by rearranging the equation used to compute the next basefee? Some chains like arbitrum and polygon PoS behave a differently though, so we might need to use the chain input files to describe their deviations

[koonopek]

When I was writing about gas diffs on evm I was thinking about models - how gas is calculated and passed into transactions.

There are currently two models:

• AuctionModel
• EIP1559

Additionally some of the L2s uses two dimension gas prices

At Redstone we are currently maintaining list of fee models per evm network (not all, but many). You can find it here:
https://github.com/redstone-finance/redstone-oracles-monorepo/blob/4bcf002f7fd907e596b2bb1fe327710dfdd3bd6e/packages/rpc-providers/src/chains-configs/index.ts#L42
(there is already PR which will convert it to json format)

Two variables that should be interesting are:

• isAuctionModel if false then is EIP1559 :)
• twoDimensionalFees

However, there are many edge cases like arbitrum is supporting eip1559 but the priority fee, in reality, is constant 0.1gwei.
Nevertheless, displaying in the table would be super helpful for projects integrating them. We will be for sure mainating our list so you can use info from there.

Love your work!