[Application Development] Why is the gas limit returned by estimateGas enough?

[compojoom]

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

I'm trying to figure out how gasEstimation has changed after the ecotone update. According to these docs:

https://docs.optimism.io/builders/app-developers/transactions/fees

OP Mainnet transaction fees are composed of an Execution Gas Fee and an L1 Data Fee. The total cost of a transaction is the sum of these two fees. Continue reading to learn more about exactly how each of these fee components are charged.

In our application we currently only do ehters v6 provider.estimateGas, we don't calculate the l1 data fee. Despite that the TXs are going through. Why is that? If we are supposed to do the estimation with l1data fee it means that currently we are setting our gas limit with 5k (for some txs) less than it should be. However, what I see from the tx execution right now is that the TXs we submit use 94-96% of the set gasLimit. So apparently the default provider.estimateGas returns a high enough value, but why is that?

Additional Information

No response

Feedback

No response

[sbvegan]

Can you walk us through how you estimate gas (a code snippet would be helpful)? and can you confirm you're not using ethers/ext-utils-optimism?

Ether's estimateGas

Estimates the required gas required to execute tx on the Blockchain. This will be the expected amount a transaction will require as its gasLimit to successfully run all the necessary computations and store the needed state that the transaction intends.

So this would give you the L2 gas, but not the L1 gas. My initial assumption is that using the blob space to write to L1 has reduced the cost enough that at current demand the L1 aspect is negligible.

[compojoom]

Up till today, we only did provider.estimateGas without taking into account the l1 data fee.
Here is a PR I did: safe-global/safe-wallet-monorepo#3490

You can see here: https://github.com/safe-global/safe-wallet-web/blob/b0b0106825f7ecc925b57be8e426ef3cab4ccfe9/src/hooks/useGasLimit.ts#L180 - er only did estimateGas and that has worked fine so far.

[hash1go]

In OP Mainnet, L1 Data Fee doesn't directly depend on gas usage of L2. So, whether there's an Ecotone update or not, the L2 gas needed for a transaction remains the same.
Your use of ethers v6 provider.estimateGas works because it sufficiently estimates the needed L2 gas, even without considering the L1 Data Fee.

[compojoom]

Hey! Thanks for the reply!

I honestly don't get it. Do we need to add the L1 Data fee or not? The docs suggest that we do need it and ext-utils-optimism also ads it. Should we adopt ext-utils-optimism approach? or leave it to ethers provider.estimateGas

[hash1go]

You'll need to ensure that there's sufficient ETH in your EOA to cover the L1 Data fee. However, it's not necessary to add L1 gas to the L2 gas limit. The reason a transaction on the OP Mainnet might fail is due to the gas usage exceeding the L2 gas limit, not because of L1 gas considerations.
Regarding tools for estimating gas, I haven’t used any myself, so I can’t offer advice on that front.

[compojoom]

Well, if that is the case you might want to clarify this in the docs: https://docs.optimism.io/builders/app-developers/transactions/estimates It's really not clear. To me it seems that we have to calculate the execution gas and also the L1Data gas and then send those 2 together as a gaslimit. In the section for tooling you have linked to ext-utils-optimism which does exactly this, and that gives one even more the impression that we should do this.
Why is the L1 Data fee listed there if it shouldn't be part of the gasLimit? Why should one calculate it?

[hash1go]

Thank you for the feedback on the documentation.

This section explains transaction fees. Before the Ecotone upgrade, the L1 Data Fee was determined by multiplying L1 gas by the L1 gas price. That's why there seemed to be instructions on how to calculate L1 gas.

With the Ecotone upgrade, the formula for calculating the L1 Data Fee changed.
https://docs.optimism.io/stack/transactions/fees

However, to potentially enhance the clarity of the documentation, I might consider adding a note explaining that there is no need to combine the two gas limits.

[compojoom]

Hey! One thing poped up in my head.

The Docs also say that the preferred way for doing gas estimation would be to use "tools". One of the tools listed is:
https://github.com/ethers-io/ext-utils-optimism

This tool does gasEstimation by first doing provider.estimateGas and later adding the l1DataFee to it. Now you are saying that this is not necessary? So shouldn't ext-utils-optimism be updated to reflect this?