Expose entropy to Refinement

[gavofyork]

Refine is stateless, which means it would need its own entropy mechanism since on-chain entropy would be far too old to be useful in a dynamic setting.

We can reasonably get some baseline entropy through the guarantor VRF; guarantors can calculate some VRF based on the (hash of the) work-package. Two validators can share this between themselves and hash them into a RNG seed before doing all the Refinement for a WP.

A new Boolean field is introduced into the work-package to specify whether 2 or 3 guarantors' VRFs shall be used. Builders may set this. Work-items also have this flag, and the OR over all WI's flags IMPLIES the WP's flag.

WI/WP builders must decide the value of this flag; if all three guarantors' VRF outputs are required, then the entropy will be strong but the core may stall if at least one guarantor malfunctions. If only two are required, then the core has no new reason to stall, but under some networking circumstances and with a potential loss of rewards, one malicious guarantor could throw the entropy between one of three values.

Changes

Invocations

Authorizations may inspect this flag as part of the WP.

Refinements may inspect the entropy as well as the VRF outputs used to create the entropy. These can be fetched.

Accumulations may inspect the flag from the WP responsible for the WI, as well as the flag from the WI itself. This could be fetched or passed in directly (it is less than one additional byte per WI).

Data structures

Work-packages must have the new flag.

Work-items must have the new flag.

Work-reports must inherit the flag from their WP.

Work-digests must inherit the flag from their WI.

The work-bundle must be extended to contain the two or three VRF proofs that would be used to audit the entropy used.

Auditing

Auditing involves verifying that the VRF proofs are valid and that the flag is respected, then utilizing the VRF output to determine the entropy and using that for Refinement.

Networking

For 3-guarantor entropy:

• The guarantor sharing a WP shall include their own VRF output.
• The (success) response of the co-guarantor should include their own VRF output for the WP.
• The initiating guarantor shall then share the extrinsics, imports.
• Finally, the third VRF output can be shared, if available.
• The guarantors should proactively share their own VRF-outputs with the others if not covered in the exchange above.

For 2-guarantor entropy:

• The guarantor sharing a WP shall include their own VRF output.
• The (success) response of the co-guarantor should include their own VRF output for the WP.
• The initiating guarantor shall then respond with their choice of VRF output combination, intentionally selecting the two guarantors with the lowest validator indices if possible.
• The initiating guarantor shall then share the extrinsics and imports.

Choice of Crypto

Ideally the crypto used for the VRF would overlap with that of the guarantee signature and thus minimise overhead.

Disclaimer

This is not intended to be an exceptionally high-quality source of entropy, but depending on the usage of two or three guarantors could provide a good baseline of dynamic entropy for certain applications.