This post is a call for feedback from the community on a proposal to increase the number of active transcoders in the Livepeer protocol from 15 to 25 during round 1261, taking effect during round 1262, on approximately Wednesday, February 20.
During Livepeer’s alpha release (Snowmelt Phase), the number of active transcoders on the network was set to be intentionally small at 10, allowing the network to be tested with a small group of actors before expanding. During round 1052, this limit was expanded by 5 in the first parameter update to the protocol to 15 active transcoders.
The intention is to scale well beyond this small number, and the upcoming Streamflow upgrade intends to enable hundreds to thousands of active nodes. However, in the meantime, there are a number of reasons to consider raising the limit to 25 active transcoders.
Proposed Benefits of the Change
- Increase the decentralization of the network by encouraging greater participation from new actors.
- The amount of stake delegated towards nodes in the active set has created quite a high bar for entry into the set, discouraging new, aspiring node operators, from considering a candidacy for Livepeer transcoder.
- Since revealing statistics on the explorer of transcoder protocol interaction performance, the active set has been performing admirably missing very few reward calls. There should be room for more actors to achieve this level of performance.
- The more nodes who are familiar with running the software and performing this role prior to Streamflow testing and rollout, the more participants in the ecosystem there will be to help QA, test, and prepare for the changes that Streamflow will bring.
- The protocol has run stably and consistently for many hundreds of rounds, so the technical risk to introducing this small scope change is derisked relative to near the launch of the alpha.
Check out the existing transcoder dashboard.
Potential Drawbacks of the Change
- It will be 62% more expensive in terms of gas to call the initializeRound() txn, which will now require about 4,500,000 gas. This txn is invoked 1x/day across the entire protocol. Since this is approximately 50% of the current block gas limit, it is still believed this can be confirmed quickly, and in Streamflow the intention is to move to an implementation that doesn’t require this sort of linear overhead in the initializeRound txn as more transcoders are added anyway.
- Bond, unbond, rebond transactions will increase approximately 8% in gas usage/cost. This affects every user, but since these actions are infrequent and low cost to begin with, hopefully the increase in decentralization and benefits listed above. As an example, a bond transaction may increase from approximately 278,000 gas to 300,100 gas, or essentially by $0.01 in USD terms at 5 gwei gas prices.
- If more stake activates on the ten newly added nodes, then existing transcoders may see their reward call token portions diminished as a result of greater decentralization of the newly generated tokens. For any individual actor, you can still expect to receive rewards in direct proportion to your stake, however if the stake is spread out further than the reward cuts for transcoders may result in less overall reward tokens. Transcoders can adjust for this by increasing reward cut if they choose. With a limited set of transcoders, each has a large share of a small pie, however the belief is that by increasing general participation, the ecosystem will benefit from more network incentive alignment leading to faster experimentation and more growth, increasing the size of the pie for all.
- DApps and Apps that reference Livepeer and have hardcoded assumptions around the 15 transcoder limit may need to update copy or UX. If they have pulled the limit from the protocol itself, they would adapt automatically, but it may take them time to discover the protocol update and make manual changes if necessary. This likely would not create breaking experiences, but it’s possible. We will proactively reach out to give everyone notice if this proposal leads to a parameter change.
Have any concerns of questions about this parameter upgrade? Share them here. As part of a shift from core team parameter setting to decentralized governance all input and discussion is welcome in an open way before executing any updates to the protocol.