# About

This page was originally posted on Cloudflare's randomness beacon documentation website (opens new window).


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 (opens new window) or the one from the University of Chile (opens new window). 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

Drand's development originally started in 2017 at the DEDIS (opens new window) lab at EPFL (opens new window) by Nicolas GAILLY, a PhD student at the time with the help of Philipp Jovanovic and under the supervision of Bryan Ford.

The DEDIS lab was already working on a decentralized randomness project called Scalable Bias-Resistant Distributed Randomness (opens new window) led by Ewa Syta (opens new window), that started under the supervision of Michael J. Fischer (opens new window) and Bryan Ford (opens new window) at Yale University. After Bryan moved to EPFL in 2015, the new members of the DEDIS team at EPFL (Nicolas Gailly (opens new window), Linus Gasser (opens new window), Philipp Jovanovic (opens new window), Ismail Khoffi (opens new window), Eleftherios Kokoris Kogias (opens new window)) joined the project and together published a research paper at the 2017 IEEE Symposium on Security and Privacy (opens new window).

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 2017, the DEDIS team started a collaboration with DFINITY (opens new window) 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 (opens new window), 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.

As drand has gained maturity, an increasing number of organizations (including NIST, Cloudflare, Kudelski Security, the University of Chile, and Protocol Labs) started taking interest, and decided to collectively work on setting up a drand network spanning these organizations. To support the use of public randomness in web applications, Mathilde Raynal , a master student at DEDIS, started developing a JavaScript proof-of-concept frontend, called drandjs , to interact with drand servers.

# Acknowledgments

Thanks to @herumi (opens new window)for 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 (opens new window) and @grittygrease (opens new window) for providing the native Golang bn256 implementation and for their help in the design of drand and future ideas.

Finally, two special notes:

Get in touch

If you have any questions or comments, you can reach the Drand team at leagueofentropy@googlegroups.com or join the drand slack workspace (opens new window).