A Proposed Scaling Strategy for the Livepeer Protocol

Research & Protocol Improvements
1

A Proposed Scaling Strategy for the Livepeer Protocol

The purpose of this post is to propose a strategy for scaling the Livepeer protocol based on my view of the evolving blockchain scaling landscape and to encourage the community to provide feedback.

This post is inspired by the MakerDAO PCU’s multichain strategy and roadmap post which does a great job of laying out considerations for the MakerDAO protocol in a multichain world.

The evolving blockchain scaling landscape

As mentioned in this blog post, rising Ethereum gas fees continue to increase the cost of protocol transactions. The good news is that there are a variety of efforts to scale Ethereum in order to reduce gas fees for end users of applications built on Ethereum such as Livepeer. A few projects (non-exhaustive!) building solutions in this area include:

  • Arbitrum One, an optimistic rollup built by Offchain Labs
  • Optimism, an optimistic rollup built by Optimism PBC
  • StarkNet, a zk-rollup built by StarkWare
  • zkSync 2.0, a zk-rollup built by Matter Labs
  • Polygon, a sidechain connected to Ethereum built by the Polygon team

A full evaluation of all available scaling solutions across all the different categories of solutions (i.e. optimistic rollup, zk-rollup, validium, sidechains, etc.) is outside the scope of this post and I suggest for those that are interested to start by reviewing the following resources:

Today, based on the total value locked (TVL) metric, Arbitrum One is in the lead in terms of adoption according to l2beat.com. At the same time, there is a growing belief that in the long term zk-rollups and their variants will be the most ideal technology to scale Ethereum. However, while there have been tremendous advancements in zk-rollup technology in the past year with many projects launching alpha versions of their solutions in the next few months, there will still be work to do to bring the technology to a greater level of maturity (battle testing in production, auditing, education, growing the tooling ecosystem, etc.). Furthermore, while many of these solutions share a similar design, they also differ in certain details with different projects aiming to differentiate their solution. And while these projects are working to launch the alpha versions of their solutions, other projects that are already live (i.e. Arbitrum One, Optimism) work on not only shipping improvements, but in some cases also R&D to bring the benefits of zk-rollups to the existing users of their already live solutions.

I believe that the situation described above illustrates that the blockchain scaling landscape is constantly evolving. While we may have a sense of the ideal scaling solution in the long term in a theoretical future, there is still work to be done before that theoretical future becomes a reality and in the short term I believe that it is prudent for any decisions around scaling for the Livepeer protocol to take this into account.

Where should the Livepeer protocol smart contracts be deployed?

A general way to think about the protocol contracts is as an incentive mechanism designed to incentivize the provision of video infrastructure resources (i.e. hardware/bandwidth for video transcoding) by nodes in an off-chain network through a combination of LPT rewards and ETH fees. The Livepeer network depends on this incentive mechanism because it defines the rules by which nodes on the network are compensated for the video infrastructure resources they offer. It is important for this incentive mechanism to be hosted on a blockchain because the rules by which nodes on the network are compensated should be transparent and predictable which requires the property that no single party can unilaterally change the rules without community consent. At the same time, the incentive mechanism needs to be cheap to operate and use - otherwise, the cost overhead of the incentive mechanism may make the network unattractive to use relative to centralized alternatives or worse just economically unsustainable.

Today, this incentive mechanism is deployed on Ethereum (with the rise of the L2 category of blockchain scaling solutions, Ethereum is also commonly referred to as “L1 Ethereum” or just “L1”). Given the above, I see the following goals when thinking about where to deploy the incentive mechanism:

  • Make the cost of operating and using the mechanism as cheap as possible
  • Ensure that the incentive mechanism can be operated in a transparent and predictable way to ensure that no single party can unilaterally change the rules without community consent

In the long term, it is possible that there is a clear choice of a single chain that the incentive mechanism can be deployed on that fulfills both of these goals. However, in the short term, given the constantly evolving blockchain scaling landscape, it is not clear which particular choice at this point in time can fulfill both goals in the long term. But, rising gas fees on L1 is a problem today that the community needs to address which means that a decision needs to be made even if the best choice for the long term is not yet obvious.

A flexible scaling strategy

An ideal scaling strategy for the Livepeer protocol would:

  • Reduce the cost of operating and using the incentive mechanism (i.e. the cost of staking, settling payments, distributing rewards and fees, etc.) by many magnitudes
  • Minimize or avoid altogether any reduction in the transparency and predictability of the operation of the incentive mechanism
  • Ensure flexibility to adapt the protocol to leverage new scaling solutions when the community decides it is appropriate and necessary

I belive that a strategy that fulfills these requirements is as follows:

  1. Identify a chain that offers significant cost reductions for operating and using the on-chain incentive mechanism and that is believed to be reasonably mature such that the protocol contracts can be securely developed and maintained on the chain
  2. Build support for stake migration from one or many origin chains that the protocol contracts are already deployed on (i.e. today this is just L1, but in the future this could be L1 and a L2) to the destination chain such that orchestrators and delegators can move their stake to the destination chain without waiting through the unbonding period
    • This requires support for bridging LPT from the origin chain to the destination chain
  3. Deploy the protocol contracts to the destination chain
  4. Enable protocol inflation on the destination chain
    • The simplest version of this is to disable protocol inflation on the origin chain and enable it on the destination chain
    • Other options include:
      • Gradually decreasing inflation on the origin and increasing inflation on the destination
      • Calculating the inflation on the origin and destination based on the amount of stake participating in either chain i.e. if 40% of all stake is in the destination then 40% of inflation goes to the destination
  5. Build support for broadcasters to discover and use orchestrators that are registered and staked in the destination chain

The above steps can be repeated more than once. For example:

  • Initially, stake could migrate from L1 to Arbitrum
  • Then, broadcasters could discover and use orchestrators that are registered and staked on both L1 and Arbitrum
  • In the future, stake could migrate from L1 and/or Arbitrum to StarkNet
  • Then, broadcasters could discover and use orchestrators that are registered and staked on L1, Arbitrum and StarkNet

As this example illustrates, a big benefit of this strategy is that it can take advantage of cost reductions from scaling solutions in the short term without sacrificing the flexibility of taking advantage of cost reductions from other scaling solutions in the future.

Arguably, the most important part of this strategy is the support for broadcaster to discover and use orchestrators that are registered and staked in the destination chain. If we assume that migrating stake to the destination chain is a user opt-in process (and I would argue that user consent is important), then it is likely that stake and the orchestrator set on the network becomes fragmented across multiple chains at least in the short term. For example, 40% of all stake may remain on L1 and 20% of orchestrators on L1 may prefer not to migrate their stake at least in the short term (perhaps because they have a lot of stake and do not feel comfortable moving it yet). If a broadcaster is only able to discover and use orchestrators registered and staked on a single chain then this fragmentation can be harmful for the broadcaster because the broadcaster has a much more limited set of orchestrators to use and can be harmful for orchestrators because each orchestrator may only receive work from broadcasters that are using the same chain.

The orchestrator set for a protocol contract deployment on a chain can be considered a “subnet” as a part of the larger Livepeer network. From a broadcaster’s point of view, it can consider orchestrator sets from all subnets on the network when selecting orchestrators for jobs. The following diagram illustrates how this could work:

1751×1141 33.6 KB

A downside of this design is that it requires broadcasters to have deposits with the TicketBroker contract on different chains in order to pay the orchestrator set for that chain. In the future, this could be remedied by improvements to the payment protocol - for example, payments could be mediated by a set of untrusted third parties such that the third parties can relay the payment to orchestrators on any chain with the broadcaster only needing to pay the third party (something like Scaler). In the short term, this is definitely burdensome for broadcasters, but, since most broadcasters today are currently operated by Livepeer Inc., the scope of impact of this inconvience is limited.

A few analogies that may help with understanding this strategy:

  • There are multiple sources of DEX liquidity available today. 0x’s Matcha provides users a unified interface that they can use to trade, but under the hood the trade is routed to the liquidity source that gives the user the best price.
    • For the Livepeer protocol scaling strategy, replace liquidity sources with orchestrator sets for protocol contract deployments on different chains and replace Matcha with the broadcaster.
  • Suppose a web2 app uses a MongoDB database in its backend. The development team wants to switch to a Postgres database for new functionality. In the web2 world, the team could just migrate all data from the MongoDB database to a new Postgres database (after a translation process). However, in a web3 context, since we care about user consent, let’s say each user gets to choose if their data is migrated from the MongoDB database to the Postgres database which results in the app being backed by both the MongoDB and Postgres databases at least for a period of time.
    • For the Livepeer protocol scaling strategy, replace the databases with protocol contract deployments on different chains and replace the web2 app with the broadcaster.

Questions for the community’s consideration

Find below a few questions that could be useful for the community to consider:

  1. Does the potential requirement of additional user initiated stake migrations (keeping in mind that there would be development to make this as low friction as possible) in order to access additional cost savings in the future feel reasonable if the strategy used also unlocks cost savings sooner in the short term? An alternative is to just wait for scaling solutions perceived as more “ideal” (i.e. zk-rollups) to launch and to become more mature.

  2. Given that gas fees are quite high on L1, when support for migrating stake to the first destination chain is added, should protocol inflation on L1 be completely disabled for simplicity or should some protocol inflation still be supported on L1 in some way?

3 Likes
2

Thank you for all these explanations Yondon.

in my opinion, we have to switch to L2 as soon as possible. And the requirement of additional user initiated stake migrations feel reasonable for me.

This will allow all Orchestrators to call reward daily, and finally allow them to compete with the biggers ones.

Indeed the only thing most delegators are looking for is a big Orchestrator with a low reward cut. For them the sharing of earns with the Orchestrators is quite insignificant because on a large O, the earns is too diluted due to the number of LPT stakes, and on a small Orchestrator (for the moment) the lack of gain is not motivating (in relation to the risk of missing reward calls).

of course, the ideal would be to wait until a zk-rollups solution to be sufficiently mature, but how long would it take? I think that the current situation with the price of gas is really untenable even in the short term, for an orchestrator who wants to be competitive. (call reward daily, lowering his reward cut, etc…)

Regarding the second question I think we must completely migrate the protocol inflation to the L2 solution, a hybrid solution is more likely to create difficulties and confusion.

2 Likes
3

First off all, thanks for the extensive writeup!

Hmm, I don’t like this hybrid approach, like @Wiser already said: it will add too much confusion. E.g. how would you educate the users that they can stake on L1 or on L2? How would you display the O list on the explorer? What would you promote as the better option?

If you stop the L1 inflation, you’re essentially forcing every O to migrate to L2 anyways - since they’d lose their stakers if they don’t get any inflationary rewards anymore. If you don’t stop the L1 inflation, what’s the incentive for current stakers to move to an L2? They’d occur migration costs without any immediate benefit.

So IMO, the correct way would be to stop supporting L1 once we’re on an L2.
And Orchestrators should have the option to move over to an L2 with their entire stake. So it would NOT be an opt-in from the user side, which doesn’t really matter: They’re staked anyways, so they would have to pay the unbonding & withdraw cost if they want their LPT back. If they’re forcefully migrated, we could include an option that unbonds and withdraws their stake directly to L1, so essentially they get the same result as if they would unbond on L1. We even have the 7 day unbonding period to move the tokens through the normal bridge! And this whole process might even be cheaper for the user…

The only issue I see is that they need a small amount of ETH on the L2 to pay for this unbonding tx. A solution for that: When the migration happens, distribute a very small amount of L2 ETH to every staker, just enough to pay for the unbonding tx.

The benefit of “an all or nothing” L2 move is also a redistribution of stakes - away from inactive Orchestrators that remain on L1 to the active ones that migrated.

TL;DR: Not a fan of the hybrid approach. Move everything to L2 and stop transcoding jobs and inflation on L1. And allow an O to migrate with its entire stake.

1 Like
4

It strikes me that the point that @vires-in-numeris hits upon is at the root of this debate… where the source of LPT inflation will be:

  • on L1 only (current state)
  • on L1 and L2
  • on L2 only

Fees flowing in ETH matters, and making it cheaper to deposit, withdraw and redeemWinningTicket will be great catalysts. But for me, what matters more is the location of the source of LPT inflation, in order to renovate the underlying dPoS / continuous funding mechanism.

So, given the proliferation, and constantly-evolving nature of EVM-compatible / EVM-equivalent networks upon which Livepeer Protocol could deploy, might it be worthwhile to “get good at” (as a community) shifting the source of LPT inflation between networks?

It feels to me like this might not be the last time we make such a shift… especially in light of the evolution between optimistic rollups and zk-rollups. And who knows, we might even want to shift it back to Ethereum PoS when that lands!?

So, irrespective of where we shift to first from Ethereum L1… does anyone else feel that it’s worth focussing on becoming more “nimble” (whatever that means in practice) as a protocol but importantly as a community, to be able to easily migrate to faster / cheaper networks as they materialise, and the community starts to prefer them?

3 Likes
5

If you mean the merge with “Ethereum PoS” (when the consensus switches to PoS) - no, you do not want to switch back since the fees on L1 will stay the same (slightly faster blocktimes, so ~8% improvement in theory) :slight_smile:

The earliest when L1 fees will come down significantly is when the execution layer sharding is live… which is probably 3+ years away. Or it might never happen, because everybody moved to L2s anyways and the data availability version of the shard chains is enough.

I also hope that we DON’T have to migrate that often. Yes we’re at the forefront of new technologies, so one or two additional migrations might be necessary. But eventually, the separation of the different L2s (as well as the shards) will hopefully be abstracted away. Ideally the users won’t even notice when they buy LPT on L2A and then stake them on L2B.

1 Like
6

Thank you for the write up. Appreciate the time it took to put together. This is a very complex issue to solve.

I agree that Orchestrators should not be able to move LPT assets delegated to a L2 without consent. If Os could, to me, it brings up questions who owns the assets. I also don’t quite understand how this could be possible without underlying keys to the wallets holding the LPT.

I have a few questions:

  1. With broadcasters possibly discovering Orchestrators on multiple chains would the stake from the subnets be combined for one total stake amount for selection process?

  2. Delegators will pay transaction costs to move to L2?

  3. With possibly multiple TicketBroker deposits, would it be 2x the deposit needed currently on L1? Or if a broadcaster only put a deposit on L2, would the broadcaster only be able to interact with that subnet of orchestrators?

1 Like
7

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:

  1. Choose when they migrate
  2. 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”:

  1. Support protocol inflation on L1 and L2
  2. Support ticket redemption (and thus transcoding jobs since ticket redemption is the compensation for transcoding jobs) on L1 and L2
  3. 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
2 Likes
8

I also hope that we DON’T have to migrate that often. Yes we’re at the forefront of new technologies, so one or two additional migrations might be necessary. But eventually, the separation of the different L2s (as well as the shards) will hopefully be abstracted away. Ideally the users won’t even notice when they buy LPT on L2A and then stake them on L2B.

I also hope we don’t have to migrate that often! But, one thought is that if the migration process is a) as simple as submitting a single tx for the user (by integrating with the proper bridge tech i.e. in the future L2 → L2 between the origin chain and the destination chain) and b) not particularly disruptive to the network as a whole (by allowing broadcaster to utilize orchestrators on the destination chain while being able to fallback to orchestrators on the origin chain) then it may not need to be that painful of a process. And the less painful the process, the less we have to worry about whether L2A is going to be the long term winner relative to L2B and focus instead on taking advantage of L2A if it has benefits that are more immediately impactful.

1 Like
9
  1. With broadcasters possibly discovering Orchestrators on multiple chains would the stake from the subnets be combined for one total stake amount for selection process?

I see the following options right now:

  1. A broadcaster considers all orchestrators across all its supported subnets during selection. This should basically result in the same effect as the scenario that you described.

  2. A broadcaster first considers orchestrators on L2 during selection. Then, if the performance on L2 is degraded for a certain # of streams, the broadcaster can fallback and consider orchestrators on L1 during selection. As a result, the broadcaster will bias towards orchestrators on L2.

I’m leaning toward 2 right now because:

  • It will be faster to support technically
  • It provides an additional incentive for orchestrators to migrate to L2 while still preserving the ability to utilize orchestrators on L1 if needed (at least until those orchestrators migrate to L2 as well)
  1. Delegators will pay transaction costs to move to L2?

Yes. Although with the latest update to LIP-73, it would technically be possible for a third party to pay the transaction costs for the migration tx if the delegator signs a message and provides the signature to the third party.

We’re hoping to have a better sense of the transaction costs for the migration tx after making more progress on the LIP-73 implementation.

  1. With possibly multiple TicketBroker deposits, would it be 2x the deposit needed currently on L1? Or if a broadcaster only put a deposit on L2, would the broadcaster only be able to interact with that subnet of orchestrators?

Yes. At the moment, a broadcaster would need 2x the funds to use both L1 and L2. As mentioned in the OP, this is definitely a downside. After a move to L2, improvements to the payment protocol could reduce this burden for broadcasters - generally, the payment protocol is due for some improvements anyway because even outside of this context broadcasters currently have pretty hefty capital lockup requirements. Prior to that, the scope of impact of this burden is somewhat limited by the fact that a) most broadcasters today are operated by Livepeer Inc. which can shoulder that burden for a bit and b) broadcasters operated by others can choose to just use L2 to reduce the burden a bit.

1 Like
10

So as an example: if my Orchestrator migrates to L2, every delegator (which is 500+ in my case) needs to actively migrate its stake? What happens to those who don’t migrate (a lot of them probably only check once every 3-6 months how the project/Orchestrator is doing)? Would those be forcefully unstaked or do I now have to operate two Orchestrators - one on L1 and one on L2?

Sorry but that seems really messy and confusing to me. If it’s technically possible (and I believe it is since the staked tokens are in the minter contract?), this should really be an opt-out migration and not an opt-in.

Similar to the governance process, I would propose a time window (3-4 weeks) where Os could signal if they plan to migrate or not. If an O decides to migrate, the stakers have enough time to overrule that decision and unbond from that O. At the end of this window, every O that signaled migrates at the same time - with its entire stake.
This has the following benefits:

  • No migration cost for the delegators
  • No rush towards migration (for LPT rewards)
  • Gives a good indication on the network capacity of the L2 before the actual migration
  • An Orchestrator is either on L1 or L2, it’s a clear cut

I don’t really see any downsides with this approach. I strongly believe that inactive delegators would prefer being migrated to L2 and continue earning rewards to being left behind on L1.

3 Likes
11

I agree that supporting the choice of where to get and redeem tickets / call rewards is a good call until you have a strong L2 presence and can make a cut off eventually. Ultimately if you keep L1 rewards/tickets accessible and Orchestrators for some reason choose to pay more to run their O, then that is fine but I could probably safely assume that 90% of O’s would choose L2 at very quickly if not almost instantly. Though alternatively @vires-in-numeris’s suggestion of disabling protocol inflation on L1 would be your best bet to get compliance as fast as possible.

I also think that doing an L2 Migration sooner than later is worth the cost for most of us as right now we are continuously being outpaced by bigger Orchestrators and we are losing a significant return by just farming the winning tickets. Whether its 6 months or a year before livepeer decides to migrate to another L2 solution or fully embrace the one that gets chosen now, seems to have a bigger opportunity for not only O’s but delegators to grow and establish a more diverse community. Postponing could have significant missed opportunity costs for a large portion of the community.

12

Good points. The current LIP-73 design would result in an orchestrator losing its delegated stake on L1 when it migrates to L2 since the orchestrator’s delegators would have to migrate their own stake delegated to that orchestrator to L2. After some thinking, I agree with you that this is not only messy, but also disproportionally penalizes orchestrators with many delegators relative to orchestrators with few delegators. While delegators can certainly choose to move their stake away from an orchestrator on their own, I think it is important for this and other protocol upgrades to not disproportionally penalize a certain group (i.e. orchestrators with many delegators) if the members of the group are operating honestly and according to the rules of the protocol.

Similar to the governance process, I would propose a time window (3-4 weeks) where Os could signal if they plan to migrate or not. If an O decides to migrate, the stakers have enough time to overrule that decision and unbond from that O.

I agree that an opt-out process that involves an orchestrator by default migrating its entire delegated stake to L2 with the ability for delegators to opt-out beforehand could be reasonable. LIP-25 already defines a social convention for delaying protocol updates by a fixed period of time and the purpose of the delay is to give users the ability to exit if they disagree with the nature of the protocol update. So, during a delay period after staging a protocol update a delegator that does not want to have its stake migrated with an orchestrator has the option to opt-out by unbonding.

At the end of this window, every O that signaled migrates at the same time - with its entire stake.

While it is technically possible to move staked LPT from L1 to L2 in a single large batch (since the staked LPT is owned by the Minter contract), a couple things worth noting here.

Orchestrators/delegators would likely still have to at the very least submit a transaction on L2 in order to “claim” their stake on L2 which would be the same amount of stake that they had on L1. This is because the BondingManager contract on L1 tracks the stake of each orchestrator/delegator and there needs to be a process by which the BondingManager on L2 can “learn” the stake of each orchestrator/delegator. Additionally, if orchestrators need to “claim” their stake on L2, they wouldn’t be able to earn LPT rewards until that point since the BondingManager contract needs to know how much stake they have in order to calculate the LPT reward amount - depending on how you interpret the situation, the orchestrators would either be still considered on L1 at this point or in a sort of limbo state where they need to submit a transaction on L2 in order leave that state.

Thanks for all the feedback. We’re working on an an updated stake migration design to address the concerns shared thus far and will share back soon.

1 Like
13

I posted a proposal for an updated L2 stake migration design here based on the feedback in this thread. I opted to post the proposal in the LIP-73 thread since its already dedicated to L2 stake migration designs and since the original post in this thread was more focused on discussion around general scaling strategies for the protocol.

@vires-in-numeris @0xB79

1 Like