Streamflow registry in a multi-registry construction

If we choose to move toward a multi-registry construction, there is still the question of how the Streamflow registry will work and be deployed. Furthermore, we should remember that even if we move toward a multi-registry construction, there will likely only be a single registry that is used by the majority of broadcasters and orchestrators in the short term.

My current thoughts on the updates required for Streamflow if we move toward a multi-registry construction are:

• Update the current base staking contract system to support the integrated workflows involving different verification/payment protocols for different registries as described in #22
• Deploy a Streamflow registry that uses PM for the payment protocol, sets a maximum # of orchestrators and max global float to be used to set the required reserve for PM and uses a centralized metrics based probabilistic verification for the verification protocol [1][2]
• Integrate the Streamflow registry with the updated staking contracts

Many details around how this should be implemented in practice need to be worked out, but this issue aims to lay out an initial proposal for the Streamflow registry.

[1] As has been discussed offline, there is a fair amount of concern on the accuracy of probabilistic verification (research is still on-going). One unknown at the moment is the performance characteristics of the verification task i.e. what the computation overhead involved with running the task is. If the overhead is small, one mechanism to explore is for orchestrators to run the verification tasks themselves in order to ensure that it never sends signed segments to broadcasters that can be slashed. There are additional details to be worked out, but one design proposed by @dob is for the orchestrator to send unsigned segments to broadcasters whenever it observes that a segment is slashable (perhaps a false positive from the verification task) and transcode the next segment for free. Regardless of such details, this only works if the verification task can be run with little overhead by the orchestrator. Another unknown is whether we can make the verification task deterministic to guarantee that it produces the same result regardless of who runs it when. Another path to explore is for there to be a time lock whenever the centralized verifier triggers a slash. During this time lock, a set of parties can manually intervene and cancel the slash if needed.

[2] The use of a maximum # of orchestrators rather than a minimum stake along with the global max float is to define a single required PM reserve for a broadcaster that only needs to be set up once. See #18 for more details

Start by reading the integrated workflows described in #22 and the required PM reserve details in #18, then review this issue's proposed registry, staking-contract, and verification changes. The work is not ready to implement until the multi-registry design and unresolved verification details have been decided and documented.