Enhancing Blockchain Randomness To Eliminate Trust Issues Once For All

Blockchains lack true randomness, hindering applications like fair games, DeFi, and NFTs. Pyth Network’s “Pyth Entropy” solves this with provably fair, trustless random number generation. It’s fast, cost-effective, and easy to integrate

Blockchain developers have come up against a significant challenge when it comes to creating smart contracts that can execute randomness in a provably fair manner. Because most blockchain networks are limited to deterministic inputs and outputs, randomness is all but impossible to implement using standard architectures.

Various solutions have been proposed to implement genuine randomness in blockchain applications, including the use of trusted third parties, blockhashes and Verifiable Random Functions or VRF, but none of these solutions are perfect.

****Why Do Blockchains Need Randomness?****

Randomness is essential for many different kinds of blockchain applications. For instance, many blockchain-based games are built around the concept of randomness, such as the outcome of a fight between two players, which object the player discovers and so on. Randomness is also required to ensure fair NFT airdrops and mints, the allocation of tasks and resources and choosing samples for a consensus mechanism. Many dApps also have lottery-style mechanics that must be provably fair.

Without randomness, none of the above applications can be demonstrated to be fair, as it’s easy for those with blockchain know-how to predict outcomes to their advantage. This is a big problem because the future of decentralized applications must be built on a foundation of trust and transparency. Participants in DeFi markets and blockchain games must be reassured that outcomes are fair and randomly selected, based on inputs. Betting protocols such as Lunabets, IDO auctions and random NFT lotteries must also be provably fair.

We can illustrate the need for randomness in a blockchain-based poker game. The developer of the poker app must be able to prove to its players that the game uses a fair and unbiased algorithm. For instance, every time the deck of cards is shuffled and the players’ hands are dealt, players need to know that no one can manipulate the outcome. If it’s possible for any stakeholder to predict which cards are drawn, no one will trust the game.

Developers could implement their own, black box algorithm like many traditional online poker games have done, but these obscure the inner workings of players. As such, the developer has no way to prove that the outcomes are random. Given the priority the Web3 industry places on trust, that simply won’t do for most users.

However, implementing randomness is a challenge. To do so, the random outputs must be unbiased, unpredictable, verifiable and instantly available. The deterministic nature of most blockchains makes it difficult to fulfil these criteria, and so alternative solutions have been proposed.

****Different Approaches To Randomness In Blockchain********– Trusted Third-Parties****

The simplest solution is to use a service provider to generate randomness. When the dApp user requests a random number, it’s generated by an off-chain provider that posts the results onto the blockchain. It’s an extremely easy-to-implement solution, but the problem is that everything is based on trust.

Participants need to trust that the randomness service provider is acting honestly. But there’s no guarantee of this, which makes it unsuitable for decentralized applications, especially those that involve high stakes, such as crypto games, betting applications and highly-prized NFT airdrops.

****– Blockhashes****

An alternative method is to generate random numbers with the blockhash of a future block. When the user submits a request for a random number, it saves the or future block number. When the hash for that block is computed by network validators, the reveal transaction generates a random number.

Once again it’s a simple solution, but trust is still a sore point, as users must trust the honesty of the validator. However, validators can reorder or omit transactions, which opens the door to the possibility of collusion between one participant and the validator to ensure that a favourable random number is generated.

****– Verifiable Random Functions****

To ensure that single entities cannot influence the outcome of random number generation, verifiable random functions or VRFs have emerged as a popular solution. It’s a novel technique that relies on the collaboration of multiple participants to create a random number.

A simple illustration of how VRFs work is this: f_s(x) = (y,p), with the random output “y” being deterministically computed from the input “x” and the secret key “s”. The function returns a “p”, which is proof that enables anyone to check that the “y” output is accurate.

Typically, whenever randomness is requested, the input “x” is partially provided by the user and partially by the current blockhash. An off-chain service provider that holds the secret key “s” watches the blockchain for such requests, and submits on-chain responses “y,p”. The reveal transaction checks the proof “p” to ensure the “y” value is correct, before delivering the random output.

While VRFs mitigate the need for trust, they also require the collaboration of the user, validator and service provider to generate the random number. However, there are concerns with this approach, as the service provider must be trusted not to censor any transactions. With VRFs, the service provider can simply choose not to submit it to the blockchain.

This opens the door to collusion, where the user submits a request for a coin flip, but collaborates with the service provider to only submit the request if the outcome is favorable. Developers can mitigate such attacks to an extent by ensuring the user cannot benefit from a failure to reveal.

However, a second problem with VRFs is that the cryptography involved is quite complex and computationally intensive. Because blockchains generally don’t implement the necessary primitives for this cryptography, such requests can require excessive gas fees and multiple transactions to complete.

****A Superior Solution****

The decentralized oracle protocol Pyth Network has emerged as one of the most widely-used crypto oracles, providing high-quality financial market data to blockchains at low latencies and with greater regularity than other protocols.

Pyth has recently improved on an alternative approach to randomness generation called “commit-reveal” which involves the collaboration of untrusted parties.

With commit-reveal, both the user and the service provider generate a secret random number and submit its hash, called a “commitment” to the blockchain. Then, in the reveal phase, both the user and service provider reveal their random numbers. Each party checks the revealed number generated by the other, with the random number generated being the hash of those two random numbers. It’s also possible for the blockhash to be included to add further randomness into the mix.

It’s a novel idea that improves on the trust assumptions of VRF and it uses simpler cryptography, because only the hash function is required, making it easy for developers to implement. The same “liveness” problem remains, as both the user and the service provider can still halt the protocol by not revealing their random number, but developers can mitigate this in the same way as they would with VRF.

The downside of commit-reveal is that it requires more than two transactions, meaning higher gas fees. This is because the participants must first send their commitment, and then process the reveal phase, with the final random number being revealed in the third step.

Pyth Entropy resolves this drawback with a more sophisticated version of commit-reveal, where the service provider can commit multiple numbers upfront, reducing the number of transactions involved in the process. In this way, it enables secure random numbers to be generated more rapidly, with minimal transactions, making it the ideal solution for dApps that rely on speed, such as NFT games, airdrops and mints, lotteries and more.

****Randomness Everyone Can Trust****

Pyth Entropy has gained significant adoption since its launch last year and is now available on multiple EVM blockchains and Layer-2s, including LightLink, Chiliz, Arbitrum, Optimism, Mode, Zetachain and, more recently, Blast.

Blast is a new Ethereum L2 and the first to offer native yield for ETH and stablecoins while powering faster and cheaper transactions. It leverages the capabilities of Ethereum’s Shanghai upgrade, which introduced features such as auto-rebasing for ETH and T-Bill yields for stablecoins via Blast USD (USDB).

Blast’s integration with Pyth’s data oracles means dApps built on the network can access more than 400 low-latency price feeds for cryptocurrencies, foreign exchange pairs commodities and equities of exchange-traded funds. Already, Pyth has been adopted by dozens of Blast dApps.

With Pyth Entropy, Blast dApps now have a way to quickly generate secure random numbers with zero trust issues at the lowest cost, ensuring they can rapidly deliver unbiased outcomes for users. Its applications extend to NFT mints and airdrops, blockchain games, SocialFi, prediction markets and more. Combined with the advantages of the Blast network, it will enable new experiences that aren’t possible on any other blockchain, eliminating trust issues once and for all.

1. Could Bitcoin Be The Future Of DeFi?
2. The Rise of Blockchain Gaming and Secure Marketplaces
3. 5 Ways Smart Contracts Are Making A Real-World Difference
4. Exploring the Phenomenal Rise of Ethereum as a Digital Asset
5. Web3 needs decentralized infrastructure beyond IPFS capabilities