Optimistic VRF - New, cheap way to do RNG in smart contracts
Optimistic VRF - New, cheap way to do RNG in smart contracts
With Randomizer's VRF protocol, contracts will be able to choose between two VRF methods:
Regular on-chain validated VRFs.
An optimistic system where on-chain validation is only applied when it’s detected as invalid off-chain. Sweet gas savings!
Optimistic VRF are up to 60% cheaper per request without sacrificing security. It only uses a different approach for security, which we’ll explain below.
Optimistic VRFs add a little more time between a request and a final result, but for your end-users this doesn’t make a difference as Randomizer’s sequencer service sends VRF results to your front-end in real-time as soon as a random value is requested. Your game or app can update in real-time without needing to wait for on-chain confirmations!
Regular VS Optimistic VRF
Contracts can specify whether they want to use Randomizer’s regular or optimistic VRF method. But which should you choose?
It’s important to note that Optimistic VRFs are cheaper, but slightly slower on-chain. However, Randomizer Sequencer can help your dapp/game show real-time results to users without delay, regardless of the method you're using (optimistic or regular).
So here are some possible considerations:
Use optimistic VRF when…
If you plan to have a real-time RNG experience and will use Randomizer’s Sequencer to show instant results to your users before they're finalized on-chain (i.e., update their balance, show a game result, or show their minted NFT immediately after their transaction). When using Sequencer, the extra few blocks between request and result will make no visual difference to your end-users as the experience will still look real-time. But if you need the results to be on-chain as fast as possible, use regular VRFs.
The gas savings make a big difference for your use case. If your contract uses a lot of RNG (e.g., a game with an item drop-rate or hit chance on each transaction) and new VRF values need to be requested regularly, the savings of using optimistic VRFs pile up quickly. And more saved gas means more gas available for future transactions.
Use regular VRF when…
Getting on-chain callbacks as fast as possible is a dealbreaker. Remember that you can process the result in your front-end before the result is on-chain securely using Randomizer’s Sequencer process. But if that doesn’t matter for you and this is still a dealbreaker, use regular VRFs for the on-chain time savings (regular VRFs take ~2 blocks between request and callback).
The fee savings are negligible on the network you’re using. Sure, optimistic VRFs are up to 60% cheaper, but does it really matter if users pay $0.00095 or $0.0004 in their L2 transaction? If you’re building a game that uses lots of RNG then the potential savings might make a difference. But if the VRF is only used for a short period such as an NFT minting phase, you could consider going the regular route.
If you’re only planning on getting a random value once or twice in your contract. For instance, if you’re calling Randomizer just once to shuffle a whitelist lottery, then difference in gas savings doesn’t really matter.
You’ll notice the main dealbreakers are whether you need the result to be on-chain asap (then you should use regular VRFs), and otherwise if processing the result in your front-end before it’s on-chain is a solution for your use case (optimistic VRFs are the most gas efficient solution here), and finally whether the potential gas savings make a big economic difference or not.
How it works
Technical tl;dr: Instead of validating VRF proofs submitted by beacons within the submit functions, they’re stored in the protocol without validation taking place (yet). This saves up to 60% of the gas fees compared to directly validating the VRF immediately.
An event is fired with the proof data that allows anyone to validate it off-chain. If the proof is invalid, the dispute() function can be called on it within a configured time window (x blocks + y seconds).
dispute() validates the proof on-chain, and if the VRF is indeed invalid, the disputed beacon’s ETH stake is used to refund all fees paid for this request so far, and the rest of their entire stake goes to the disputer. This means there’s a big incentive to dispute incorrect VRFs, and a big punishment for attempting to submit invalid VRF proofs. And if the VRF is valid, dispute() simply reverts.
All beacons on the network automatically validate optimistic VRFs off-chain and call dispute() on invalid VRFs. We’ll also have a disputer server application ready that anyone can run to validate and dispute Optimistic VRF submissions.
To ensure all VRF submissions can be adequately disputed if they’re invalid, a dispute time window (blocks + seconds) is added when all proofs are submitted. The final callback to the requesting contract can only be made when this dispute window is over.
This dispute window adds a little time between the request and the result compared to Randomizer’s regular VRF logic. Luckily, Randomizer has a real-time sequencer service that lets results be processed in a dapp’s front-end in near instantly after a request is confirmed on-chain.
Wen mainnet?
We understand you might be working on a smart contract and would love to use Randomizer, so the protocol’s release date is important info to have.
We’re happy to announce we’re in the final stages of development. Expect Randomizer to be live on EVM-supported Layer 1 and Layer 2 networks in early October.
Join the Randomizer Discord, follow us on Twitter, and subscribe to our email newsletter to stay up to date!