# Entropy - A case for on-chain randomness

Entropy is an intellectual exercise, a smart contract (hashelot_entropy_v.1.0.sol) in which you will find the callable (i.e. you don’t need gas to use it) method randomics() that returns a value in

$$[0,2^{256}-1],$$

mimicking a random generator1.

Transaction hash: 0x80d370b146…2f978ae329.

The way another contract might use randomics() is then up to the developer. As an example, the following button generates and displays a value in

$$[0,1]$$

by an off-chain evaluation of

$$\frac{ randomics().call()}{2^{256}-1}.$$

Playing around and coding with Solidity forces developers to adapt their way of thinking, especially if they come from more traditional languages.

The initial hype many feel when learning for the first time about distributed ledger technologies is then usually weakened by the hard truth that blockchains are often oversold as a universal remedy to unfairness in the financial system, that is unless a maximalist stance is held despite solid criticism, and by the fact that a harder to hack structure comes with the property of having harder to implement features.

The shift from centralized entities accountable to the law to decentralized designs solely run with economic incentives, in the case of a Proof of Work system, or by sharing authority among specific actors, for instance in the future Proof of Stake solution, shouldn’t be dismissed without a thorough analysis.

Unfortunately, fairness is still a human quality and we’re not quite there yet in terms of hardcoding it inside a protocol or a distributed consensus.

A task as simple as defining randomness inside the Ethereum blockchain while maintaining the property of decentralization, once again shows that something that might look decentralized, and therefore intuitively more secure, needs to be handled with care.

There’s a special set of variables (e.g. block.timestamp, block.number, block.coinbase, …) from which it appears possible to draw the inspiration for randomness, at least with a hint of freshness since those variables usually change from block to block, but that inspiration comes with a price. For instance, in the game Rings, the winner of a round is determined by a precise hash value, blockhash, but that variable is manipulable at a certain degree by a miner who might take the risk of discarding, i.e. not propagating it to the network, a mined block whose blockhash doesn’t comply to the miner’s interests.

A miner might be encouraged in doing so if a better chance in winning the Jackpot of a round could overcome the risk of losing the reward for creating a new block, and the answer to that dilemma depends on the hash power of the miner and the value of the Jackpot, but still, in theory, the game is not completely fair.

Regrettably, in the Ethereum network, the long awaited Proof of Stake implementation could even increase the advantage held by a miner in that regard.

In designing a game that would rely on randomness, the miners’ motive can’t be neglected, but for the fun of it and as long as the Jackpot doesn’t inflate to a notable amount, a blockhash can be sufficiently fair.

One possible solution for mitigating the influence by those who mine is to seed randomness in other values from the network, for instance the Ether balances of known wealthy addresses, tipically the ones that belong to exchanges which would hardly find interest in manipulating the outcome of a smart contract that easily has a fraction of their value.

A bigger number of parameters or a bigger number of actors whose actions might modify the outcome would streghten a decentralized smart contract. Entropy is a friend.

1. To be taken cum grano salis. ↩︎