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 (7)
Requested
Proposal Passed
Nice job! I told them this would be useful, so I'm happy its built and pleased the tooling looks fleshed out. A prachain can use this now even before we ship the ECC hostcalls for arkworks-extension, but pairings cost 10x more CPU time in pure wasm. It's still nothing like the zk prover time to do a one million constraint proof of a pairing on ETH. It's absolutely fine if you're doing it in a state channel for a game. An EVM parachain could provide calls or precompiles for this too, or all manor of other functionality, but then their EVM contracts become stronctly more powerful than ETH ones, which maybe good for them, but bad for the wider EVM community. lol
Thanks @tommi, @ltfschoen and @jeff for your feedback.
I would like to encourage more people to let us know their thoughts. Especially for those voting Nay, we'd like to know what are your concerns and why you think this proposal doesn't look good for you. We appreciate all constructive feedback, as it helps us to work towards improving what we are doing.