Approval and backing checker timeouts

[burdges]

We decided upon using the deterministic wasmi timer at the research meeting, which enables simpler safer designs.

Idea 1. Safer for validators, but slower

• Primary backing validators runs the block in both wasmtime and wasmi and only announce if it passes both limits.
• Approval checkers and non-primary backing validators only run wasmtime, unless the block exceeds their wasmtime limit, in which case they run wasmi.
• We punish the primary backing validator for wasmi runtimes exceeding some t_good, but only declare the block invalid if its wasmi runtime exceeds some larger limit t_bad > t_good.
• We tune the wasmtime limit to be longer than the wasmi limit t_good, so that honest acceptable wasmi reports result in wasmtime running fast enough.

We'll want as few backing validators as possible anyways, so there is no reason to distinguish a primary backing validator here.

Idea 2. Faster, but maybe slightly riskier for validators

• Backing validators run the block in wasmtime (resp. native) and only announce if it passes within time t_wasmtime_backing (resp. t_native_backing).
• Approval checkers only run wasmtime (resp. native), unless the block exceeds come t_wasmtime_approve > t_wasmtime_backing (resp. t_native_approve > t_native_backing), in which case they run wasmi. We have two wasmi timeouts t_good and t_bad, so approval checkers report four cases:
  1. Valid, ran in t_wasmtime_approve (resp. t_native_approve) in wasmtime (resp. native),
  2. Valid, ran in t_good in wasmi,
  3. Valid, but ran between t_good and t_bad in wasmi,
  4. Invalid, exceeded t_bad in wasmi,
• We deny candidate rewards to backing validators if the majority of approval checkers says iii, but we do not escalate, slash, or chill, and never punish any approval checkers.
• All validators automatically benchmark and then tune their t_wasmtime_backing (resp. t_native_backing) to be faster than t_good, so that they never loose candidate rewards due to iii. All validators similarly tune t_wasmtime_approve (resp. t_native_approve) to be both slower than t_good, so that they never waste CPU due to ii, but faster than t_bad, so that i vs iv disputes should never occur. It merely provokes local retuning when ii or iii occur.

Optional 1a: If some i vs iv dispute occurs then i voters have a short window in which they rerun the block using wasmi and agree or disagree with iv voters. If all i voters agree then we do not escalate the dispute, but the i voters are still slashed 100%. In this case, their aid avoiding the delay may count somewhat in their favor in slash reversion discussions, but guarantees nothing.

Optional 1b: As an unlikely option, if a backing validator X considers a block B slower than t_wasmtime_backing (resp. t_native_backing), but observe another validator Y backing B, then X could run the approval checker scheme, but declares it votes with approval checker timeouts, and hence cannot loose candidate rewards. I fear this grows unnecessarily complex.

[AlfonsoCev]

About the idea number 2:

• I think there should be a fifth type of report for approval checkers: "invalid, the block panics". Having the two types of invalidity reports (iv. timeout vs v. panic) can help with the slashing logic.

• I don't like the idea of an approval checker getting slashed 100% just for setting their t_wasmtime_approve threshold too generously. So I propose the following:

  • If an approval checker reports v. (panic), then all validators vote. If a supermajority then reports either iv or v, we slash the backing validators and everyone who reported i, ii or iii.
  • If an approval checker reports iv. (timeout), then all validators execute wasmi, and vote. In this vote, approval checkers who previously reported i can make a new report, but this time nobody can report i. If a supermajority then reports iv, we slash the backing validators and everyone who reported ii or iii. I think being lenient here is not a security concern as the backing validators still get slashed, and we only need one timeout report to trigger this slash.

[burdges]

We could optimize disputes by running them in wasmtime if the disputer claims wasmtime terminates, but..

Approval checkers having some escape hatch sounds too risky. Anyone who votes valid for some block that wasmi cannot validate should be slashed 100%.

We should consider t_wasmtime_approve = t_wasmtime_backing because yes that distinction sounds unhelpful. And maybe other variants too.

[burdges]

We learned the variance between wasmtime and wasmi looks higher than the variance among wasmtime on different machines, so we're going to scrap using wasmi and do a wasmtime only solution.

It'll have two timeouts, t_good and t_abort. All valid votes will contain the running time and invalid votes will contain either finished or aborted. Any aborted votes still trigger dispute and escalation, but optionally aborted voters could continue running even longer and partially revert their vote. We still slash the minority 100% on dispute, even if the invalid votes say aborted.

If a block is judged valid, then we compute the median running time t after approval. If t > t_good but Vlad votes t_Vlad < t_good then we pay Vlad no rewards for this block, and reduce Vlads other rewards by (x / y / t_good) (t - t_good) where x is the parathread block price and y is the number of validators who voted under t_good, i.e. we charge Vlad for the extra blocks of data.

@AlfonsoCev will do a first draft off-line. We can send a guide PR, but any opinions as to where?