Drand Bridge Pallet | Retroactive Funding
Introduction
Ideal Labs is working to develop onchain randomness solutions for substrate based chains and beyond. To date, we have participated in the web3 foundation’s grant program, where we developed a prototype version of a substrate-based randomness beacon. We are currently participants in the decentralized futures program. The work presented here is not covered within our contract with DF.
Verifiable randomness is a critical component for enabling fairness in decentralized protocols. Unfortunately, existing solutions for Substrate-based chains have limitations. We are proposing retroactive funding to support the development and maintenance of a Drand to Substrate bridge, bringing drand's verifiable randomness to Kusama.
We developed a drand bridge pallet, allowing Substrate-based runtimes to consume verifiable randomness from Drand's Quicknet. It can be used as a drop-in replacement anywhere the Randomness trait is used. We also built a node that supports host functions built with the arkworks-extensions library, which is required to efficiently verify drand's pulses. Finally, we developed a chain extension and smart contract environment so that the output of drand can be used within ink! smart contracts, along with a demonstration rock-paper-scissors game.
Key Benefits of this work include:
- Robust and Verifiable onchain randomness: drand enables highly secure, robust, verifiable randomness. With this work, it is easy to use it both within pallets and smart contracts.
- Timelock Encryption: drand's output enables us to build timelock encryption capabilities on top of the beacon, enabling new kinds of use cases for trustless protocols, such as trustless asset swaps, keyless crypto wallets, and more.
- Potential Ecocsystem Growth: EVM-based blockchains perform pairing operations poorly, so there is no cost-efficient drand > ETH bridge (though one does exist through Starknet). In general, EVM-based applications rely on VRF-based randomness-as-a-service solutions like Chainlink VRF, which carries a significant cost (also: no timelock encryption). This solution uses optimized arkworks extensions to efficiently compute pairings on-chain.
This post is to ask for feedback and review of our proposal for retroactive funding of our work on:
- a drand bridge pallet
- a node template supporting arkworks host functions
- a chain extension and contract environment for using randomness in ink! smart contracts
- A demo dapp: casino-style rock-paper-scissors
Retroactive funding will allow us to maintain and enhance this pallet, where we will work to support other beacons (e.g. NIST's beacon) and eliminate current limitations (see proposal). Our goal is for this to be an easy-to-use module for other networks - solochain or parachain - to acquire secure verifiable randomness and timelock encryption capabilities.
Read the full proposal here: https://docs.google.com/document/d/1wjn8Il3O5A51MU24CUdOhNyoU2YAABrLsWiOckM8Kg4/edit?usp=sharing
Comments (9)
on brief look proposal and its ask seems reasonable especially considering focus on providing support, further integration and hopefully improved demo(time to see if kusama can handle its fomo3d?) probably good idea to get ideal network running for demo before proposing referendum.
@tommi thanks for the feedback! That's a good point. As of today we have a testnet with a solochain version of the network running currently to showcase the the pallet and test long-term behavior. I also just deployed the RPS game (https://rps.idealabs.network), so I'll add those items to the proposal description as well.
Initial Questions:
1— How do the costs of Drand compare with Chainlink VRF or Moonbeam VRF, which I previously dabbled with here? https://github.com/ltfschoen/XCMTemplate/tree/main/dapps/evm2/randomness
2— Could you please explain the benefits of timelock encryption offered by Drand? Ans: Found the answer in your full proposal https://drand.love/docs/timelock-encryption
3— Could you please explain the benefits of efficiently computing pairings on-chain using optimized arkworks extensions?
4— How does it compare to generating a source of randomness from a future blockhash like I previously dabbled with here https://github.com/ltfschoen/XCMTemplate/blob/main/dapps/xcm/unnamed/oracle_contract/lib.rs
5— How does it compare with using ZK to generate a source of randomness?
6— How does it compare to generating a source of randomness in secure enclaves of Phala Phat Contracts?
Note: I haven't had time to read your full proposal yet, I've only skim read parts of it
@ltfschoen
To answer your questions:
Drand is free to consume, so the only additional costs come from running acquiring and verifying pulses from the beacon, which is relatively cheap.
Glad you found it! In general I would describe it as providing the ability to do a non-interactive, async commit-reveal (e.g. I commit, but then I can throw away the original message and anybody can do the reveal after a deadline).
Being able to efficiently compute pairings means that we're able to verify pulses from drand more efficiently than EVM-based systems, meaning that it is cheaper (by how much? not sure, we'll look into it) to build a bridge to drand this way than, for example, on Ethereum. As a result of supporting the arkworks host functions we can also perform other arkworks operations more efficiently (e.g. verifying groth16 proofs).
Generating randomness from future block hashes is a form of insecure randomness. It can be manipulated by block producers, for example. This doc has some further examples of this in solidity: https://www.immunebytes.com/blog/bad-randomness-in-solidity-smart-contracts/.
If you mean using SNARKs/VDFs on Ethereum for example, I can't say I've done too much research on it. Looking at sources like this, it relies on RANDAO as the underlying beacon (which can potentially be manipulated by block producers), though their scheme seems to be able to account for this. It also goes back to cost, it's cheaper to compute two pairings on our node than to verify many snarks on Ethereum. Those schemes generally don't support timelock encryption either.
I also haven't looked that much into this, haven't used Phala before. Reading this doc, it would seem that they still rely on insecure randomness. However, assuming they can generate randomness within the TEE, the implication is that many participants could find it difficult to trustlessly agree on a random output since it would likely lack public verifiability. Also, no tlock.