The TEA Project’s Hardware-based VRF
Crypto ecosystems need to incorporate randomness at various points in their architecture to ensure their network is robust and fair. Smart contracts have deterministic inputs and outputs and need to inject randomness to thwart off hacks. There’s also the issue of how incentives are distributed fairly in crypto which is another facet where injected randomness comes into play.
A verifiable random function (VRF) is a pseudorandom function based off of a public-key that also provides proofs that its outputs were calculated correctly. This post will take a look at the importance of verifiable random functions for various crypto projects.
We’ll touch on their implementation and contrast it to how TEA verifies randomness using hardware. We’ll finish off by showing how VRF is crucial to the TEA Project’s remote attestation process, a core function that allows our layer2 nodes to be trustable and run at full speed.
Polkadot VRF
Polkadot algorithmically generates random numbers by using the hash of previous VRF values as a seed. The function is verifiable as it generates both a random number and a proof of randomness as a result. Here’s an explanation from the Polkadot wiki:
A blockchain like Polkadot needs VRF as it’s not using PoW to validate new blocks. Without VRF, Polkadot (a Proof of Nominated Stake blockchain) would not have a verifiably random function to choose the next block issuer. VRF is also important for any smart contracts executing on one of Polkadot’s parachains. Imagine if multiple transactions in the same block shared the same random seed. That could give users of, say, a gambling app an unfair advantage through on-chain snooping.
CryptoSat VRF
The CryptoSat project uses build satellites that form trusted modules for blockchains and other crypto-related applications. CryptoSat launches small cube satellites into space each with a random number generator embedded inside. The source of the random number generator could be anything outside of it as it uses a sensor to pick up a random quantifiable aspect of the phenomenon it’s measuring.
The primary advantage of CryptoSat is that no one can touch the satellite. Since it’s been launched into space, it’s guarded by isolation from being physically hacked.
The TEA Project’s Construction and Use of VRF
VRF is used in the TEA Project’s remote attestation (RA) process as it’s very important to decide who will RA who. During remote attestation, a random number is sent with a public key bi-directionally among tester and testee. It’s designed this way to verify that who sent it is in fact who said they sent it. If someone can designate which nodes will undergo RA, then this person would have the power to control the RA process in general. VRF is implemented within the TEA Project so that no one can control the RA process.
The TEA Project is also actively integrating VRF into its task dispatching algorithm.
- VRF is used to decide which node will run any particular task and who will be its verifiers.
- Anyone in this verifier group can verify that it’s using a VRF, so they’ll know it’s valid.
- After the task is executed and any traces are cleaned up, the particular VRF that was run will be posted in public (either to layer1 or layer2) so that everyone else can verify it.
During the execution of the task, only the executor and the verifiers know which node is running the task. After execution, everyone else can verify who was running the task. There’s no issues with data leaking as the task has already been cleaned up of any identifying traces as part of the post-execution algorithm.
TEA Project’s Hardware Root of Trust for VRF
An integral aspect of the TEA Project is that one of our roots of trust is in hardware, specifically that each of our trusted nodes has a TPM chip inside. In the TEA Project’s implementation of “VRF,” it’s the TPM hardware that generates a random number. This number can be verified as random using trusted computing technology. Ours is a hardware-based way of performing VRF, not the algorithmic math way as found in most other projects.
The benefits of our TPM-based approach is that it’s much faster and cheaper compared to algorithm-based VRFs. We can trust the result as long as we trust the hardware. Of course, whoever doesn’t trust hardware will not trust this kind of VRF either.
What do you think of this new form of VRF? To continue the conversation, please join us in our Telegram group: https://t.me/teaprojectorg
