Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
yondonfu opened this issue Mar 25, 2019 · 2 comments

Comments

@yondonfu
Copy link
Member

yondonfu commented Mar 25, 2019

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.

@yondonfu yondonfu changed the title Mutually agreed upon verification oracles Local verification of random samples with mutually agreed upon verification oracles Mar 25, 2019
@yondonfu
Copy link
Member Author

yondonfu commented Apr 12, 2019

Different verification tasks can vary in their computation cost. As mentioned in the open problems/questions section of the challenge protocol problem statement, if the transaction cost for initiating a challenge < the computation cost of the verification task + the transaction cost of submitting the result on-chain, then there is a griefing vector > 1 meaning for every $1 of cost incurred by a malicious broadcaster, it can incur > $1 of harm on the verifier running the verification task. This griefing vector is accounted for in verifiable computation protocols like TrueBit where the task giver must pay money to incentivize third party verifiers. The griefing vector should also be accounted for in a centralized verification model.

Each verification contract could define a required bond or payment that a challenging broadcaster needs to put down. The required bond/payment would be set based on the execution cost of the verification task associated with the particular verification contract (pricing issues might need to be factored in...i.e if the bond/payment is denominated in ETH and the ETH/USD exchange rate falls then the bond/payment might end up being less than the execution cost of the task).

@yondonfu
Copy link
Member Author

yondonfu commented Jul 2, 2019

An implication of mutually agreed upon verification oracles is that depending on the type of verification oracle used, the SLA between a broadcaster and orchestrator can vary. When the oracle outputs the result of either a bitexact verification or metrics based classifier, the SLA between a broadcaster and an orchestrator is: "The orchestrator will transcode a segment based on the options provided by the broadcaster such that given the result and input segment the oracle will indicate whether the transcoding was correct or not".

An oracle can also output the result of a quality score verification that checks whether for a input segment the transcoded result has a minimum quality score of Q, a resolution of R and a maximum bitrate of B. In this case, the SLA between the broadcaster and orchestrator is: "The orchestrator will transcode a segment that has a minimum quality score of Q, a resolution of R and a maximum bitrate of B where Q, R and B are specified by the broadcaster". This type of SLA essentially allows a broadcaster to dictate what the constitutes "correct transcoding" rather than the definition of "correct transcoding" being fixed globally.

The quality score verification oracle would define a fixed, public and transparent quality score function observable by the entire network. Broadcasters could use the function to determine what a reasonable quality score is. Orchestrators could use the function during internal benchmarking to determine what combinations of Q and B could be reasonable achieved. Then, within the marketplace, orchestrators would only accept segments that use the quality score verification oracle if the desired Q and B can be achieved by the orchestrator. It is worth noting that as with all fixed, public and transparent functions if there is an economic benefit from gaming it using specially crafted inputs, then over a long enough time horizon there is good chance that it will be gamed. At the very least there is a clear upgrade path - a new oracle can be deployed that uses an updated function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant