How does Automata VRF work
The VRF system consists of:
DRAND as an entropy source.
Off-chain oracle.
AutomataVRFCoordinator
contract.
The flow for each component is the following:
An off chain oracle is responsible for performing the following tasks in a trusted manner (e.g. execution in TEE)
Computes the SHA256 hash of the signature, to match with the randomness value given by DRAND.
Computes
hash_to_field
operation on the message.Generates SNARK proof for the
BLS12-381
signature verification.Generates a final
uint256
random number.Produces
secp256k1
signature over the random number.Submits the final random number, the
secp256k1
signature, computedhash_to_field
value and SNARK proofs toVRFCoordinator
VRFCoordinator
is responsible for the following:After the Off Chain Oracle has published randomness on chain:
Performs
ecrecover
to ensure the randomness is signed by a trusted off chain oracle.Re-construct
hash_to_field
to match with the input. This step serves as a point of revert for mismatch of hash, to prevent spending unnecessary gas on the SNARK verification.Performs SNARK verification of the
BLS12-381
Signature.After passing all of the above verification steps, it updates the state of the program, allowing consumers to fetch the latest round of randomness.
Consumers can invoke:
VRFCoordinator.getLatestRandomness()
VRFCoordinator.getLatestRandomWords(uint32 numWords)
VRFCoordinator.requestRandomWords()
Or query event logs, to get randomness from past rounds.
Detailed Description of the Trusted Off Chain Oracle Workflow
Upon receiving new randomness from DRAND, it performs SHA256 of the current BLS signature to verify the correctness of randomness. Denote DRAND randomness as A.
Sends the DRAND parameters to an API service that generates the following:
55x7 integer representation of the BLS signature for the current round.
hash_to_field
value.SNARK proof for the BLS signature verification.
Generates a randomness of its own, denoted as B.
Performs A XOR B, to generate C.
Generates a final randomness R, using C as the seed.
Signs over the hash of the concatenation of R and SNARK proofs with
secp256k1
ECDSA.Submits the randomness to
AutomataVRFCoordinator
, with the following parameters:DRAND return values.
SNARK proof, consists of uint256[2] proof_a, uint256[2][2] proof_b and uint256[2] proof_c. See here for reference of converting
proof.json
to the proper format.hash_to_field
The final R value. (Randomness)
The ECDSA signature
Detailed Description of AutomataVRFCoordinator
AutomataVRFCoordinator
The consumer should be aware of the difference between a randomness value and random words:
Randomness: A single
uint256
verifiable random value generated by the oracle. It can be used as a seed to perform more complex random generation.Random words: This is a list of
uint256
words generated by taking the hash of the randomness value concatenated by its index. It can generate at most2**32
random words in a single call. Consumers are free to specify the number of random words to produce from the randomness generated at the latest round. The code below describes how they are computed:
There are three ways which a consumer can fetch the latest randomness or list of random words:
Invoke
VRFCoordinator.getLatestRandomness()
. This method returns the final randomness R generated by the off chain oracle. This is most likely called by an EOA, or a smart contract that does not conform with the Chainlink VRF workflow.Invoke
VRFCoordinator.getLatestRandomWords(uint32 numWords)
. This method returns a list of random words, with the number of elements specified bynumWords
. It is most likely called by an EOA, or a smart contract that does not conform with the Chainlink VRF workflow.To provide compatibility with existing contracts that consumes Chainlink VRF (e.g. the calling contract extends the
VRFConsumerBaseV2
interface), consumers can invoke therequestRandomWords()
entrypoint.
Additional note on #3: If the consumer contract were to indirectly invoke the entrypoint via the LINK token transfer callback, the Receiver handler function would forward the call to the entrypoint and refund LINK tokens back to the consumer contract. However, this also would cost more gas than directly calling the entrypoint.
Last but not least, an event is defined in this program to allow consumers to query for randomness produced for all past rounds.
Consumer-facing Interface for AutomataVRFCoordinator
Last updated