Provide randomness from relay chain VRF output. Also clock from median algorithm

[burdges]

We expect that parachains might lack enough collators to produce secure randomness, even if they run sensible BABE configurations. If they run AURA with collective flip then their randomness could be significantly worse than their own blockhash. We should provide randomness from the relay chain VRF for use in parachains.

We need each parachain block to acknowledge some parent-like block on relay chain, yes? I suppose the watermark in XCMP gives one example, but way too loose for this use case. Our new A&V design has two relay chain blocks R_2 > R_1 associated to each a prachain block B_1, the second R_2 when B_1 actually runs may not yet exist when B_2 > B_1 gets created, but R_1 exists.

Anyways..

There is always some relay chain parent-like block so it's VRF would provide good randomness for the parachain.

Afiak, there is not much reason to work on this until A&V spec and implementation get more nailed down.

cc @AlistairStewart @rphmeier

[rphmeier]

Yeah. Each parachain block executes in the context of some specific relay-chain block. @coriolinus has done some investigation into passing the hash or header of that block into the validation function. That would allow us to track the BABE randomness, although not in the most space-efficient way - we'd want updates only at the end of each epoch in practice.

[bkchr]

@rphmeier I think we would need to pass the randomness the same way we do it in Substrate, as inherent digest. If we just pass it into the validation function, we could not use it while building a block.

[burdges]

There are applications that like randomness faster than each epoch, but some like games require minimal security. We'll work that out after A&V gets more nailed down.

I think randomness tied to BABE/Sassafras epochs actually helps enormously, so thank you for suggesting it. In particular, some parachain BABE/Sassafras variant could use the relay chain's BABE/Sassafras randomness, which saves them doing their own security analysis to choose their own parameters, which dramatically simplifies parachains deploying BABE/Sassafras. Also, parachains can simply wait an epoch then they require more secure randomness for auctions or whatever.

[burdges]

We should pass the relay chain clock produced by the median algorithm too. paritytech/substrate#5978

[JoshOrndorff]

I want to check in on the status of this issue. Moonbeam has been planning to use the relay chain randomness for quite a while. We've mocked it by using collective flip all along. As parachains launch approaches we are wondering whether babe randomness will be available.

Ideally we'd like it faster than every epoch. I was thinking we'd get it every block.

I'm willing to put some time into buiding this. Is there any more recent thinking or a rough design that I could start to think about?

[burdges]

We should expose the VRF output from a relay chain parent to candidates building upon that relay parent. We should expose epoch based randomnesses too of course, as that's useful for parachains consensus, but application level parachain code usually wants the relay chain VRF output I think.

We're happy to chat about specific cases with folks of course.

[bkchr]

This is basically a duplicate of paritytech/polkadot-sdk#82. While this was created earlier, the linked issue more general. So, I'm going to close this.