If you would like to propose a change to one of the Livepeer Protocol Parameters, you can do so here.
Submitting a proposal does not guarantee that the change will be made.
All proposals will be shared below.
1 Like
The following proposal was submitted to the Change Proposal Form:
Please propose which Livepeer Protocol Parameter to change? (current values of these parameters are shown in brackets)
Max # Active Transcoders (25)
Please propose what value the parameter should change to?
50
If you like, you can give your reasons why you think this change should happen.
Because right now, the barriers to entry are so high to begin participating in the Livepeer Protocol, which means that the Active Set of Transcoders are able to generate huge wealth for themselves, and the opportunities for new Transcoders to enter the market are very low.
If you like, you can give any reasons why you think this change should NOT happen.
1 Like
The following proposal was submitted to the Change Proposal Form:
Please propose which Livepeer Protocol Parameter to change? (current values of these parameters are shown in brackets)
Max # Active Transcoders (25)
Please propose what value the parameter should change to?
30
If you like, you can give your reasons why you think this change should happen.
- To increase network effect, decentralization, and participation
- Increase likelihood of more transcoder contributions
- To target a smaller minimum stake amount
If you like, you can give any reasons why you think this change should NOT happen.
- Could draw delegations away from current transcoders
- Could be a burden on the network
The following proposal was submitted to the Change Proposal Form:
Please propose which Livepeer Protocol Parameter to change? (current values of these parameters are shown in brackets)
Max # Active Transcoders (25)
Please propose what value the parameter should change to?
50 - 100
If you like, you can give your reasons why you think this change should happen.
It should be increased now to give more transcoders a chance to participate and to hopefully support decentralisation of delegations
If you like, you can give any reasons why you think this change should NOT happen.
One argument would be that we should wait until the streamflow upgrades and roll it out with those changes.
The following proposal was submitted to the Change Proposal Form:
Please propose which Livepeer Protocol Parameter to change? (current values of these parameters are shown in brackets)
Max # Active Transcoders (25)
Please propose what value the parameter should change to?
40
If you like, you can give your reasons why you think this change should happen.
The barrier to entry for a new Transcoder is currently very high. The 25th Transcoder has a total amount of delegated stake of 47,000 LPT, which is equivalent to ~$284,000 at current market prices.
This means that it is almost impossible to launch a new Transcoder, unless you already have the support of a Livepeer Whale.
This high barrier to entry, and requirement to secure an “inside deal” in order to participate as a Transcoder, represents a risk to the decentralisation and participation of this project.
If you like, you can give any reasons why you think this change should NOT happen.
Increase cost to initialize a round: as I understand it, the cost of initialising a new round is proportional to the number of Transcoders in the active set. Increasing the number would therefore increase the cost of initialising a new round.
The average cost of initialising the last 10 rounds was approximately $8.
However, given that approximately 21,000 LPT (~$126,000 at current prices) are minted each new round and distributed to active participants, increasing the cost to initialise a new round seems to be a reasonable suggestion.
We could also wait for Streamflow - but that isn’t likely to ship until the end of 2019 at the earliest, by which time, 25th place will be a long way out of sight for new joiners, and likely to therefore be an even higher barrier to entry.
One consideration on these proposals is that the current cost to initialize a round in gas is 4,519,008. The Ethereum block gas limit is 8,000,000 currently I believe.
As the gas cost increases approximately linearly with the number of transcoders, it looks like it might be technically impossible to increase the limit up to 50, as the transaction would not fit within a single Ethereum block, and therefore would fail every time and the protocol would halt. There may be a sweet spot between 25-50, however as the transaction gets bigger and bigger towards taking an entire Ethereum block, it’s possible miners are less likely to include it quickly, leading to a longer protocol halt each day while everyone is waiting for the round initialization to confirm.
Note: the Streamflow protocol update re-architects the contracts to make it such that the cost of initializing a round in gas is much lower and therefore the limit can be increased to a much higher order of magnitude.
I think 33 is a good number, that leaves you just below 2/3s and should not increase protocol halt. Obviously we are biased, since we literally just started running a transcoder yesterday.
I do agree that a hard-line at 25 creates a whale-centric node structure that will be hard to break and over time can create issues for network performance. One good way to handle is is similar to BTC – halving in PoS is increasing Validator count automatically, so you avoid getting drawn into politics.
From a network architecture, iterative increase is what you should aim for – explosive percolation of validators to 100 can create unforeseen issues to token-value over time.
Existing validators will fall into 2 buckets – the ones that are here to maximize returns/yield at all cost (keep it close and small), and the once that care about network integrity (increase network size iteratively)
We are accumulating LPT and have enough relations to secure whatever the minimum amount is, but truth is, that creates a network culture we don’t think rewards the right behavior. Smaller validators ahead of us, that might have aided the network for longer, would suddenly fall to the wayside.
1 Like
The one risk you have with increasing validator count is that you end up with validators that aren’t run properly being active in the network – eventually they will get penalized out of the system, but it creates short-term issues (Stellar had a few of those). Since there isn’t a lot of network activity yet, this is less of a risk right now. In the long term, certifications are a good way to handle that (and the Livepeer 'Foundation" retaining a large enough active node-set to dynamically stabilize the network).
Could you explain your reasoning on why the current limit will create issues for the network performance?
In the long term, the protocol should handle that (by setting the right incentives and punishments) and not a centralized party.
Now regarding the increase of the numbers of transcoders:
I’m not convinced that it’s reasonable to increase the number of transcoders before streamflow (or before a contract re-architecture). The main pro arguments seem to be “increase decentralization” and “lower the barrier for participation”. Well you can participate right now by staking - you don’t need to run a transcoder for that. There are currently 11 transcoders offering a 2% or lower reward cut, so I don’t see any problems for participation… We can also increase the decentralization through staking to a transcoder outside the top 10/15. This would help a lot more than increasing the limit to 30 or 35 transcoders (more is imo not possible due to the gas restrictions).
So in my opinion, increasing the limit before streamflow (or a contract re-architecture) would hurt the protocol more than it would help due to the gas cost. After the protocol update, I’m all for increasing the number of transcoders (by a lot…)
Hey there – thank you for your questions. Here my take:
- Network issues long-term: Basic economics. Nodes with disproportionate amounts of LTP will be able to offer way lower fees over time to off-set cost of that node. This is a common and well understood problem with creating 20 or so super nodes.
- Iterative is better for networks. A manageable increase with quality vetting (not done by a centralized agent but by pre-defined community standards) ensures you have more consistent node performance over time.
- More validators always aids decentralization, what is your rational to the contrary (i.e. less validators = better decentralization?)? Certifications aren’t normally a centralization point (unless you believe linux to be a centralized network), for example.
- Gas cost is not going up on a transaction level, it would go up for the full block – can you provide examples where 45%-60% block fill leads to slower block-issuance? How does that relate to actual network performance (based on content items transcoded now?
- Decentralization is more than getting a return for your token. It is a common mis-conception. It is like saying that owning bitcoin aides the decentralization of bitcoin (it doesnt, running a node does).
- Everyone commenting should be transparent about their associations – are you connected to a current transcoder?
That said – i sell nodes, so lean towards open networks where the best get rewarded. I will stand by that even if/when we are a top 25 node …
Interesting discussion!
My opinion is in line with vires-in-numeris and the information posted by dob.
Increasing the number of transcoders directly affects the amount of gas needed to init rounds and will lead to one of two things:
- Pay a higher gas price to prevent protocol halts making round inits too expensive to be considered acceptable
- Run into transaction inclusion issues, halting the protocol
We’ve already run into round init transactions being stuck when the ethereum network is congested.
Network issues long-term
The current version of the protocol is not the final product. We are currently working on a scaling upgrade: The Streamflow Proposal — Scaling Livepeer | by Doug Petkanics | Livepeer | Medium
This means that even changing parameters would only be a short-to-medium-term bandaid until that portion of the protocol gets reworked, tested and released
I think it’s also important to consider what the goals of the iterative protocol releases are. I believe that the current version’s goal is more to test certain cryptoeconomic assumptions regarding the staking protocol rather than have mass transcoder decentralization.
In the end I’m all for more transcoders, but as mentioned before it is something we aim to tackle through streamflow re-architecture rather than increasing the parameter value.
if the reward allocation is not connected to the stake-size, I concur @NicoV. Otherwise the time between now and streamflow will still make the orchestrator network one-sided towards existing whale-nodes.
if the reward allocation is not connected to the stake-size, I concur
Reward allocation is connected to “total stake” which includes delegated stake.
Well if we look at the top transcoder in the list.
27166 stake
1 076 804 delegated
Or 2.5% of stake belongs to the transcoder himself.
But that transcoder does have a 5% reward and 0% fee share.
I think the short-term problem of what you describe above lies perhaps not in # of transcoders but how sensible users are delegating stake to a transcoder. Perhaps we should do a better job of making clear that the top transcoder in the list doesn’t necessarily mean the best one to delegate to if you want to get the most rewards as a delegate.
Thanks for elaborating further, @Blockdaemon
- Over time, the LPT reward will decrease and it will be more about the ETH reward from actual transcoding being done. So the amount of stake that a transcoder has is mostly a security signal for broadcasters and more important factors will be involved (e.g. price, location, availability, response time…). So I can’t see any (short or long term) performance issues for the network due to the current transcoder limit.
- I don’t agree. In the long term, this should be handled by the the protocol by setting the right incentives and punishments - that’s why we have the token…
- Currently, the top 5 transcoders have 50% of the staked LPT. I can’t see how this will change by adding 5 or 10 transcoders. I think what Nico mentions is much more important: “Perhaps we should do a better job of making clear that the top transcoder in the list doesn’t necessarily mean the best one to delegate to if you want to get the most rewards as a delegate.”
- Has already been answered
- & 6. Never said that… And yes, I do run a transcoder (you can find my campaign in the forum). I also built a (free) transcoder watcher bot to increase transparency and help stakers make more informed decisions: Telegram Bot: Transcoder-Watcher
It’s important to know that we’re not talking long term here… I think everyone agrees that the number of transcoders/orchestrators should increase drastically once actual work is being done on the protocol.
Great about 1. – we have thoughts on what that can mean to stakes etc., and rewards (tricky when you disconnect the potential of a node from the potential upside of token appreciation). Longer discussion.
We aren’t experts about the bottleneck the gas prices create, but i think the difference is very marginal.
Either way, in principal we are never fans when you have to pay hundreds of thousands of dollars to run a node. In reality that is a commercial benefit to us, but it isn’t great practice – so let’s do what we can to bring streamflow on …
Either way, in principal we are never fans when you have to pay hundreds of thousands of dollars
I agree and I think that’s a concern many in the community share. In the meantime running a good transcoder campaign to gather the support of delegates can aleviate some of those pains.
To give an example, I’m actually bonded to @vires-in-numeris (purely coincidental as I looked for a node with decent stats) and he has only put up 250 LPT of his own, while having nearly 500k (!!) delegated to him.
And he currently has a node with the 5th most stake.
so let’s do what we can to bring streamflow on …
Totally !
1 Like
Thank you for your support @NicoV! But I do actually have a lot more self bonded - just from a different account 
(since the private key of the transcoder is sitting on the server in an unlocked state in order to submit transactions, it’s more secure to bond larger amounts from an external account)
As soon as the network actually benefits from more nodes, the cost will come down drastically
1 Like
The following proposal was submitted to the Change Proposal Form:
Please propose which Livepeer Protocol Parameter to change? (current values of these parameters are shown in brackets)
Max # Active Transcoders (25)
Please propose what value the parameter should change to?
1024
If you like, you can give your reasons why you think this change should happen.
More decentralisation required
If you like, you can give any reasons why you think this change should NOT happen.
Too few participants
Great discussion thus far!
I ran a quick test to get a sense of what the gas cost for round initialization would be for different active transcoder set sizes:
| Active Set Size | Gas Cost | % of Avg Block Gas Limit |
|---|---|---|
| 30 | 5344629 | ~67% |
| 40 | 6584479 | ~82% |
| 50 | 8274342 | ~103% |
Based on the above numbers, increasing the transcoder limit size to 50 right now without a contract upgrade is infeasible given the current average ETH block gas limit of 8 million. The current round initialization gas cost of ~4519008 takes up ~56% of an average block, so while increasing the transcoder limit size to 30 or 40 is feasible, increasing to 30 results in a 11% increase in block space consumed and increasing to 40 results in a 16% increase in block space consumed.
Additionally, while round initialization is most affected, increasing the transcoder limit also has an impact on the gas cost of bond, unbond, rebond and reward transactions albeit much less so than on round initialization. This impact is due to the internal reordering of the transcoder list maintained by the BondingManager contract. I’m optimistic that the contract internals can be updated to minimize the impact of a transcoder limit increase on gas cost of all of these transactions.
Given the operational effort that is required to securely update a protocol parameter (even if it is a single value being updated) and the relatively small increase in the transcoder limit that is possible, I would suggest not increasing the transcoder limit size right now and instead focusing efforts on updating the BondingManager contract internals to enable a more significant increase in the transcoder limit.
That being said, I think this would be a great discussion/debate topic to include in the next community call scheduled for next Thursday 8/1 EST and the community could discuss more in-depth and hear more arguments from all interested parties.