These are great questions. I’ll try to give some quick responses.
- Will delegators also be slashed/how will they know if their O is behaving correctly…
Yes, D(elegators) will also be slashed proportionally along with the O. O’s history should be visible on chain, but also through tools like the explorer, so that D’s can evaluate their level of risk. Remember that no one should ever be slashed unless they do something proactively malicious.
Of course the other scenario is that they are accidentally slashed due to a bug - and even worse is if someone malicious can trigger this bug remotely by crafting a certain input segment. We are thinking about “rate limiting” solutions in which harm due to accidental slashing could potentially be limited, especially in the early days of the network.
The 1-out-of-1000 is just an example parameter, and far more segments could be checked, or there could be built in checking via redundancy. The average time to detect a slash should be bounded with high probability, and since it’s likely only a few Ethereum blocks, (or couple minutes) worth of encoding - this likely costs pennies worth of work, but any slash amount that represented a percentage of a significant amount of staked LPT, would be a harsher penalty.
Yes, all those metrics you suggested should be visible through the explorer (or other 3rd party tools). The explorer is totally open source, and we welcome contributions to improve it and display more/better statistics.
- Will delegators be able to see all the services and locations registered by Orchestrators in service registry? Will that be available on livepeer explorer or in some other place?
Yes. The explorer should give a view into the registry, yes.
- How do the protocol know whether the mistake happenned is from Broadcaster side (not paying amount properly) or from Orchestrator side (not performing work properly)? How do you ensure that Orchestrator is not getting slashed because of Boradcaster’s mistake?
An O can’t get slashed due to a B’s mistake. There is proof of the input segment signed by B, and only if O signs an encoded segments attesting to the output encoding, can O be slashed. If B doesn’t pay enough, O simply doesn’t do the work, there is no slashing in that case.
If B spends more money than they have, then their “penalty escrow” can be lost (which is kind of like slashing). B should be able to control for accidentally doing this with high probability if they have a big enough deposit in their penalty escrow.
- What are some of the steps that delegators should take to ensure that they are delegating to the right orchestrator?
The same steps they’re currently taking - researching a combination of on chain statistics on past performance, the economics the O is sharing, and their offchain social campaign. It also isn’t unreasonable to “diversify” across multiple O’s to reduce risk and to encourage decentralization.
- Centralization risk…
Certainly if the most efficient operators who can charge the lowest possible prices continue to provide great service, share the most fees, and attract the most stake, then they will likely win much of the work. Two factors which work against this:
- The more stake they attract, the more ways the fee-share is being split - hence a lower ETH/staked LPT fee ratio for delegators. If any up-and-coming node can attract work due to being available with good performance, a lower price, or more attractive fee share - then stake would likely shift over towards this node in favor of a higher ETH/LPT fee ratio.
- Local nodes have an advantage - if an up-and-coming node happens to be located closer to a B, then they’ll potentially have a lower latency response time on the transcoding, and hence they’ll win work, and attract an outsized ETH/LPT fee ration - attracting further delegation.
So yes if there are only 2 big B’s on the network, and 2 big O’s are serving them reliably as cheap as possible, there may be some centralization, but that’s a pretty small network…let’s onboard more diverse B’s, with different use cases, in different locations, building awesome video products
- what is the approximate timeline for Streamflow to go live? 6 months? 1 Year?
The build has already been under way, so we’d like to have an internal testnet before the end of December as the next milestone. From there, of course external testing, reviews, audits, etc - so I can’t predict a date yet, but we’re working hard!
- Do you have any broadcasters ready to start broadcasting on livepeer once Streamflow goes live? If yes, what is the volume (in terms of USD) that you are expecting?
Well, we’ve had a bunch of B’s use Livepeer already - but for one off events like conference and meetup streaming this isn’t exactly scaled transcoding. So using the term “Broadcaster” is actually a little bit of a misnomer, when in reality the target users are developers building scaled video applications. And yes, while there are a number of developers/projects who have expressed interest and would benefit tremendously from using LP post Streamflow, it is definitely on Livepeer to showcase that the network can be reliable, performant, and cost effective before they would turn on the integration. This is the purpose of Streamflow
- Are there any transcoders in livepeer network that are currently earning fees (ETH) by doing transcoding job?
Yes, but low volume ETH - mostly through demonstrations, early integrations, and one off tests. One of the challenges that Streamflow addresses is that if the streams are short, then it actually costs more in ETH to do the txns to claim the fees, than they would make in fees - and hence not worth it. In Streamflow that’s no longer the case.
- Is there any waiting time between broadcaster paying the fees, orchestrator receiving the fees and distributing that fees to delegators? Will that distribution be done at the end of each round or is it done at orchestrator’s discretion?
As soon as O receives a winning PM ticket (payment from B), they can cash it in on chain at their discretion. The default is that they’ll cash it in right away, and there’s an expiration date which means they can’t wait too long. This will automatically split the fees between O and its D’s - though the D’s will need to “claimRewardsAndFees()” for each round in order to move the fees into their wallet. This is a bit of an implementation/accounting detail though and could potentially be changed to work differently.
Hope that helped!