Closed sambacha closed 2 days ago
Add support for L2s
Arbitrum
Arbitrum gas units are different: opcodes are priced differently, so swaps as an example, cost different amounts. Arbitrum has 2 separate gas meters- one for compute and one for storage On Arb its not clear if we capture everything we need by querying eth_gasPrice (also unclear if we need to capture both when estimating gas)
Optimism
Optimism charges a fee based on the size of the calldata that would need to be sent to L1 On Optimism for example eth_gasPrice always return 1000000
yea this is no longer true with nitro which is now live, opcode gas usage is now the same as L1. eth_estimateGas returns different values (and therefore gas limits are different) though because it adds additional gas to account for L1 costs
Optimism, which calculates the transaction size (distinguishing between zero and non-zero bytes, leading to different costs akin to Ethereum) along with associated gas costs. In contrast, Arbitrum dynamically computes the L1 fee based on an estimated transaction size (without distinguishing between zero and non-zero bytes, but charging a uniform 16 gas per byte) and gas cost, incorporating dynamic and flexible additional components. Furthermore, in Arbitrum, a transaction incurs L1 gas fees only if it is part of a sequencer batch and not sent directly to the L2 contract on the L1, whereas this distinction does not seem to apply to Optimism.
Add support for L2s
Arbitrum
Arbitrum gas units are different: opcodes are priced differently, so swaps as an example, cost different amounts. Arbitrum has 2 separate gas meters- one for compute and one for storage On Arb its not clear if we capture everything we need by querying eth_gasPrice (also unclear if we need to capture both when estimating gas)
Optimism
Optimism charges a fee based on the size of the calldata that would need to be sent to L1 On Optimism for example eth_gasPrice always return 1000000