Introduction
Generating a pseudorandom number from the blockchain as an entropic source is a formidable task, especially when the miners influence the block gas limit, block-hash and block time, this may change as the network adheres to Proof of Stake (Casper POS, Serenity). It depicts a stern complication for programmers who endure establishing a trust-less internal deterministic source of entropy for Ethereum blockchain, whose essence inclines to be transparent.
The complication
Since the blockchain is conspicuous, EVM bytecode on the blockchain is evident to all the existing nodes for verification. Nevertheless, reverse-engineering (decompile) bytecode back to perfect original source code in a stack-based architecture is computationally impossible due to name omission of variables, functions and types; particularly if the smart contract is optimised, obfuscated and self-modifying, the decompiler may generate pseudo-code but this is far from the original. This settles one issue and generates another as there is a perception of reluctance and lack of confidence to interact with a closed source smart contract.
The solution
The block variables in their raw form are susceptible to influence or effortless prediction (In POW or Future Casper POS) by various parties. The solution to this problem is extensively mixed hashing (keccak256) of the contributing factors to the point that influencing block variables and predictions prove ineffective on the final hash output.
The problem here is after all the mixed hashing the creator of such smart contract (Niguez Randomity Engine) will identify what the outcomes of certain blocks are and hence may use this to their advantage. Therefore, no entity will use such a facility as it is imperative and necessary to provide a degree of freedom and customisations to the random number end users.
The pseudorandom numbers generated are 24 sequences of unsigned integers of 256 bits. The end user could use any sequence, cross sequence, allocate a slot in a sequence and re-hash it. Thus, the smart contract creator has no influence due to the fact that the contract is immutable. Accordingly, the smart contract creator is incapacitated to comprehend and influence the sequences or slots of the random number a user picked. Consequently, a user can only have control over the customised sequence they generate but not the outcome of the random number, avoiding prediction of numbers all through.
What is Niguez Randomity Engine?
Niguez Randomity Engine is a smart contract deployed on the Ethereum and ThunderCore blockchain that functions on the foretold protocol. It is immutable, providing impulsive sequences of pseudorandom number with every block.
In the scenario of influenced blockchain variables, Niguez Randomity Engine makes them redundant due to its very essence. It is an immutable smart contract and cannot predict and dictate the slots determined by the user. It serves as an escrow for random numbers.
In conventional pseudorandom number, the pattern tends to repeat, that is not the instance with this randomity engine as it uses a cryptographic hash function. Hence, every sequence is non-repeating and unique; if the sequences repeat, that would be considered an instance of a hash collision.
The engine still renders the sequence of random numbers even if the block variables are unpublished. Utilities, the likes of ‘web3.eth.getStorageAt()’ are redundant because nothing is stored in the storage and the contract dependencies are self-modifying.
The pseudorandom sequences generated are named alphabetically from ‘Ra’ to ‘Rx’, that is 1 to 24 respectively. The illustration below elucidates the mechanism of this randomity engine.
Block variables are hashed, rehashed and mixed to generate 24 sequences of (256bits) unsigned integer.
Sequences (7 slots) in action for every new block.
Usage
The pseudorandom sequences generated can be used with infinite possibilities, a simple example is demonstrated here. For the purpose of brevity, the use case has been limited here to nine mixed sequences of nine slots each.
Allocating slots for various pseudo-random sequences.
This is purely an instance of how to set customised slots for sequences. If the classification is static then the numbers will be picked from the identical slots perpetually, hence it is advised to use dynamic slots by the user to be assured that the randomity engine creator is debilitated to predict the slots beforehand.
Niguez Randomity Engine is FREE to use by any entity for personal or commercial purpose and to explore the boundaries of the system. However certain state modifying transactions will consume gas.
Niguez Randomity Engine contract addresses
Guide to generate random numbers using the Niguez Randomity Engine
Import API into your project | Use the following code:
pragma solidity ^0.5.0;
/**For Ethereum*/
import
"https://github.com/niguezrandomityengine/ethereumAPI/nreAPI.sol";
/**For ThunderCore*/
import "https://github.com/niguezrandomityengine/thundercoreAPI/nreAPI.sol";
Create a Smart Contract as follow (Ethereum):
pragma solidity ^0.5.0;
import "https://github.com/niguezrandomityengine/ethereumAPI/nreAPI.sol";
contract Randomness is usingNRE {
}
Code function to use sequences and set slots, there are 24 sequences i.e., ra(), rb(), rc() up to rx():
Example 1: Using the explicit sequence to get a 10 digits random number.
pragma solidity ^0.5.0;
import "https://github.com/niguezrandomityengine/ethereumAPI/nreAPI.sol";
contract Randomness is usingNRE {
function randomNumber() public view returns (uint256){
return (ra()%(10**10));
}
}
Example 2: Using multiple sequences to generate 3 digits random number ranging from 0 to 999. This type of random number generation can be used to randomly select validators in a Proof of Stake (PoS) network.
pragma solidity ^0.5.0;
import "https://github.com/niguezrandomityengine/ethereumAPI/nreAPI.sol";
contract Randomness is usingNRE {
function randomNumber() public view returns (uint256){
return (((rf()%10)*100)+((rx()%10)*10)+(rm()%10));
}
}
Example 3: Transaction of random numbers into state or local variable. The below transaction will consume gas, approximately (40k — 120k) gas per sequence.
pragma solidity ^0.5.0;
import import "https://github.com/niguezrandomityengine/ethereumAPI/nreAPI.sol";
contract Randomness is usingNRE {
uint256 public randomNumber;
event rNum(uint256 theNumber);
/**State Variable. */
function stateRandomNumber() public {
randomNumber = (((ru()%10)*100)+((re()%10)*10)+(rq()%10));
}
/**Local Variable. */
function localRandomNumber() public {
uint256 randomGame = (((rj()%10)*100)+((rg()%10)*10)+(ri()%10));
emit rNum(randomGame);
}
}
Example 4: Using the slot of numbers from between the sequence and hashing it for distinct random sequence
pragma solidity ^0.5.0;
import "https://github.com/niguezrandomityengine/ethereumAPI/nreAPI.sol";
contract Randomness is usingNRE {
function randomNumber() public view returns (uint256){
return (uint256(keccak256((rw()/(10**20))%(10**12))));
}
}
These are merely 4 instances of generating a pseudo-random number, the user could use this numbers in infinite possibilities by using dynamic slot selections, cross stitching sequences and using them as a salt to hash with user’s address or nonce.
Thank you for reading. Enjoyed it? Please Share it.
Links