feat: support multilayer gas fee reporting in gas reports and deployment scripts

[dghelm]

Component

Forge

Describe the feature you would like

For L2s that have "total transaction fees" that include both the L2 gas fee and an L1 Data Fee (also taken from L2 account, but depend on callData size and gas prices on L1), it'd be helpful for gas reports and deployment scripts to include L1 Data Fee context.

My own use case would be for helping developers understand the differences in optimizing for gas usage in an L2 environment, although I'm hopeful actual projects would be able to use it for better insight into how their contracts will perform on an L2.

For example:

Chain 534351

Estimated gas price: 7.6143807 gwei

Estimated total gas used for script: 510867

Estimated amount required: 0.0038899358250669 ETH

would include an additional Estimated L1 Data Fee that would also be added into the amount of Estimated amount required.

In a Gas Report, this might be complicated, as the L1 Data fee will only really be useful for developers if the contract will be called by an EOA.

Additional context

Not all L2s expose this fee to users. AFAIK, Linea and Arbitrum just adjust gas fees to account for this cost and abstract it from the user, maintaining gas_estimate as the full transaction cost.

Scroll and OpStack networks, however, do have this fee.

This is related to the bug at #4903 and feature request at #5733, but the solution there seems much more nuanced (and supportive of highly divergent gas schedules) than something more basic like what MetaMask implements for MultiLayer Gas Fee prediction (which essentially just calls the L1GasOracle if you're on a chain listed as "MultiLayer Gas Fee").

More context on L1 gas fees: https://docs.scroll.io/en/developers/transaction-fees-on-scroll/ https://community.optimism.io/docs/developers/build/transaction-fees/#the-l1-data-fee

[dghelm]

Also, although slightly intimidated as I'm new to Rust, I'm happy to take a stab at a PR if pointed in the right direction (or even just implementing the Scroll fee calculation code).

[ankurdubey521]

@dghelm I'm interesting in working on this as well! I could look into implementing the Optimism Fee Calculation Logic

[zerosnacks]

This is a great point: our tooling can no longer assume a base case of Ethereum mainnet but has to reflect the reality of a multi-chain / rollup-centric future.