Blockchain gaming optimized VRF
Introduction
Randomness is a crucial element in many online multiplayer games, especially when it comes to things like loot drops, matchmaking, and other important gameplay mechanics.
To achieve this randomness, many games rely on a cryptographic function called a Verifiable Random Function (VRF).
In this article, we’ll cover how Proof of Play has created a custom VRF, optimized for blockchain speed & cost (~500% faster & ~3x cheaper), and is currently being used in our first game, Pirate Nation.
Why VRFs are important
A Verifiable Random Function (VRF) is a cryptographic function that takes a secret key and an input string as input and returns a random output string. The key property of a VRF is that the output is verifiable, meaning that anyone can verify that the output was indeed generated from the input and the secret key, without needing to know the secret key themselves.
This is useful in applications that require random inputs, such as games and other cryptographic protocols, where it is important that the randomness is fair and cannot be manipulated by any party.
Many top NFT teams have for example, used a VRF to ensure minted tokens are randomly assigned jpegs and that rares are verifiably assigned to random token #’s.
Building our own VRF
After evaluating & experimenting with off the shelf VRF solutions, we soon felt restricted by their flexibility (e.g. incompatibility with Arbitrum Nova, the L2 to which we’ve recently migrated) & cost, and began thinking of ways we could build a custom solution. This custom solution would be tailored to our own use case, and optimized for the performance we were looking to embed into Pirate Nation.
We started with arguably the most important component for a VRF: the beacon, and found drand (a well known open source beacon, sponsored by Cloudflare & several prominent universities) to fulfill our requirements.
We paired drand with OpenZeppelin’s Defender to start constructing a two-step model (similar to other leading decentralized VRF solutions) with the goal of creating the most secure & efficient setup to generate random numbers for Pirate Nation.
Two-steps to securely generate random numbers
Only once a player performs an in-game action requiring a random number to determine the outcome of their action, and their request has been processed on the blockchain, our VRF generates the number and creates another blockchain transaction with the randomized number. This eliminates the possibility of tampering as a user is forced to choose before they know the number.
Altogether, the setup means we can provide a fast blockchain augmentation, and where appropriate we can have gameplay off-chain that is then reconcilable on-chain.
Benefits of ownership
Buy vs build decisions are always a matter of trade offs and context is important in decision making. In this instance we are particularly pleased with the upside we’ve seen in building our own VRF, namely:
1. Tailoring form & performance to our game & specific use cases. A series of micro-optimizations have allowed us to reduce our VRF runtime down to just 5 seconds.Relative to off-the-shelf solutions where we saw a 30 second runtime, this is a 500% improvement.
2. The cost-effectiveness of running our own VRF is significant — almost 3x better than options available in the market — which means we are able to make investments elsewhere in our infrastructure.
3. Lastly, functionality can be added as & when needed: for example, we have baked-in retries and a reconciliation step, so we can play-back and fill any gaps if and when they arise, increasing system reliability.
The future of random numbers
While right now we follow a tried and true model with two step, we have future plans to speed up random number generation, by using a Notary system where client actions are signed and the client can get numbers from the VRF directly. This will allow us to verify client actions on chain in a trusted model, and be able to move faster then the blockchain limits on processing. Expect to see this model used in things like PvP in the future.
Summary
Building your own VRF may not make sense for every team or on-chain application, but it did for us given the specificity of our use-case and the performance & cost benchmarks we were aiming for.
We’ll be sharing more documentation about our custom VRF in the future, and will be making it available along with other tooling when we open up the Proof of Play game platform for other teams to build on.
Questions in the meantime? Reach us in our discord.
Onward!
Proof of Play Team
