drand: publicly verifiable randomness explained

Yolan Romailler

Playlists: 'MCH2022' videos starting here / audio

drand is an opensource project allowing anybody to run a “randomness beacon”. Its goal? Providing a trustable, verifiable source of public randomness that would enable full transparency in online lotteries, leader election or blockchain smart contracts.
This talk is about what distributed randomness is, what it means for developers, and users, and why you’d want to use it. I will also present to you the current ecosystem around drand, and what it enables you to do differently and why it is desirable in a distributed, decentralized web to have public, verifiable randomness.

Don’t worry though: we will first go through an easy overview of how it works without diving too much into the gory cryptographic details. In addition, I’ll demo how drand works in practice, and explain you how you can easily use it in your applications since drand nodes can be queried by anybody.

Disclaimer: this is NOT a blockchain talk, but rather a distributed system one.

[drand](https://drand.love/) (pronounced "dee-rand") is a distributed randomness beacon daemon written in Golang.
It has been used by Cloudflare, EPFL, Kudelski Security, UCL and other partners to setup a distributed randomness project that was unveiled in June 2019: the ["League of Entropy"](https://blog.cloudflare.com/league-of-entropy). Since then even more members have joined the league.

Servers running drand can be linked with each other to produce collective, publicly verifiable, unbiasable, unpredictable random values at fixed intervals using bilinear pairings and threshold cryptography. Drand nodes can also serve locally-generated private randomness to clients.

Generating public randomness is the primary functionality of drand.
Public randomness is generated collectively by drand nodes and publicly available. The main challenge in generating good randomness is that no party involved in the randomness generation process should be able to predict or bias the final output. Additionally, the final result has to be third-party verifiable to make it actually useful for applications like lotteries, sharding, or even "nothing up my sleeves" parameter generation for security protocols.

drand relies on the following cryptographic constructions:
- Pairing-based cryptography and Barreto-Naehrig curves.
- Pedersen's distributed key generation protocol for the setup.
- Threshold BLS signatures for the generation of public randomness.
- ECIES for the encryption of private randomness.

These are well known, while still relatively cutting edge cryptographic schemes.

Why do we need such randomness?
A lot of reasons actually:
- Lotteries, jury selection, election event, random sampling for audits, ...
- Protocols & cryptography:
- Verifiable gossip: randomly choosing peers in a verifiable way in a network to disseminate information
- Parameters: Nonces & IV for symmetric encryptions, composite or prime numbers for selecting a field for RSA, or even ECC
- Schemes: Diffie Hellman exchange, Schnorr signatures, more generally for zero knowledge proofs,
- Protocols: Tor (e.g. path selection), sharding (Omniledger), leader election for consensus
- Statistics: verifiable random sampling, reducing bias e.g. in controlled trials in medicine, etc.

Now, drand is a software ran by a set of independent nodes that collectively produce randomness and whose long term goal is to implement Randomness-as-a-Service:
- Fetching randomness should be as simple as fetching time from NTP servers.
- Nodes can serve both private randomness and public randomness:
- Unpredictable and bias-resistant
- Publicly Verifiable
- Decentralized service using threshold cryptography, with high availablity, reliability and trust.

This talk will NOT be about just the cryptography behind drand, but I will cover some of the basics in a simple way in order to tease the people that could be interested, while introducing cool cryptographic constructions to the rest. It will NOT be about how drand is built, but it will really be about the **practical use-cases for drand**, how to use it, its kind of randomness, what it means and why you might want to use it.