This page was originally posted on Cloudflare's randomness beacon documentation website.
Drand (pronounced "dee-rand") is a distributed randomness beacon daemon written in Golang. Servers running drand can be linked with each other to produce collective, publicly verifiable, unbiased, unpredictable random values at fixed intervals using bilinear pairings and threshold cryptography.
Drand is meant to be an Internet infrastructure level service that provides randomness to applications, similar to how NTP provides timing information and Certificate Transparency servers provide certificate revocation information.
# Why decentralized randomness is important
Over the years, a generation of public randomness (often referred to as common coins) has attracted continuous interest from the cryptography research community. Many distributed systems, including various consensus mechanisms, anonymity networks such as Tor, or blockchain systems, assume access to such public randomness. For example, in recent Proof of Stakes blockchains, miners are being elected randomly at each epoch via a common source of randomness. However, it remained a major missing piece of the puzzle to have a unbiasable public source of randomness which is distributed & scalable. There are some centralized solutions which exists as of today, for example the randomness beacon run by NIST or the one from the University of Chile. Even though they do provide an uniform source of randomness, these beacons are not verifiable nor decentralized. Verifiability is necessary for examples in Proof of Stakes systems where a block producer needs to prove he has been elected as a miner for the given epoch. Decentralization helps for the liveness of the beacon.
# Origins of drand
The DEDIS lab was already working on a decentralized randomness project called Scalable Bias-Resistant Distributed Randomness led by Ewa Syta, that started under the supervision of Michael J. Fischer and Bryan Ford at Yale University. After Bryan moved to EPFL in 2015, the new members of the DEDIS team at EPFL (Nicolas Gailly, Linus Gasser, Philipp Jovanovic, Ismail Khoffi, Eleftherios Kokoris Kogias) joined the project and together published a research paper at the 2017 IEEE Symposium on Security and Privacy.
However, that system presented a randomness generation protocol with multiple rounds, a complex node topology, a large transcript to verify for the end user and a client that needed to actively participate in the request. Using more recent development in the field of pairing based cryptography, we could devise the next generation of randomness beacon with a trivial protocol and with faster verification and shorter transcript.
In early 2007, the DEDIS team started a collaboration with DFINITY on various topics including public randomness. Indeed, DFINITY's architecture included the notion of a randomness source that uses the same cryptographic techniques as drand. Additionally, they had implemented an optimized pairing library in C++ for the BN256 curve. After integrating this implementation into the DEDIS’ crypto library Kyber, all major cryptographic components were ready to implement an efficient, distributed randomness generation protocol using pairings.
Thanks to the use of pairing based cryptography, drand is able to generate randomness in a very simple and efficient manner and to deliver it in a reliable way to the client. Drand was meant to be from the ground up a distributed service providing public randomness in an application-agnostic, secure, and efficient way. And nothing else. The idea is that instead of having each blockchain systems re-inventing the wheel internally, often poorly, drand would provide it for them.
Thanks to @herumifor providing support on his optimized pairing-based cryptographic library used in the first version. Thanks to Apostol Vassilev for its interest in drand and the extensive and helpful discussions on the drand design. Thanks to @Bren2010 and @grittygrease for providing the native Golang bn256 implementation and for their help in the design of drand and future ideas.
Finally, two special notes: