Research Area: Consensus Level Tracking of Chain Revenue/Expenses

Right now there are various config values in the L1 system config smart contract that are related to the fees charged on L2. These values can easily be set in a way where it causes the chain to not be profitable or to overcharge users by a lot. In an ideal world, the chain operator can just specify their profit margin and the chain should be able to automatically adjust fees by introspecting the revenue and expenses as part of the derivation pipeline.

The derivation pipeline already observes all L1 transactions, it would just need to compute the gas used of the transactions sent by the batcher to know the expenses of the chain. It would need to observe all L2 receipts to learn the revenue of the chain. It could use the expenses and revenue as inputs to a deterministic function that sets the scalars/fee config in the L1 block attributes transaction instead of referencing L1 events for changes to the scalar values.

The revenue and the expenses can be included as part of the L1 block attributes transaction to make it possible to introspect on the chain's economics at the application layer. This would enable applications such as revenue sharing.

The system config on L1 would no longer hold gas config that is pushed into L2 but instead it would hold a target profit ratio.

This feature can easily be broken up into 2 parts, the first would simply enable the introspection of the revenue/expenses via the L1Block contract by pushing the values as part of the L1 attributes transaction. The second part would be completing the automatic targeting design to simplify config for chain operators.

Start by reading the derivation pipeline, the L1 system config smart contract, and the L1Block contract references in this issue. Separate the proposed work into exposing revenue and expenses through the L1 attributes transaction and designing automatic fee targeting from those values. Done means the required inputs, deterministic fee behavior, and target profit ratio are specified clearly enough to implement.

Written by the indexing model from the issue text.