WitnetRandomnesscontract internally uses an instance of the low-level
WitnetRequestRandomnessformarly explained, this contract implements also the whole request/resolution asynchronous flow involved in the resolution of a data request in the context of the Witnet side-chain.
Moreover, the same instance can be safely and concurrently used by any number of indepent applications running within the same EVM-chain.
Because of this, you may even have the chance to reuse randomness previously requested by others, at no cost (🎉), while having the certainty that the acquired randmoness was independently generated by the Witnet side-chain strictly after any given block number.
And therefore, depending on the time-response constraints of your own app, the Witnet Randomness Oracle may become the cheapest EVM-agnostic mechanism to generate reliable randomness in the whole crypto arena (💣).
In a nutshell, by using a
WitnetRandomnessyou just need to:
- 1.Eventually, care for requesting and paying for new randomness at any given time: see
- 2.Eventually, fetching a randomness value generated by Witnet after any given block number: see
As simple as that ;-)
WitnetRandomnesscontract is not owned, so anyone is actually allowed to either request new randomness (i.e.
randomize()), or get previously solved randomness from storage (i.e.
- Besides, you or your contract will be able to request for new randomness (i.e.
randomize() payable), even if other previous randomness requests (either coming from you, or other apps) were still pending to be solved.
Clonable, which means that you, or your contract, may cheaply create your own cloned copy as a means to gain ownership of the self-contained
WitnetRequestRandomnesscontract. Only the owner of a cloned copy will be allowed to change the witnessing parameters of the low-level Randomness Request.
WitnetRandomnesscontract provides the
random(uint32 _range, uint256 _nonce, uint256 _block)and
random(uint32 _range, uint256 _nonce, bytes32 _seed)helper functions.
random(..)functions guarantee that different contracts/apps reading from same randomness request will actually get completely different random sequences of uniformly distributed numbers, within a given range, and doing so while keeping complexity under O(1) (🎉).
- Most of all, the
WitnetRandomnesscontract guarantees that the received randomness is the one requested for a given block number, or the subsequent randomness request posted after the given block if there was none posted back then, or if the ones posted after that got reverted for whatever reason at the Witnet side-chain level.
This logic alone protects the Witnet Randomness Oracle against front-running attacks from mallicious miners at the EVM-chain level (💣).
Once you call on
randomize() payable, you should not allow any change in your smart contract state that alters the outcome of whatever the requested randomness is planned to be used for.
Just call on the
isRandomized(uint256)method, passing the block number at which the
randomize() payablecall got mined, as to check for readiness of the requested randomness.
WitnetRandomnesscontract is not owned, the self-contained
WitnetRequestRandomnessinstance it is (i.e.
witnetRandomnessRequest()). This enables the operator of a
WitnetRandomnessinstance to eventually update the witnessing parameters of the underlying low-level Randomenss Request that gets posted to the Witnet side-chain.
The witnessing parameters part of the self-contained
WitnetRequestRandomnessinstance may eventually turn immutable at the time the
WitnetRandomnessoperator decides to renounce its ownership.
This back door of letting the
WitnetRandomnessoperator modify the underlying witnessing parameters of the randomness request, is left open as to provide a means for adapting to eventual high-load situations within the Witnet oracle's side-chain.