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.
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:
- Off-chain protocols: rollups and sidechains | Infura Blog | Tutorials, Case Studies, News, Feature Announcements
- The ultimate guide to L2s on Ethereum — Mirror
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.
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.
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:
- 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
- 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
- Deploy the protocol contracts to the destination chain
- 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
- 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:
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.
Find below a few questions that could be useful for the community to consider:
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.
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?