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)
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.
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
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.
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