From 7ce255520117317633b4cb039f316e2ea25f1fc2 Mon Sep 17 00:00:00 2001 From: iquerejeta Date: Tue, 27 Jul 2021 15:29:49 +0200 Subject: [PATCH] update on deterministic randomness --- VRF_BATCH.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/VRF_BATCH.md b/VRF_BATCH.md index 40b8490..5f36229 100644 --- a/VRF_BATCH.md +++ b/VRF_BATCH.md @@ -213,21 +213,20 @@ Note that this performance only considers steps 4 and 5 of the algorithm (see ab This does not represent the time of verifying 1024 proofs. ### On the purity of VRF batching -It is of interest to mantain the purity of the VRF verification intact. If for +It is of interest to maintain the purity of the VRF verification intact. If for batch verification we require a source of randomness to divide each of the verifying equations, this purity would be lost. Hence, we explore how would be the best way to compute this randomness in a deterministic manner. The important property -of this deterministic randomness generation, is that the value can only be known -to the verifier. Which raises the question---what value(s) can we use to deterministically -(by the means of hash function) generate this randomness? +of this deterministic randomness generation, is that the value CANNOT be known +to the prover at the time of generating the proof. Which raises the question--- +what value(s) can we use to deterministically (by the means of hash function) +generate this randomness? * The inputs to the verification function are the public key, the proof itself, and the - string used to generated randomness. All these values are known to the prover, and there - cannot be used (uniquely). -* This means that there is nothing `linked` to the proof itself that can be used to produce - the batch verification scalars. -* We would therefore require the verifier to introduce a secret which would then be used - to hash multiple times to generate the different randomness. If we generate this secret - randomly, we are back at square one (and a half--- in this case we only need to - generate randomness once). - + string used to generated randomness. All these values are known to the prover, but + only the proof itself is unknown when generating the proof. +* The evolving nonce of each block would also be another candidate to consider. It's + value is included in the header (where the VRF proof is included), and therefore is + not known at the time of proof generation. +* Finally, the block body hash could also be a candidate. More information can be found +in the [Shelley formal spec](https://hydra.iohk.io/build/6752483/download/1/ledger-spec.pdf).