Local verification of random samples with mutually agreed upon verification oracles

Nobody has claimed this yet.

# Local verification of random samples with mutually agreed upon verification oracles

For every input segment `seg_data` with a set of requested transcoding options `t_opts` that B sends to O, B also sends the signature `b_sig = sign(b_priv_key, H(seg_data) + H(t_opts) + verifier_addr)`. `verifier_addr` is the address of the verification contract that B wishes to use when challenging segments. In practice, B's client would contain a list of addresses for well known verification contracts (one contract could have the off-chain verifier run a bitexact verification task and another contract could have the off-chain verifier run a metrics based probabilistic verification task) that B could select from. B could discover the verification contracts that O supports off-chain using periodic requests (which would likely also be used to refresh price menus and latency measurements). `b_sig` cryptographically binds the input segment, the set of transcoding options and a verification contract to B's ETH address.

If O does not want to use the verification contract at the `verifier_addr` requested by B, O can refuse to transcode B's input segment. Otherwise, O produces a transcoded result `t_res_i` for each transcoding option `t_opts_i` contained in the set of transcoding options `t_opts` requested by B. For each `t_res_i`, O also sends the signature `o_sig = sign(o_priv_key, H(seg_data) + H(t_res_i) + H(t_opts_i) + verifier_addr)` to B. `o_sig` cryptographically binds the input segment, the transcoded result, a specific transcoding option and a verification contract to O's ETH address.

B defines a verification rate parameter `v_rate` - every `v_rate` segment that it sends, B will randomly sample a transcoded result from the set of all transcoded results received for the last `v_rate` segments.

Let `seg_data` be the sampled input segment, `t_opts` be the set of transcoding options for the sampled input segment, `t_res_i` be the sampled transcoded result and `t_opts_i` be the specific transcoding option (i.e. rendition) corresponding to `t_res_i`. B runs a local verification task (this could be the metrics based probabilistic verification task regardless of what verification task the selected verification contract uses) using `seg_data`, `t_res_i` and `t_opts_i` which results in a pass or fail. If the verification passes, B does nothing. If the verification fails, B initiates an on-chain challenge:

1. B uploads `seg_data` at `seg_data_storage` and `t_res_i` at `t_res_storage` at a storage provider i.e. IPFS, Swarm, S3
2. B submits `H(seg_data)`, `H(t_res_i)`, `t_opts`, `t_opts_i`, `o_sig`, `b_sig`, `seg_data_storage` and `t_res_storage` to the verification contract at `verifier_addr`.
3. The verification contract checks that `o_sig` is valid for `H(seg_data)`, `H(t_res_i)`, `H(t_opts_i)` and `verifier_addr`
4. The verification contract checks that `b_sig` is valid for `H(seg_data)`, `H(t_opts)` and `verifier_addr`
5. The verification contract checks that `t_opts_i` is in `t_opts`
6. If the above checks pass, the off-chain verifier fetches `seg_data` from `seg_data_storage` and `t_res_i` from `t_res_storage`. The off-chain verifier checks that `seg_data` matches `H(seg_data)` provided on-chain and that `t_res_i` matches `H(t_res)` provided on-chain.
7. The off-chain verifier runs the verification task using `seg_data`, `t_res_i` and `t_opts_i`. The result (pass or fail) is submitted back to the contract.
8. If pass, nothing happens. If fail, the orchestrator (address recoverable from o_sig) is slashed.

Note that the verification contract at `verifier_addr` can only be used if BOTH B and O authorize its usage - B authorizes usage of `verifier_addr` by including it in the signed data when producing `b_sig` and O authorizes usage of `verifier_addr` by including it in the signed data when producing `o_sig`.

Start by reviewing the proposed local sampling flow, signed data, verification-contract checks, storage steps, and challenge sequence in the issue. The payload names no files, tests, or entry points, so first identify where this protocol belongs in the research repository; done would require an agreed implementation scope and validation plan.

Written by the indexing model from the issue text.