Offchain engineering considerations
- PM contains an interactive protocol for ticket generation. B first asks O for a random number, and then starts sending tickets based on the result from O. The generation of the random number should be secure, and the random number should NOT be leaked. Otherwise B will be able to forge tickets that will never will for O.
- PM double-spend issue.
- PM risk management issue.
- O writes its serviceURI onchain. As a result, it should be DDos-resistant. There is an incentive for Os to DDos each other in order to take down the competition.
- Price discovery remains to be an open research topic. For example, it's possible for Os to arbitrage by negotiating with another O if Bs don't negotiate with every O. This is not necessarily a bad thing - if the intermediate Os are facilitating market-efficiency.
- VOD payment risk / data availability issue. VOD jobs have the potential to be spread across many Os. However, PM depends on the assumption that if O doesn't perform, B can quickly move to a different O. But if we “spread too thin”, B won't have the ability to “move away” to a different O. This might not be an issue however, if B keeps some internal reputation, or if B “retains some thickness” of the job distribution.
- Broadcaster has to be responsible for verification. Therefore, broadcasters have to be online, and able to run the verification algorithm. However, a broadcaster under certain scenarios might not have the capacity to verify (especially if the verification method is probabilistic re-transcoding). The is a classic data availability problem, common among Plasma implementations.
- O/T split is an offchain protocol. The current form of O/T split assumes inherit trust of T to O, especially that O will compensate T honestly and fairly. O's trust with T depends if (and how) O verifies T's work - since O has economic disincentive to provide results that fail verification, it needs to be sure transcoding results from Ts can pass verification. This becomes harder if Ts have no skin in the game. Note: O could require some stake from Ts to create disincentive for Ts to return work that fails verification. In the case of metrics-based verification, Ts have the option to report the metrics with every transcoding result.
- O/T split can result in transcoding race. This is yet to be spec'ed out.
- Redundancy and failover algorithm for Bs is an open area that can have different implementations.
- In low-latency streaming protocols like LHLS and CMAF, video segments are “streamed” via http chunk transfer. This means the data is transferred before the entire segment is created, and it can affect the security model of signature generation / verification. In this world, the signature will be generated / transferred after the segment is transferred, but transcoding work should start before the whole segment is transferred. Therefore, B can only verify the signature of a segment AFTER it's already streamed. B however, has the option to wait until the whole segment is ready before streaming it out - this comes at the expense of increasing latency (roughly the length of the segment).