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.

[burdges]

We could read block headers via paritytech/polkadot-sdk#82 or do you mean we insert the relay chain block's VRF distinguished somehow in the relay chain state?

At some point, we were shoving relay chain VRFs into a Vec, which sounds bizarre and should eventually be replaced by accumulate them like under_construction = H(under_construction,relay_vrf), although we could still insert the relay chain VRF somewhere I guess.

[bkchr]

The randomness is stored on chain in the relay chain state https://github.com/paritytech/substrate/blob/master/frame/babe/src/lib.rs#L213

Or do I miss something here?

[burdges]

That's randomness accumulated during some previous epoch. As in paritytech/substrate#8180 we've RandomnessFromOneEpochAgo and RandomnessFromTwoEpochsAgo in state, but CurrentBlockRandomness exists in the header, and may or may not appear in a usable way in the state, but whatever way it does appear changes with https://github.com/w3f/research-internal/issues/691

Anything consensus likely wants RandomnessFromTwoEpochsAgo. A recent project of Shawn's favored RandomnessFromOneEpochAgo. We expect parachains that need fresh randomness favor CurrentBlockRandomness, although this turns out the weakest.

[bkchr]

https://github.com/paritytech/substrate/blob/master/frame/babe/src/lib.rs#L264 we could make this stay in state, so we can access the current block randomness.

[burdges]

Yes fine. We do not even need it to persist, just be there in the relay parent's output state.

[bkchr]

For that we need to persist it ;D

[burdges]

Right, I meant the next block after the relay parent could overwrite it since we're referencing it using a proof into the relay parent state