An alternative to the “L2 inflationary minting” design in the OP:
Instead of supporting minting on L2, minting could just be supported on L1 and any minted tokens would be migrated via a gateway to the L2 Minter. A reward transaction would still be submitted by orchestrators on L2 during each round in order to distribute rewards to the orchestrators and its delegators, but the reward transaction would not mint any tokens since tokens have already been minted and migrated to the L2 Minter from L1. In order to reduce L1 tx costs, rewards could be minted and migrated from L1 less frequently. For example, suppose a round on L1 is 7 days and a round on L2 is 1 day. Rewards could be minted and migrated at the beginning of every L1 round and those rewards could be distributed in each of the following 7 L2 rounds. Rounds on L1 and L2 could both be defined in terms of L1 blocks to make it easier to reason about how L1 and L2 round progression align with each other.
Since the rewards available for a round are determined by the current inflation rate which depends on the total staked supply vs. the total supply, L1 would need a way to determine the staked supply on L2. At the moment, there is not an easy way to read state from L2 on L1. In an optimistic rollup, an L1 contract can only determine if L2 state is valid after a delay. In a zk rollup, an L1 contract can determine if L2 state is valid immediately after the ZKP is validated by the L1 verifier contract, but there is still some time before EVM compatible zk rollups will be production ready. A workaround to this problem could be to use an oracle to report the L2 staked supply to L1 at regular intervals. Even if an optimistic rollup is used, an oracle can validate the L2 chain state off-chain. In the short term, the oracle address(s) that can report L2 staked supply to L1 can be determined via governance. A subsequent improvement could be to use an oracle network such as Chainlink.
A sketch of how this could work in practice:
- An oracle reports the L2 staked supply to L1 at regular intervals and the value is cached
- When a new round is initialized on L1, calculate the total staked supply and total supply across L1 + L2 and use the result to determine the current inflation rate. Then, mint 100% of rewards for the round based on the current inflation rate and send them to the L2 Minter via the gateway
- On L2, track the amount of rewards that have been migrated from L1
- On L2, calculate the amount of rewards that are available in each round based on the total rewards that have migrated and the number of L2 rounds that the rewards should be distributed over i.e if there are 700 rewards and 1 L1 round = 7 L2 rounds distribute 700 / 7 = 100 rewards in each L2 round
Pros of this approach:
- No need for a special gateway between L1 and L2. The “L2 inflationary minting” design would likely need a special gateway where LPT can only move through the special gateway to ensure that L1 LPT can be minted for newly inflationary L2 LPT that is being moved to L1
- There should be less contract code required on L1 and L2 to support this
- Reduces scope of impact of L2 bugs to incorrect LPT distribution on L2 as opposed to excess LPT being minted (since no LPT is minted on L2)
Cons of this approach:
- Incur L1 tx costs when rewards need to be minted. This can be countered somewhat by minting and migrating rewards less often
- Requires an oracle to report L2 state to L1