Exploring On-Chain Randomness with Move in Aptos (1) — Is an On-Chain Casino Possible?
Why is on-chain randomness necessary?
One of the most frequently mentioned features of blockchain is its immutability (or the extreme difficulty of tampering with it). PMs imagined building lotteries, casinos, and games on it that cannot be manipulated.
Compared to private betting, where the backend operations are unknown, the idea of products that people can trust and bet on is thrilling.
However, one essential characteristic for such ‘gambling’ to possess is ‘fair randomness’.
There have been various attempts to achieve fair randomness on-chain.
If a lottery vendor knew the winning numbers in advance, or a casino knew where the roulette would stop, gambling would lose its meaning. The essence of gambling lies in the unpredictability; not knowing the winning lottery numbers or where the roulette will stop is what keeps gamblers at the table.
Therefore, anyone wanting to create a blockchain-based casino has naturally been interested in implementing ‘on-chain randomness’.
For a fairer casino, and greater profits.
Fairness which was ‘Hybrid’
Randomness has been treated as a concept too challenging to implement entirely on-chain. Thus, various alternatives, not fully on-chain, have been introduced to the market.
For instance, a so-called ‘hybrid’ solution generates random numbers off-chain and then transmits them on-chain.
However, if the fairness of the off-chain numbers’ generation cannot be guaranteed, those numbers might already be manipulated by the off-chain provider. There are risks of interception during the transfer to the blockchain and attacks that upload false data on-chain.
The question arises: How can we ensure off-chain numbers haven’t been tampered with?
The answer is illustrated in the figure above.
Chainlink’s VRF (Verifiable Random Function) offers ‘verifiable randomness,’ ensuring the randomness created off-chain is not intercepted or manipulated by other players. Simply put, it allows the verification on-chain of whether lottery numbers are truly random.
Please refer to the diagram above for further explanations.
- The smart contract provides the oracle with a seed that only it knows (= unpredictable by the oracle). The oracle then uses its ‘secret key’ along with the seed to generate a random number.
- Next, the oracle sends this number to the on-chain ‘VRF contract’.
- The VRF contract receives the smart contract’s seed and the oracle’s secret key, verifying that the random number was indeed generated using the correct seed and secret key.
- Once the randomness is verified, it is passed back to the smart contract.
Through this, smart contracts can naturally utilize oracles (like Chainlink) to generate ‘verifiable randomness’.
Imagine a lottery where the company handling the balls and machine, and the host drawing the balls, are separate entities, preventing unilateral outcome manipulation.
This lottery case could be compared to this structure.
Chainlink’s VRF includes features to penalize oracle nodes that either do not input randomness correctly or fail to respond to randomness requests.
This ensures that most applications today use a ‘hybrid’ VRF that bridges on-chain and off-chain elements to guarantee randomness.
However, returning to the example of the lottery.
What if, (although unlikely,) the host had the skill of an eagle-eyed martial artist, selecting only the desired balls?
Or what if the host didn’t show up, preventing the lottery numbers from being drawn on time?
Such scenarios highlight vulnerabilities in Chainlink’s VRF approach due to the reliance on off-chain to on-chain information transfer.
There remains the possibility of oracle nodes manipulating outcomes, tampering with information during transfer, or ‘corrupted nodes’ failing to respond to randomness requests, leading to various potential issues.
There have been unusual scams around the world. One such scam involved a group in the United States that collected fees to purchase lottery tickets on behalf of clients but never actually bought the tickets. Instead, they used other clients’ money to pay out lower-tier winnings, such as 3rd, 4th, and 5th prizes, to their customers. It’s reported that this lottery scam amassed about 43.1 billion won.
AIP-41: The First On-Chain Randomness for PoS Blockchains
In November 2023, Aptos’ development head, David Wolinsky, visited Korea and stated:
“Aptos plans to add on-chain randomness features. On-chain randomness is a technology that provides verifiable random numbers on the blockchain. For instance, if a game randomly selects users to give NFT rewards, the selection criteria must be fair to increase trustworthiness. On-chain randomness is necessary to ensure that no one can predict the outcome in advance.”
And he also mentioned:
“By early 2024, we will become the first major blockchain to actually have on-chain randomness, offering a web2 development environment-like experience.”
Indeed, as Head Wolinsky mentioned, Aptos is planning to be the first PoS blockchain to directly implement on-chain randomness.
Aptos has been emphasizing games, social, content, and DeFi in its ecosystem, all of which are deeply related to the topic of ‘on-chain randomness’ discussed in this article.
In fact, recent posts from Aptos Labs have listed several functionalities such as decentralized games, lotteries, random NFTs, and random airdrops as features that will benefit from Aptos’s on-chain randomness.
Move Randomness API Interface.
Starting with the AIP-41 proposal and extending to the recently added Move API interface, Aptos Labs and the Foundation have been working to provide developers with solutions more convenient than relying on ‘external randomness beacons’.
Although Aptos has utilized external beacons like Chainlink before, AIP-41 initially proposed a ‘randomness’ Move module to verify ‘external randomness’ within Aptos. This approach aimed at providing an API for this purpose, with drand as an example of an external randomness beacon used to create a raffle shared among the community.
However, this approach has three major inconveniences: it’s difficult for users to understand, the process of generating randomness is too costly and slow, and it requires transactions to be sent to contracts.
Therefore, AIP-41 proposes a new method.
Suite functions (for integers, bytes, shuffles, etc)
- randomness::u64_integer() uniformly samples a 64-bit unsigned integer
- randomness::bytes(n) uniformly samples a vector of n bytes.
- randomness::permutation(n) returns a random shuffle of the vector [0, 1, 2, …, n-1].
randomness module (source: AIP-41)This section explains how randomness is generated and called, indicating that more randomness functions could be added in the future. The example code provided is a snippet from a raffle application, highlighting the part where the winner is determined and the prize money is paid out.
This demonstrates a practical use of the proposed module in a real-world scenario, showcasing the application of on-chain randomness to make decentralized applications more dynamic and fair.
After sufficient time has passed and at least one person has participated in the raffle, the process involves randomly selecting a winner and depositing coins into the winner’s account.
This flow ensures a fair and transparent selection process for awarding the prize.
Aptos Roll — Chain rolls the dice for you
Aptos has introduced an on-chain randomness API and cryptographic implementation named “Aptos Roll.” It’s simple to use; when on-chain randomness is needed, the following functions can be called:
- aptos_framework::randomness::u64_integer()` for when a random number is required in Move.
- aptos_framework::randomness::bytes()` for when random bytes are needed.
Aptos Roll, as mentioned, does not rely on external oracles (beacons) but utilizes the security and availability of Aptos validators, which is considered its best feature. Utilizing Aptos Roll for on-chain randomness has particular advantages in terms of next two things.
- Using the instant API, Aptos Roll makes the randomness generation process faster and cheaper than the traditional method, which involves two separate transactions for committing and utilizing randomness.
- Additionally, it ensures security by leveraging PoS validators, making it as secure as the mainnet itself without the need for external entities.
This raises a curiosity:
How did Aptos achieve on-chain randomness, something other chains have struggled with?
Aptos Casino is Coming
The answer lies in three key concepts: wPVSS (Weighted Publicly Verifiable Secret Sharing), wDKG (Weighted Distributed Key Generation), and wVRF (Weighted Verifiable Random Function), which will be explained in a follow-up article.
Aptos is paving the way for on-chain casinos, offering a secure and efficient method for generating on-chain randomness, crucial for fair and transparent gaming experiences.
The title deliberately chose to question the feasibility of on-chain casinos because,
even now, many companies in the blockchain ecosystem claim to offer cryptocurrency-based play and tamper-proof outcomes through blockchain.
However, this article reveals that the off-chain backends or ‘hybrid’ VRF solutions utilized by these companies might not provide as fair randomness as thought.
They potentially carry the risk of manipulation, biased outcomes favorable to one party, and the possibility of third-party interference or data theft.
To truly create an on-chain casino, it’s not enough to just implement on-chain randomness.
The chain used must offer faster speeds, lower usage fees, and easy integration with various dApps to enable a broader range of services should be provided.
Aptos Roll with Move exemplifies these features, making it an ideal API set for enabling on-chain casinos. With on-chain randomness, innovative and entertaining use cases in gaming, gambling, and content are expected to emerge — maybe even beyond our imagination.
Author : Minik
Reviewer : Ryan
