Research Area: L1 Fee Abstraction

[tynes]

Right now, the L1 portion of the fee is defined in native code. With various hardforks, the fee calculations are changed. This adds tech debt to the state transition function as there becomes more branching logic depending on the currently active chain spec. For example, ecotone introduces a new fee formula and fjord may introduce a new fee formula. This means that every op stack execution client needs to support this branching logic.

It is possible to use EVM bytecode instead to define the L1 portion of the fee. A solidity interface could be defined that accepts the RLP encoded transaction and potentially some other data and it is expected to return a uint256 that represents the L1 fee or the L1 gas used. This would remove altering the fee logic from being a hardfork and increase the social scalability of fee logic discussions as any team working on the OP Stack can choose to use their own fee formulas that work best for them. There should be some standard EVM bytecode that comes with the OP Stack that can do a good job of this fee charging so that teams don't need to think about this problem unless they really want to.

There are some performance considerations of this approach. Benchmarking is required to learn how much of an impact this would have on syncing. Spinning up an EVM instance to do this calculation will always be slower than running the calculation in native code. It is likely that it should be a STATICCALL context, ie no writing of state because that could result in some strange side effects. The only application of writing state would be to write the L1 fee to transient storage such that smart contracts would be able to access the value only during the execution of the particular transaction, this could be useful for meta tx relaying.

Another concern is how the L1 portion of the fee isn't committed to by the user's signature. There may have been some work done to attempt to standardize a "multidimensional fee transaction for L2s" that could help with this problem. If the smart contract can be swapped very quickly, then it may be possible for the network to overcharge end users for their L1 fee because they cannot express a "max amount of L1 fee" they are willing to pay. It is possible that this logic could exist in the smart contract doing the L1 fee charging itself, this could work well with smart contract wallets. This is already an issue for what its worth, as the chain operator can bump the L1 fee params in the SystemConfig arbitrarily.

[tynes]

This could be extended to support more than L1 fee abstraction but instead abstract the full fee payment. This would be more intrusive to EVM equivalence, but would enable a lot of experimentation. It is possible that only abstracting the L1 portion of the fee is enough. We would want to think through the exact data passed into the smart contract if we were abstracting the entire fee payment. Likely we would want gasUsed, success and the raw transaction data.

[tynes]

This could also be used for MEV rebates by reducing fees for users that need a rebate. A mechanism for tracking who deserves rebates would need to be developed. This could be managed by the chain operator as an oracle, or on chain applications could track this information. For example Uniswap v4 hooks could be very useful for automating the process of determining who deserves MEV rebates