Verification protocols in a multi-registry construction

In a multi-registry construction, each service registry can define its own Verifier contract which specifies the rules of when an orchestrator in the registry can be slashed based on a challenge initiated by a broadcaster. Examples of Verifier contract implementations include:

- A "human judgement" verifier that is controlled by a trusted m-of-n multisig
- A metrics based probabilistic verifier that is controlled by an automated centralized party
- A bitexact verifier that is controlled by a decentralized verifiable computation protocol such as [Truebit](https://truebit.io/) or [Arbitrum](https://www.usenix.org/conference/usenixsecurity18/presentation/kalodner)

Some benefits of having separate verification protocols for each service registry include:
- Not tying the broader Livepeer protocol to a single global verification protocol
- Allow verification protocols to evolve faster without requiring global coordination for an upgrade
- Allow broadcasters and orchestrators to opt-in to verification protocols with stronger trust assumptions by choice in order to enable video services that otherwise would not be presently possible (i.e. video filters, dynamic content insertion, etc.)
- Give broadcasters and orchestrators the ability to choose their trust model

Below is an initial sketch of what the integration of different verification protocols in different service registries might look like:


No files, tests, or entry points are named. Start by treating the issue as an architectural research proposal and clarify the intended integration scope, then define an implementation target and acceptance criteria for registry-specific Verifier contracts.

Written by the indexing model from the issue text.