WitnetRandomness Contract

The WitnetRandomness contract, also known as the «Witnet Randomness Oracle», is the easiest and most convenient way to generate EVM-agnostic and realiable randomness for your smart contracts.

The Witnet Foundation sponsors a pre-deployed instance of WitnetRandomness in practically all the EVM-compatible chains supported by the Witnet oracle.

While the WitnetRandomness contract internally uses an instance of the low-level WitnetRequestRandomness formarly 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 WitnetRandomness you just need to:

1. Eventually, care for requesting and paying for new randomness at any given time: see randomize() payable.

2. Eventually, fetching a randomness value generated by Witnet after any given block number: see isRandomized(uint256) and getRandomnessAfter(uint256).

As simple as that ;-)

API Reference

Best practices

• The WitnetRandomness contract 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. isRandomized(uint _blockNumber), getRandomnessAfter(uint _blockNumber)).

• 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.

• The WitnetRandomnesscontract is 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 WitnetRequestRandomness contract. Only the owner of a cloned copy will be allowed to change the witnessing parameters of the low-level Randomness Request.

• The WitnetRandomnesscontract provides the random(uint32 _range, uint256 _nonce, uint256 _block) and random(uint32 _range, uint256 _nonce, bytes32 _seed) helper functions.

These 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 WitnetRandomness contract 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 (💣).

Security concerns

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() payable call got mined, as to check for readiness of the requested randomness.

While the WitnetRandomness contract is not owned, the self-contained WitnetRequestRandomness instance it is (i.e. witnetRandomnessRequest()). This enables the operator of aWitnetRandomness instance to eventually update the witnessing parameters of the underlying low-level Randomenss Request that gets posted to the Witnet side-chain.

The RAD bytecode of the self-contained WitnetRequestRandomness instance (accesible via the template() method), will foerever remain immutable, though.

The witnessing parameters part of the self-containedWitnetRequestRandomness instance may eventually turn immutable at the time the WitnetRandomness operator decides to renounce its ownership.

This back door of letting the WitnetRandomness operator 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.