Thanks for the feedback @vires-in-numeris @Wiser! I’ll attempt to create different sections for different areas of discussion below.
Opt-In Migrations
I agree an orchestrator/delegator should be able to migrate to L2 with their entire stake. But, I also believe that they should be able to:
- Choose when they migrate
- Unbond and withdraw on L1 if they don’t want to migrate to L2
The reasoning for 1 and 2 is that while a large portion of orchestrators/delegators may be happy to migrate to L2 pretty immediately after the option is available I also think it is important to retain the option for orchestrators/delegators to take any security precautions (i.e. waiting a bit, doing more research, etc.) before migrating to L2 which implies not forcefully moving any funds to L2. Additionally, while I don’t currently expect anyone to unbond and withdraw on L1 because they don’t feel comfortable with L2, I think retaining this option is worthwhile to give users the ability to exit on their own terms. With all this being said, protocol inflation on L2 can still provide a strong incentive for migrating to L2 such that many users choose to migrate because it makes economic sense to do so.
The most obvious form of an opt-in migration is for an address to submit the migration tx themselves. I also recently updated LIP-73 to support authorizing a migration by signing a message allowing a third party to submit the migration tx as well as long as they have the signature.
Hybrid Approaches
I think it is worthwhile to distinguish the different types of “hybrid approaches”:
- Support protocol inflation on L1 and L2
- Support ticket redemption (and thus transcoding jobs since ticket redemption is the compensation for transcoding jobs) on L1 and L2
- Both 1 and 2
The problem with any approach that doesn’t involve 2 at least for a period of time is that if the migrations are opt-in, then there is the possibility of network capacity to be reduced until a sufficient # of orchestrators migrate to L2. Ideally, the network capacity would not be meaningfully impacted by migrations to L2 so that from a broadcaster’s POV the network continues to “just work” regardless of when individual orchestrators decide to migrate to L2. In the best case scenario, we can pretty quickly ignore L1 altogether because a sufficient # of orchestrators are on L2 to support streams. In order to prepare for the worst case scenario where there are an insufficient # of orchestrators on L2 to support all of a broadcaster’s streams, the broadcaster can fallback to using orchestrators on L1 (if it chooses to do so).
So, that leaves options 2 and 3 with the difference between option 2 and 3 being whether protocol inflation is supported on both L1 and L2. Before digging into this further, a couple clarifications:
- I agree that there should be protocol inflation on L2 as it is an important incentive for orchestrators/delegators to migrate to L2
- I see the main use case for simultaneously having some amount of (likely reduced) protocol inflation on L1 for a period of time (could go to 0 after that) not to encourage new users to stake on L1, but rather to give existing users the ability to make the migration decision at their own pace instead of incentivizing a mass rush to migrate to L2 which could happen if protocol inflation is completely disabled on L1 and enabled on L2 at a single point in time
- However, I do think that @Wiser makes a good point about how protocol inflation on both L1 and L2 can lead to user confusion even if we don’t intend to encourage users to stake on L1 and that @vires-in-numeris makes a good point about how disabling protocol inflation on L1 can encourage delegators to move away from passive orchestrators on L1 to the more proactive orchestrators that migrate to L2 which can have a positive stake delegation re-distribution effect