Blockchain Entropy
The Difficulty and Use of Private Randomness in a Public Ledger
When Satoshi Nakamoto invented the blockchain, he imagined it as a consensus mechanism for Bitcoin transactions. While it functions incredibly well in this endeavor, the underlying system can be used for so much more. Far from the hype and speculation of early crypto days, web3 will usher in technological improvements that are actually useful and applicable to the average person.
People will not only own their own data, but also control the backend processes that determine their experience. Namely, users will themselves become random number generators (RNGs), resulting in their privacy, higher security, and the ability to trust the system and not a centralized third party.
Source: Live Science
What is Randomness?
There are several classes and definitions of randomness. The first, pseudorandomness, should exclusively be used in single party ecosystems where security requirements are low. If you’re programming a game on your computer and need a random seed to determine an enemy’s direction, this is what your computer will produce. Because a computer is a deterministic machine, “randomness” means selecting the next seed in a set that was inputted by the developers at inception.
The next degree is chaotic randomness, deriving from entropy. This can mean anything from the shuffling of cards with deck cutting, to name a physical example, to utilizing the tenth decimal of the temperature at Mt. Everest in a lottery. While not actually random in the truest sense of the word — as one could theoretically predict these events if they had all the knowledge in the system…if they were God — for most practical purposes, chaotic randomness is sufficient.
The final level of randomness is quantum. As far as we know, it’s truly random — yet cost and negligible security improvements make quantum unnecessary and not useful.
Verifiable and non-exploitable randomness should be thought of as being binary: it’s either trustless or it isn’t. One can predict the sets and event seeds in pseudorandomness but cannot in chaotic or quantum randomness.
Source: SciTech Daily
Randomness for What?
The need for randomness is classically undervalued. RNGs are necessary in everything from gaming to gambling to security applications. Trying to catch a Pokemon or open a loot crate? You need randomness. Want to play poker or roulette? You need randomness. In cryptography, you even need randomness to generate secure passwords and encryptions. There are crypto-specific applications too, like NFT generators and mixers as well as verifiably random airdrops.
In fact, RNGs are crucial as entire environments would become nonfunctional and monotonous even if only a small portion of the protocol relies on randomness. Say there exists a golf simulator where a player inputs power and direction to hit the ball. Without an element of randomness, the gameplay yields only one unique playable experience. With a verifiable source of randomness, tournaments can be held with different terrains and wind movements and the knowledge that the system cannot be exploited.
Source: Taming Gaming
Why Hashes and Oracles Suck
So how does one create non-exploitable and verifiable randomness in a blockchain? The first thought is this vein often leads to the hash.
In Proof of Work, the block hash is the 256 bit computation result that encodes the previous blocks. Because users solve this puzzle every few minutes and the hash is seemingly arbitrary, one could argue that the hash itself could be a source of randomness. And while it is true that the hash succeeds in some aspects, it fails in perhaps the most crucial way: it’s exploitable.
A solution will only hold until the amount to be gained in its destruction exceeds the cost to break it. A game that used hash-derived randomness for loot crates would function until the reward for those crates exceeded that of the block reward, placing a ceiling on the security of the system. This is even worse in gambling where bets can be multiplied and leveraged. If ever a miner in the network was also a bettor, they could simply choose to not submit a hash that would result in landing on red, had they bet on black.
Another solution entails deriving chaotic randomness from external sources, or oracles. A group of validators will read data from some source, maybe it’s the latest score in a football game or the chance of precipitation in New York, and transmit the data to the system. Because these events are unpredictable and uncorrelated with the game play, they substitute as a source of randomness.
Source: Binance
Explaining fully why oracles are insufficient as a non-exploitable seed of randomness is beyond the scope of this article, but let us briefly examine three reasons why this is the case.
The first is that the solution is not decentralized. Because validators rely on an outside source, the entire environment becomes beholden to it. If the website goes down, charges higher prices, or changes their API, the blockchain is out of luck. Additionally, users must trust that the oracle is providing accurate data and is not being exploited or tampered with itself. No one has an incentive to hack a weather app until that app becomes the RNG seed for multi-million dollar bets.
The second reason why oracles suck as RNGs in blockchain is cost. Decentralization sacrifices efficiency for delegation. One central party can perform actions quicker and in a more cost effective manner than hundreds of users who must all “okay” an action. We accept this because decentralization eliminates corruption and encourages collaboration. However, combining a decentralized system with a centralized oracle forms a choke point of data that is extremely expensive to validate. For reference, Chainlink’s VRF averages $4 per seed. Imagine playing 60 games of poker per hour and getting charged $240, before rakes and losses. It’s untenable.
The final reason why oracles are not web3’s solution to randomness involves trust and security. While an oracle does provide readable data, there is no guarantee that the data will be accurately provided. If the oracle informs the validators that a certain event provided a seed of 23C93A, a majority of the validators can agree to publish the seed as 35E999. Essentially, an oracle is just a suggestion that should streamline validators’ opinions on what the seed should be. Yet this solution relies on the assumption that validators will not have a greater incentive to alter the data for their own benefit, which we discussed is untrue as leveraged bets quickly outpace fixed gas fees. Oracles are also not mathematically secure and are more exposed for DDOS attacks from outside pirates. Without going on further, it is safe to say that oracles are flawed and exploitable.
Source: The Back Room
The Back Room
The Back Room is the first web3 solution to true random number generation, solving privacy, verifiability, and trustlessness.
The Back Room, known as the world’s first decentralized casino, aims to democratize gambling with three promises: You Deal the Cards, You Own the Table, and You Always Win.
Starting with You Deal the Cards, The Back Room utilizes two revolutionary mechanisms to ensure that privacy is maintained while results remain cheap, verifiably random, and non-exploitable.
Dynamic User Entropy
The first of these innovations is Dynamic User Entropy, or DUE. With DUE, the players themselves generate the randomness. This means the process can be thought of as placing 52 cards on a table with all players sliding and mashing them around until all are satisfied that they are mixed up enough. There is no third-party dealer needed.
Source: The Back Room
To put these models into words, DUE incorporates distributed key generation to ensure “face down” cards can’t be decrypted by a single player: privacy; homomorphic encryption so that new cards can be checked against the existing deck: verifiability; and Merkle Trees so that players can reach consensus ensuring trustlessness. A more in depth description can be reached here.
Proof of Result
Proof of Result, or PoR, is the second innovative disruption in the web3 space. Simply, Proof of Result allows games and events to occur off-chain, recording only the end state. Imagine you see a game of chess with just a black queen and rook placing the white king in checkmate. You cannot be sure what moves occurred in the game, but you can compare each players’ identical Merkle Trees to verify that the entire game is legitimate. This is what Proof of Result accomplishes. By offloading the game of poker to the players, control over the game is delegated (You Deal the Cards) while validation costs are vastly lowered, bringing computing costs of each hand to near 0.
Conclusion
The Back Room is the first DAO to bring verifiable and non-exploitable randomness to web3 through its Dynamic User Entropy and Proof of Result technologies. The DAO offers even more, however, not only eliminating rakes and fees, but promising a reverse rake. This means that players enjoy a positive-sum game where the odds are forever in their favor. This is because the house always wins and the players own the DAO.
The Back Room has more exciting features which can be found at https://backroomdao.com.
Note: Nothing in this article is to be considered financial advice, there is no such thing as a “risk-free” investment.
Sources
