FeeOracleV2 #1951
Comments
kevinhalliday
changed the title
Add FeeOracleV2 contract. - fee oracle v2 uses explicit data & exec gas prices per chain - add version() view on fee oracles issue: #1951
|
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. |
Created a FeeOracleV2 deployment routine that uses Create3. We cannot upgrade FeeOracleV1 as V2 has a different storage layout. This routine does not currently include upgrade logic. issue: #1951
FeeOracleV2 Create3 salt was missing. issue: #1951
Generation of FeeParams for L2 Sepolia testnets was failing as Sepolia isn't in the manifests for staging or omega. Default gas prices to 1 gwei for non-mainnet manifests. issue: #1951
Refactored FeeOracleV2 such that data cost fee updates can be made once and update all execution layer pricing for all chains that post to any given data layer. Also, conversion rates are set independently, which updates pricing for all routes that rely on them. issue: #1951
This adds an admin command to upgrade the `feeOracle` address on the OmniPortal contracts to the FeeOracleV2 address. issue: #1951
Refactored FeeOracleV2 such that data cost fee updates can be made once and update all execution layer pricing for all chains that post to any given data layer. Also, conversion rates are set independently, which updates pricing for all routes that rely on them. issue: #1951
This adds an admin command to upgrade the `feeOracle` address on the OmniPortal contracts to the FeeOracleV2 address. issue: #1951
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 thanpostsTomechanism.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
The text was updated successfully, but these errors were encountered: