Light-weighted Manipulation-proof Random Number Generator for smartBCH

In our early article introducing cloud enclaves, a mechanism for building manipulation-proof random number generators (RNG) with SGX enclaves was presented. Now we are planning to implement this mechanism on smartBCH, as our first real-world use case of SGX enclaves, and an important step for gathering experience before using enclaves in SHA-gate.

This mechanism combines VRF and enclaves. The enclave contains VRF's private key, which is used to generate a pseudo-random number and its proof for each block's hash. Anyone can use the VRF's public key and the proof to verify the generated pseudo-random is valid. The enclave keeps the private key a secret, so the generated pseudo-random cannot be predicted even if you know the block's hash.

In the following sections, we'll compare this mechanism to two existing common mechanisms for building RNG and introduce its implementation details.

A comparison of RNGs

VDF (verifiable delay function) and the commit-reveal scheme are two widely used mechanisms for RNG.

VDF is a hash function that takes a long proveable time to compute but only a short time to verify. The block hashes are fed into VDF and the outputs are used as fair random numbers. Since the computation of VDF requires a proveable time to finish, the proposers can't try different hashes and pick the best.

The most beautiful part of VDF is that it does not need to trust any human. You only need to trust math (there is no cryptography algorithm that can reduce its computation steps) and physics (humans cannot manufacture semiconductor devices to speed it up dramatically).

Unfortunately, VDF is not so mature. On vdfresearch, you can find many VDF algorithms, but none of them are standardized. And VDF's physical research is just beginning. Another bad news is that the "short" verification time of VDF is still orders of magnitudes higher than plain ECDSA signatures, which makes this solution not cost-effective enough.

The commit-reveal scheme guides a quorum of operators to generate a fair random number. If these operators do not collude, i.e., at least one of them is honest, then the final result can't be manipulated. This scheme is very mature for it has been extensively tested in the field for years and Ethereum's RANDAO is based on it.

However, it has an availability issue: if some anticipator is offline and fails to reveal after committing, the result can't be generated. This issue can be alleviated by incentivizing the operators to ensure availability by using more hardware resources for redundancy. Furthermore, each new random number needs a lot of transactions for operators' committing and revealing, so it is much more expensive and takes a longer time than plain block hashes.

VRF is standarlized by IETF, and Intel SGX enclaves have been working in the field since 2015. They are both mature techniques. Although some vulnerabilities have been found for SGX in hyperthreading-enabled CPUs, they can be easily bypassed by disabling hyperthreading.

Compared to plain block hashes, the only operation the VRF+Enclave mechanism adds is one VRF verification. So the cost and delay are both very low.

Based on athe bove analysis, we compare these three mechanisms in the following table:

CostTrust ModelMaturityVDFHighTrust math and physicsLowCommit-RevealHighTrust a quorumHighVRF + EnclaveLowTrust hardware manufacturerHigh

It is clear that the VRF+Enclave mechanism do have some advantages and it is worth implementing.

How we implement the VRF+Enclave RNG

The source code implementing the VRF+Enclave RNG is already opensourced. The code is short and easy to understand. Here we just want to highlight some key points.

First, the enclave does not verify the block hashes fed to it. They may be invalid block hashes or some other chain's block hashes. Because the enclave does not run smartbchd itself, they do not know what the correct block hashes are. Instead, it just delays returning the VRF output. If you feed a block hash to it, it will delay five seconds before returning the VRF to you. Thus, even if a validator tries to utilize it to try different possible block hashes and pick the most beneficiary one, she will miss her time window of proposing a new block.

Second, there is a quorum to endorse the enclaves. The most important step of using enclaves is attestation. Attestation ensures that a web service is really running inside an enclave and its binary code is as expected. Although using utilities provided by Azure to attest to an enclave is easy for a programmer, most plain DEFI users may still find this job too hard. So we will invite some trustworthy developers in the smartBCH ecosystem to attest to the enclaves. Then they can endorse a VRF public key stored in a smart contract. The smart contract is also used in verifying VRF outputs of block hashes. Its solidity code can be found here.

Last but not least, to ensure availability, multiple nodes on different machines provide the same service, i.e., they keep the same VRF private key. The private key is generated in a master enclave and broadcasted to several slave enclaves. To prevent the private key from leaking, the master enclave will attest to the slave enclaves to ensure they are real enclaves and run the correct binary code.

Conclusion

Building a random number generator using the VRF+Enclave mechanism has several advantages. So we implement it as in the enclave-vrf repo, and plan to deploy it on smartBCH in the near future.