FeeOracleV2

[kevinhalliday]

Problem to Solve

Our current fee oracles do effectively keep us "in the green" (charging more in fees than our relayer spends on gas). They could, however, use some improvements.

Data / non-evm pricing

FeeOracleV1 uses a "postsTo" mechanism to deteremine the data gas price for an xmsg. It uses the configured gas price of the "postsTo" chain to charge data fees for an xcall. This means that calls to L2s use the execution gas price of L1. Most L2s now post tx data as blobs, and blobs have an independent fee market. We need to update the fee oracles and xfeemngr to configure and charge xcall fees based on blob gas prices.

Additionally, our pricing is pretty evm specific. We should consider what it would look like to include a non-evm chain. We may well be able to "translate" non-evm chains into our exisiting evm-esque parameters. But we should consider what this would look like.

Overheads

Sigma prime suggested some "overheads" - for data costs / gas prices.

Requires active management

The current fee orocle contracts and monitor/xfeemngr do a lot of on chain transactions - can we reduce that cost? We want to remain "in the green". We also do not want to overcharge fees too much.

Proposed Solution

FeeOracleV2 was intrduced, but is unused. This version uses explicit dataGasPrice, rather than postsTo mechanism.

This may be all we need. Though it may not. The owner of this task should read the sigma prime report, as well as our responses to their suggestions. They should also look as mainnet / omega metrics.

Then, design, propose and implement both the

• new fee oracle contracts
• new xfeemngr
• a process for upgrading live networks (omega & mainnet) to the new oracles

[Zodomo]

I was able to significantly decrease gas consumption in our bulkSetFeeParams() function in FeeOracleV2 by ~45% in #2291. This will make it substantially cheaper for us to operate it. However, I am reopening this issue as there might still need to be some discussion about whether the change to also targeting the appropriate L1 fee market (be it blobs or calldata) is sufficient, or if we have any alternative strategies worth pursuing.

I do think that execution and DA costs are the only things necessary for a fee oracle. As we can uniquely configure it for each route, we can handle differences between EVMs and non-EVMs. There isn't a way for a L2 smart contract to know if its L2 is posting to L1 using calldata or blobs, so it is on us to reconfigure the oracle's prices if such switches happen. To date, I don't know of any L2s that have switched between calldata and blobs frequently. However, this may change when the blob market is saturated.