Why should the RANDAO be included in every block for sharding? (For pure PoS this is something that is easily achieved by construction.)
I’m optimistic that the random beacon can be “offchain native”, i.e. be produced and immediately consumable offchain. This would allow for shards to have low variance 5-second periods, have a small lookahead, and not have to worry about timing of the main chain.
At a high level we want an offchain game to generate a random beacon where the outputs enjoy high offchain finality. For RANDAO we have a simplified consensus game which can be “hardened”:
- There are only small “headers” (the beacon chain) and so no hard data availability problem for “bodies”.
- The beacon chain is “quasi-deterministic” in the sense that the game is predetermined modulo skipping.
- By notarising the beacon chain (very similar to what was suggested here for the shards themselves) we can greatly tame offchain forking. This is especially true if we assume a global clock and honest majority.
- Using PoSW we may be able to “enforce” the clocking, further reducing forking opportunities.
- The notarisation process in 3) can be complemented with onchain notarised checkpoints (honest-majority or uncoordinated majority). Even with relatively low-frequency checkpoints (say, one checkpoint every 10 minutes) the shards can still progress (with high confidence) using offchain randomness freshly produced every 5 seconds.
- We may be able to remove forking altogether (producing a deterministic beacon chain, basically killing the consensus game) with a “patch-the-hole” threshold scheme complementing RANDAO. I’ll write a post shortly. The basic idea is that a committee can force-reveal the preimage of a participant that doesn’t show up.
I’m leaning quite heavily towards separating collation timing from main chain blocks. Having said that, how does using a reasonably recent main chain block hash work?
If the shards have 5-second periods and some main chain block takes one minute to produce (because of variance), does this mean that the shards will be stuck with the same RNG output (the one 5 blocks ago) 12 times in a row?
In addition to a possible additional “buffer” lookahead, does this introduce a grinding attack because of shard-to-main-chain synchronisation? That is, the concept of “5 blocks ago” is subjective from the point of view of the shards, so at every period there is an ambiguity as to which blockhash is the one that is 5 blocks old.