VRFV2Plus L1 fee calculation updates for Optimism and Base

[ibrajer]

Motivation

Optimism provides a way of calculating L1 gas fees via a predeploy OracleGasPrice contract. Gas usage of this gas calculation function is too high. This is an attempt to reduce the cost for the customer, but also to provide several options to calculate L1 gas fees in the future (after the Fjord upgrade).

Overview of changes

The most major change for Optimism is incorporating three different versions of L1 fee calculation:

• using the getL1Fee function on predeploy OracleGasPrice contract (the most accurate one, but gas expensive)
• using getL1FeeUpperBound gas cost approximation on predeploy OracleGasPrice contract (upper bound calculation available after Fjord upgrade), this is used with having a pricing coefficient in mind to reduce overcharging
• using our estimation built on top of the getL1Fee calculation for Ecotone (with average payload data layout taken into account), this is used with having a pricing coefficient in mind to reduce overcharging

The changes above inspired (and forced) some other necessary changes to existing contracts:

• extracted L1 fee calculation away from the VRFCoordinatorV2_5 and VRFV2PlusWrapper contract to separate abstract contracts OptimismL1Fees and AbritrumL1Fees
• combining L1 fee calculations necessary for the VRFV2PlusWrapper contract in a new single VRFV2PlusWrapperL1Fees contract (replacing ChainSpecificUtil used before), abstracting this calculation away from the VRFV2PlusWrapper
• created new coordinator contracts specific for Optimism and Arbitrum (with L1 fee calculation and other L2 opcode specifics on top of the base VRFCoordinatorV2_5 contract)
• applied several Coordinator contract size optimizations according to this branch so that VRFCoordinatorV2_5_Optimism doesn't break the contract size limit (thanks to @leeyikjiun)
• recalibrated padding size on Optimism and resolved incorrect padding issues (thanks to @jinhoonbang)

[ibrajer]

Seems like we are breaking away from ChainSpecificUtils? We need to revert the changes in ChainSpecificUtil.sol

The memory to calldata changes might break if there are existing contracts, for some weird reason, that are calling it with memory,

Yeah, ChainSpecificUtil.sol is no longer used so I think it makes sense to revert back...

[cl-sonarqube-production[bot]]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube