Multi-registry construction

The Livepeer protocol can be viewed as a composition of a set of protocols that provide different features (i.e. economic security, payments, verification, etc.). In V1, we designed the Livepeer protocol as a composition of a single staking protocol, a single verification protocol and a single payment protocol. As a result, the network ended up with a single global rule set.

The below diagram depicts an alternate design:

This design maintains a single global staking protocol, but allows for the existence of different verification and payment protocols which are implemented by different service registries. The staking protocol simply serves as the foundation for additional protocols to be built on top. As a result, the global rule set becomes smaller because the rules around verification and payments are now moved to a higher layer of the stack.

While the state for staking will be managed at a global level via a single set of contracts, each service registry will have its own set of contracts that implement specific verification and payment protocols. Furthermore, each service registry can define its own rules for entry (and eviction). For example, a registry could define a specific maximum number of orchestrators that can join and once the registry is full a new orchestrator can only join if it has more stake than an already registered orchestrator (i.e. how the V1 on-chain transcoder pool works). Or, a registry could define a minimum stake requirement and whenever a new orchestrator registers, the registry will query the staking contracts to check an orchestrator's eligibility.

Below is an initial sketch of what the integration of different service registries with the global staking contracts might look like:

After registering with a particular service registry:

• An orchestrator's stake will be subject to the slashing rules defined by the registry's verification protocol. See #23
• How an orchestrator accepts payments from broadcasters will be defined by the registry's payment protocol. See #24

Start with the two diagrams and the descriptions of global staking contracts and per-registry contracts. Review the related verification and payment work in issues #23 and #24. The issue does not define a concrete implementation target or a testable completion condition.