Tweak tranche-0 start time based on block receipt

[rphmeier]

We currently just use the slot-time of the block but probably want to do something a little more complicated. Can add a block_tick to BlockEntry and use that in tranches_to_approve

[burdges]

We're always worried firstly about adversaries learning approval checkers identities too early. I believe our RelayEquivocation story covers this case fine however, meaning this issue should not impact soundness.

I'll make this more precise, so apologies for the diverging cases..

All nodes learn relay chain block headers quickly, but only later learn the relay chain block body. We actually determine both backing and availability/inclusion in the relay chain block body. There are two reasons an adversary might obstruct 1/3+epsilon nodes learning about a relay chain block R_1's body, and thus prevent it from progressing.

Case 1. If R_1 includes a good candidate, then if our adversary likes their R_1 checkers then they make an equivocation R_2 on another fork that includes a bad candidate.

RelayEquivocation covers this case by assigning checkers based upon the candidate hash. We do however want RelayEquivocation to compute the candidate equivocations.

We know the candidates included by R_1 and R_2 because they were backed in ancestors R'_1 < R_1 and R'_2 < R_2 but they might not yet be available, and thus not yet disputable. We might provide some inclusion core bitfield in the relay chain header, so that RelayEquivocation could operate based solely upon the block headers, but see below..

Case 2. If R_1 includes a bad candidate, then if our adversary dislikes their R_1 checkers then they attempt to kill R_1 by not providing the body, likely without any relay chain equivocation.

Again we might compute RelayVRF from only the relay chain block header, given some inclusion core bitfield, except..

We require availability information before reconstructing, which also impacts RelayEquivocation. We therefore require availability information from R_1's body before announcing our approval checker assignments in both cases, so..

We always wait until we've import the whole relay chain block before doing any announcements ourselves. We do however accept others approval checker assignments based purely upon the relay chain block header.

We already handle delayed announcements correctly, so this only means all announcements come in delayed by the import time for the block. A priori, this seems perfectly fine. And does not require special handling, right?

---

We'd maybe care what this looks like both with and without our fancy network time scheme, if this became more complex, but this does not look so complex.

[burdges]

tl;dr

We always wait until we've import the whole relay chain block before doing any announcements ourselves. We do however accept others approval checker assignments based purely upon the relay chain block header, which works because they're being slashed for equivocations.

We already handle delayed announcements correctly, so this only means all announcements come in delayed by the import time for the block. A priori, this seems perfectly fine. And does not require special handling, right?

I'm still kinda undecided about an inclusion core bitfield in relay chain headers, which streamlines RelayEquivocation processing without importing all forks, but places more weight upon the relay chain equivocation slashing.