The proposed architecture is split into an on-chain and an off-chain component:
getPseudoRandom
; rather, there is a new function supplyRandom
that accepts (uint256[2] calldata pk, uint256[2] calldata gamma, uint256 c, uint256 s, uint256 alpha)
. This function is whitelisted to a number of addresses that will correspond to off-chain software run on our servers. The contract will be endowed with methods for whitelist manipulation. In addition, a pointer
to a current position in the list of random numbers will be maintained. Upon reception of the proof from a whitelisted address the contract must check that the most recent submission is no less than an interval
in the past, checks the proof, generates the randomness from it, and writes the obtained number at the pointer
. The pointer
is incremented modulo the list length (so, in essence, we have a cyclically updated list, one number at a time).<aside> ⚠️ The order of submission is governed off-chain. We can afford it because everything is in-house.
</aside>
The off-chain component. This script connects via WebSockets to an RPC and monitors it. It has two conditions for triggering randomness generation and sending:
block.number/blocksInEpochContract.whitelistedkeepers.length
. This makes sure that everyone has a window within which to submit.(id == block.number/blocksInEpochContract.whitelistedkeepers.length) or ((id - 1 == block.number/blocksInEpochContract.whitelistedkeepers.length ) and (lastRefreshmentTooStale))
Upon sending, a proof is generated and sent. The randomness is produced on-chain therefrom.
The proposed algorithm is described in Making NSEC5 Practical for DNSSEC (iacr.org) and RFC 9381 - Verifiable Random Functions (VRFs) (ietf.org) (the latter developed on the basis of the former).
PUBLIC ON-CHAIN INSTANTIATION PARAMETERS
OFFCHAIN SIDE