The random datasource — chapter 2
During the last few days we released two brand new Oraclize features: the Ledger proof and the random datasource.
The former is a new type of authenticity proof backed by the Ledger TEE, specifically it leverages the hardware attestation provided by BOLOS. The Ledger proof proves that a data has not been tampered with while being delivered to a smart contract, when the origin is a given Ledger application.
The latter is the first Oraclize datasource compatible with the Ledger proof. The random datasource is an architecture that enables smart contracts to receive a random number from a trusted, impartial source, without having to trust whatsoever on the data carrier. The way this datasource is designed (described in our paper “A Scalable Architecture for On-Demand, Untrusted Delivery of Entropy”) prevents Oraclize from tampering with the random number results coming from the Trusted Execution Envirnment (TEE) and protects the user from a number of attack vectors.
How it works
The random datasource is fully working and integrated with Ethereum — it can be tested today on all public testnets (Rinkeby, Kovan and Ropsten-revival). The integration with the mainnet will be available in the coming weeks!
What we are releasing today is an example code showing how the random datasource can be used within your Solidity smart contract and how the on-chain proof verification works.
The key feature included in this example code is the Solidity modifier “oraclize_randomDS_proofVerify” — which enables the onchain proof verification and prevents results which are not backed by a valid proof from executing your callback code. Given that the random datasource is backed by the Ledger proof, the authenticity of the result delivered by Oraclize can be verified on the EVM (Ethereum Virtual Machine), in addition to the off-chain verification.
As a consequence, smart contracts can verify the validity of the authenticity proof — hence the correct secure origin of the random number — before the data-dependent execution takes place.
This example code is showing how to integrate the verification process, in order for your smart contract to be able to discards any random number result whose authenticity proof doesn’t pass the verification process.
An important element of the verification process is the CODEHASH (i.e. SHA256 of the application’s binary), which is hardcoded in the smart contract. This can be used by anybody to ensure that the application code (to be released next week, as it is being polished to increase its readability) is really the one being executed to generate the randomness.
The code we have released today is meant to be a starting point to help developers leverage the potential of our — now fully functional — random datasource. The Ledger-backed one is just the first implementation of the design presented in the paper, which will be extended in the coming months to use a diverse set of Trusted Computing technologies, thereby lowering the trust involved and making this approach even more secure.
Enjoy!
Note: The company has now rebranded into Provable.
