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.