Jeff Burdges

We might add some comment that doing "batch verification" for anything heavy, like signatures, snarks, Merkle proofs, etc. gives a nice deterministic runtime which can be launched in another thread...

We're basically done for this initial stage. Alfonso never pushed anything about doing on-chain compatible arithmetic though maybe. We could mention that if the node runs the parachain code in...

We're only discussing WASM execution time here, which only begins after we successfully download the block. Approval checkers learn their assignments from the VRF of the relay chain block that...

We currently put code onto the relay chain even I think, so actually it'll halt everything anyways. We've fucked up if we permit such large blocks anyways. We do know...

We should update this to discuss non-timeout faults, like the wasm runner receiving SIGKILL due to violating rlimit, etc. We'll halt parachains whenever a super majority judges the code flawed,...

If I understand you're making two statements: 1. We could make due with a simpler timeout system since backing voters should be way stricter than approval voters. 2. Increasing the...

Anyways, I'm dubious about the ratios here for sure, but at least superficially the alpha and beta part still looks sensible because it gives assurances. We want backer / approval...

In this PR, alpha=2 and beta=3 yields approval check timeouts being 6 times as long as backing timeouts, which sounds fine I guess? I think no show delays are like...

We must support chains without their _own_ finality, since this describes parachains. We do not afaik need chains without *any* notion of finality, because afaik they're not really secure anyways....

Yes exactly.. Proof-of-work is not secure. It's especially bad on smaller chains ala https://www.crypto51.app/ but bitcoin shall be double spent eventually too ala https://economics.princeton.edu/working-papers/on-the-instability-of-bitcoin-without-the-block-reward/ We'll never fully support proof-of-work parachains...