Include babe randomness in the relay chain proof

[bkchr]

Before we have paritytech/polkadot-sdk#82, we should include the randomness manually for now.

This will enable parachain teams to use the randomness provided by the relay chain.

@burdges @andresilva which of randomness should we provide:

1. https://github.com/paritytech/substrate/blob/94679ebd37f4989f8f7803d4f9aa403b7ba9aead/frame/babe/src/lib.rs#L213
2. https://github.com/paritytech/substrate/blob/94679ebd37f4989f8f7803d4f9aa403b7ba9aead/frame/babe/src/lib.rs#L221
3. https://github.com/paritytech/substrate/blob/94679ebd37f4989f8f7803d4f9aa403b7ba9aead/frame/babe/src/lib.rs#L264

While 3. requires that we change Substrate to not delete it at the end of a block.

[burdges]

I'll remake that paritytech/substrate#8180 gives two nicer names, although AuthorVrfRandomness sounds nicer than CurrentBlockRandomness.

We'll want RandomnessFromTwoEpochsAgo for consensus, ideally even sequencing collators in Aura.

We want AuthorVrfRandomness aka CurrentBlockRandomness as a fast randomness source. It's somewhat dangerous for high value things, but not too dangerous if the victim controls when they submit the tx.

If someone wants a better randomness source, but not in consensus, then RandomnessFromOneEpochAgo is likely good enough and one epoch faster than RandomnessFromTwoEpochsAgo.

[JoshOrndorff]

@burdges This may be a dumb question, but could you explain (or link to somewhere that explains) why older randomness is better for conensus?

Following the definition of "unpredictability" from the fantomette paper https://arxiv.org/pdf/1805.06786.pdf (which I learned of from you; thanks for that):

Definition 3.3.A coin-tossing protocol satisfies unpredictability if, prior to some step barrier in the protocol, no PT adversary can produce better than a random guess at the value of R.

It is good if the leader election is unpredictable because adversaries can't mount a targeted attack against the next leader(s) as easily. When it isn't possible to have the leader truly unpredictable up to the moment of publishing a valid block, it is better to be "more unpredictable" by having the step barrier later in the protocol.

It seems like using randomness from two epochs ago is the least unpredictable.

Have I missed something? Or are you saying randomness from two epochs ago is better for a reason that is not related to unpredictability?

[burdges]

We want finality on VRF inputs before using them in BABE, and ditto ring VRF inputs in Sassafras, because otherwise we cannot so easily detect equivocation in block production, meaning building upon multiple forks, so adding a full epoch helps ensure finality. I suppose "one full epoch ago" and "previous epoch" might make more sense.

VRF keys should be registered before all VRF inputs become known by anyone, so this pushed VRF key registration even further back into the past.

If you're not worried about equivocations then you do not need to wait so long, but an epoch rendomness is still harder to manipulate or know in advance.

[h4x3rotab]

Phala requires VRF for probabilistic payment distribution. Unpredictable property is good, but a delay is acceptable (i.e. we know the randomness of the next a few blocks, but not later).

Background: On our network, a large amount of off-chain agents are registered on the blockchain. At every block we randomly sample a small subset of the agents, and send them online challenges. They must respond the challenge in order to keep their running state. To reduce the burden on the blockchain, the sample size is small (~20 per block).

[burdges]

Right now, we stupidly use a Vec to accumulate the babe VRF outputs for the subsequent epoch randomnesses. We'll replace this by a hash accumulator acc = hash(acc, babe_vrf_output) in Sassafras, which aside from being faster also makes randomness with a different threat model available on parachains.

[4meta5]

Moonbeam requires access to RandomnessFromTwoEpochsAgo for smart contracts that need a number that can't have been chosen by an adversary (i.e. gaming, public coin zkps). Ideally, we would like to also get the less secure Randomness storage value every block.

Where is the relay state proof code where we could include this randomness data?

[bkchr]

Sorry for the late reply.

1. You need to add the relevant keys here: https://github.com/paritytech/polkadot/blob/53115552d3f8a1e22db5a545d9524557fc3c10da/primitives/src/v1/mod.rs#L73 The storage items for two epochs ago randomness, for one epoch ago and for current block randomness
2. Then you need to add the keys here:

   cumulus/primitives/parachain-inherent/src/client_side.rs

   Line 106 in 6af1dd5

   relevant_keys.extend(ingress_channels.into_iter().map(|sender| {

3. Then the relevant data is part of the relay chain proof that is send to the Parachain runtime.
4. We probably need then some functionality to access this data. I think there is currently no such functionality outside of the parachain system.

[4meta5]

We probably need then some functionality to access this data. I think there is currently no such functionality outside of the parachain system.

Thanks @bkchr , so we have to add a storage item to parachain system for the randomness? And a trait with an impl by parachain system to expose it for other pallets.

[bkchr]

Better to store the entire proof for now with all its values. As I said, I think that doesn't exist yet.

[bkchr]

Done now, ty @4meta5