To invoke chaos...

Blockchains are deterministic and that's great. Given all the available inputs and knowing the state of the blockchain at the relevant point in time you will always know the outcome. It's awesome.

Except when you don't want to know the outcome.

The Desert of the Random

There are times when you want random, or at least as close to random as you can get. Obvious examples are games of chance, where the outcome of an action has to be suitably unpredictable. This presents a problem for a 100% deterministic system. Especially when you consider that there isn't widespread consensus that random truly exists anywhere...

The accepted position is that for random you need to hop off the blockchain. Head out into the wild chaos of meat world and get back something that no one on chain could have predicated. For example chainlink RNG.

That is the gold-standard, and nothing I say here will change that. BUT, there are problems. Heading off-chain introduces external dependencies that could fail, or indeed themselves could be manipulated. So what's the solution?

On-chain pRNG

If we look for entropy on-chain the most simplistic approach is to take some state variable (like block.timestamp), hash that and call it random. This doesn't really work of course, as block.timestamp can be controlled, and if the incentive is large enough our random number very quickly gets not random at all.

In this sense we aren't really looking for true random, but a source of entropy that cannot be controlled by a single entity. Or at least is extremely difficult for a single entity to control.

Unpredictability is the key

Which lead me to focus on unpredictability when developing IceRing, which is (as far as I know) the most advanced on-chain pRNG solution out there. IceRing's innovation is to look for more entropy - more chaos - on the blockchain.  

IceRing contains a list of contract addresses that have a very very fluid ETH balance. Think gateways and wrapped eth. Within every block the ETH balance of these contracts changes a number of times.

IceRing rotates through this list and uses the ETH balance of these contracts to seed a hash, combined with the more traditional block.timestamp altered by a modulo using an incrementing modulus.

In theory, to control the outcome of this pRNG an entity would need to be able to control the block.timestamp, the balance of a contract receiving many new transactions per block, the next balance to be checked from IceRing's list of addresses, and the current modulus. The expectation is that this would be so prohibitively expensive, and logistically difficult, as to be represent a low risk for anything other than a high-value outcome. A billion dollar lottery draw? Yeah, maybe this isn't the right answer. But if you want to randomly allocated tokenIds in a mint, then IceRing could well be what you are looking for (more on that in a later post).

Where can I see IceRing?

You can head to my github: https://github.com/omnus/omnus-contracts/tree/main/contracts/entropy

The live contract is here: https://etherscan.io/address/0x7257B57cc14A749B75e1F073c15132F7Ac893E57

There are Ice deployments on Ropsten, Rinkeby, Kovan and Goerli at the same address. If you need an implementation on another chain drop me a line on twitter.