LIP-73: Confluence - Arbitrum One Migration

Governance
15

The requirement for state in the L1 contracts to be frozen in this design has the following implications:

  • Protocol inflation on L1 is completely disabled
    • Reason: Otherwise, the stake of accounts on L1 could increase after the snapshot is created. Additionally, this creates a stronger incentive to migrate to L2
  • Protocol inflation on L2 is supported
    • Reason: Otherwise, there is less of an incentive to migrate to L2
  • No fees can be earned on L1 and fees can only be earned on L2
    • Reason: Otherwise, the fees earned by accounts on L1 could increase after the snapshot is created. Additionally, this creates a stronger incentive to migrate to L2

Given these implications, the following questions are important to answer:

  • How will protocol inflation be disabled on L1 and enabled on L2?
  • How will work distribution transition to L2 once fees are disabled on L1?

The below sections aim to answer these questions.

Protocol Inflation

Let LIP_73_ROUND be the round at which the changes in LIP-73 go into effect.

  1. Before LIP_73_ROUND begins, the RoundsManager contract is upgraded such that starting at LIP_73_ROUND the initializeRound() function will be disabled meaning that rounds cannot be initialized. As a result, the round prior to LIP_73_ROUND will be the last round in which Os can call reward and redeem tickets
  2. Before LIP_73_ROUND begins, all protocol contracts (with required changes [1] for stake migration) will be deployed to L2 and will begin in a paused state meaning that no protocol transactions can be processed yet
  3. LIP_73_ROUND begins. As of this round, Os will not be able to call reward and redeem tickets on L1
  4. The L1 Minter will be upgraded to support transferring LPT + ETH cross-chain to the L2 Migrator to support the stake migration process
  5. The L1 Minter will transfer LPT + ETH cross-chain to the L2 Migrator
  6. The L2 Minter will set the starting inflation rate on L2 as the last inflation rate in the L1 Minter. As a result, the inflation schedule on L2 essentially picks up where the inflation schedule on L1 left off
  7. All protocol contracts on L2 are unpaused allowing protocol transactions to be processed

Steps 4-7 should happen in quick succession during a very short time period. We’re also looking into the possibility of executing these steps in a single action to minimize the length of the time period.

At this point, the stake migration process described in the previous post can begin. Note that since the protocol currently requires an O to wait until the next round after it stakes/registered to become active, after migrating an O will need to wait until the next round before it can call reward and redeem tickets.

Summary:

  • Os will be able to call reward and redeem tickets on L1 up until a designated round
  • From that round on, no protocol transactions will be processed on L1
  • The inflation schedule on L2 will pick up where the inflation schedule on L1 left off
  • Once the steps are complete, stake migration from L1 can start and anyone is also free to directly submit protocol transactions on L2
  • Once Os migrate to L2 they will need to wait until the next round in order to become active after which they will be able to call reward and redeem tickets

[1] A full list of contract level changes to be enumerated separately.

Work Distribution

Once fees are disabled on L1, Os will not be able to redeem tickets on L1. So, any work received by Os after this point and before migrating to L2 would be performed for free (since any winning tickets received would not redeemable).

At the moment, Livepeer Inc. expects to start operating Bs on L2 immediately after the LIP-73 upgrade is executed which will only distribute work to Os on L2. Additionally, there are no plans to add simultaneous support for L1/L2 in go-livepeer. So, if other B operators wish to operate a L1 B and a L2 B they can choose to do so, but the recommendation will be to just operate a L2 B.

Previously, the intent was for Bs to be able to distribute work to Os on either L1 or L2 as outlined in this post. The benefit of this hybrid work distribution approach was that it allows for a smoother network transition where Bs could fallback to Os on L1 if the active Os on L2 have insufficient capacity. However, the reasons for not using this hybrid approach at this time are:

  • In this latest design, Os on L1 cannot earn fees after the upgrade so they can only do work for free
  • Given the above, it feels unnecessarily complex to support such a hybrid approach as opposed to as a community focusing on moving to L2

With all that being said, such an approach could be considered in the future if another migration is needed in a scenario where fees are not disabled on the origin chain. In this case, the choice of disabling fees (and other protocol transactions) on L1 in order to support a snapshot based claim on L2 that lowers costs for delegators feels like a worthwhile tradeoff.

The current planned changes in go-livepeer to make this transition easier:

  • Allow Os to receive tickets if they are pending activation as opposed the current requirement where they need to be active to receive tickets. The reason for this change is to allow Os that are scheduled to be active in the next round after they migrate to L2 to immediately be able to accept work on L2 in order to minimize the period where an O cannot receive work at all. Since the O is pending activation and since tickets are valid for at least 2 rounds (the current ticket validity period), the O will be able to redeem any winning tickets as soon as the next round.
5 Likes