Random Number Generation in Gardener
In this story, I will try to address the problem of generating random numbers on blockchains, review existing solutions to this problem and propose one that we may use in the Gardener oracle.
Perennial problem of RNG
Generating randomness programmatically has been a deceptively complex challenge that occupied minds of many coders since… well, since the beginning of time on 1 January 1970 00:00:00 UTC ;). Those familiar with random number generation (RNG) problem know that all of the software-based random algorithms are generating pseudo-randomness (PRNG) as opposed to true-randomness (TRNG). In short, it means that computers generate random numbers based on a variable called a seed. Consequently, if a malicious user uncovered the value of such a seed or took control over it, it would compromise the validity and security of a PRNG. In most cases PRNG is still good enough as it’s executed server-side, protected from the evil of this world by infrastructure.
Due to the transparent nature of blockchain and isolation of respective blocks, this challenge is only magnified in the blockchain environment. Smart contracts can’t access data from the outside world, so in order to provide seed for on-chain PRNG, we would need to use some data that is also available to a miner. On top of that, our code is transparent so every malicious Charlie out there knows exactly the method of supplying the seed to PRNG. All of these issues suggest that on-chain RNG is out of the question and a blockchain oracle needs to come to the rescue!
Blockchain solutions to the RNG problem
There have been some attempts to resolve RNG on blockchains, despite all the obstacles. I have listed the most interesting ones below:
Block-Hash
The easiest, naive solution: it uses block hash as a seed for an on-chain PRNG. Block hash is obviously deterministic and known to a miner at the time of PRNG execution. It means that given sufficient economic incentive, a miner could discover the value of the seed and therefore the PRNG result before smart contract code finishes its execution. For simple blockchain applications this might be good enough, but if we’re talking high stakes in terms of money or confidential data such as lotteries, elections and some supply chains, using block-hash based PRNG is out of the question.
Ginar
Ginar is a pretty clever solution that combines public and private blockchains to facilitate a PRNG that is fully on-chain while still being secure enough. The key to achieving sufficient security is using multiple, randomly-chosen nodes to generate a single number. Every chosen node generates a hash and all of these hashes are then used to generate a final number. This means that if at least one chosen node is a good citizen that has not been tampered with, the result will be correct. This can be further confirmed by a verification protocol that allows callers to verify that the generation process was not circumvented. Some obvious downsides include introducing a trusted party in Ginar and the fact that it is quite a pricey solution.
Provable (previously Oraclize)
Provable is an implementation of a blockchain oracle. It has had some good exposure in the Ethereum community due to a plethora of quality features that it offers. Heck, even we at @EspeoBlockchain have used Oraclize in some of our past projects! One of these features is random number generation which is done off-chain, using a Ledger device. This device boasts a True RNG, which means that its randomness is generated using some truly-random physical phenomena rather than using an algorithm. Provable also provides Ledger proof shipped with the response which confirms that the device used for number generation was a genuine Ledger device. Such a solution introduces similar downsides to Ginar — it introduces multiple trusted parties (Ledger and producer of the chip that provides Ledger device with TRNG) as well as it costs money, though it seems to be cheaper than Ginar.
Gardener Approach
In order to implement Gardener’s random data source, we tried to combine the best of three worlds described above, before adding a little something from us. As a result, our solution is simple, secure, and provable. Oh yeah, and it’s free. And open-source.
The magic lies in using Intel SGX to securely generate a random number. SGX uses a specific part shipped with modern Intel processors called Enclave. We use an SGX Enclave to securely run the code by ensuring it’s immutable which is done on the hardware level and by rejecting any attempts of affecting it once it’s running, even by processes with root privileges. It also provides an attestation service which essentially proves that the enclave that was used to run the given code is indeed genuine Intel hardware. Since Intel attestation service is publicly available and deterministic, the only trusted party introduced in this process is Intel.
That’s for the architecture, but what about implementation? Well, it’s as simple as it gets. We produce our random numbers by calling a simple PRNG function within an SGX Enclave, seeded with a current CPU time. “But Kris, doesn’t that mean that whoever hosts that Gardener instance is also a trusted party? They could intercept seed and get nasty!” Well, not really! The only way to interact with Enclave is via an ECALL, which is essentially an interface call. After we’d call it, it would proceed to execute code that sits in Enclave. It means that even if we intercepted CPU time at the time of an ECALL it would be useless because a non-deterministic amount of time would elapse between that moment and an actual function call within an Enclave. Intercepting a seed at the time of actual random function execution is also impossible, since SGX does not allow such interaction by design as explained above.
Summary
Here, in Gardener, we like to keep things simple. I believe that our approach to random number generation confirms that. I must say that developing this solution was a fun and satisfying process. More of the same awaits, starting with employing Intel SGX to prove oracle calls! Remember, Gardener is open-source so new collaborators are more than welcome to join. If you’re a blockchain developer or an experienced dev with passion for blockchain and you’d like to work on an open-source blockchain oracle implementation, feel free to hit ekin.tuna@espeo.eu up!
This is just one in the series of Gardener technical articles. Check out the previous one!
