drand is a distributed randomness beacon. It provides publicly-verifiable, unpredictable and bias-resistant random numbers as a public service. In this module we'll walk through: - Threshold Cryptography & Randomness - The Distributed Key Generation in drand - The Setup and Randomness Generation Phases - The League of Entropy

1. Drand:
the Distributed
Randomness Beacon
ResNetLab on Tour

2. A randomness beacon as a foundational Internet protocol
Distributed, bias-resistant, unpredictable and publicly-verifiable randomness.
As of August 2021, drand is a network of
16 independent partners and has just completed 1M rounds.

3. Agenda
➔ Intro & Context
◆ Why do we need randomness?
◆ Different flavours of randomness
◆ Previous Attempts and Existing Solutions
➔ Technical Background
◆ Threshold Cryptography
◆ Threshold Randomness
◆ Shamir Secret Sharing
◆ Distributed Key Generation (DKG)
◆ BLS Signatures
➔ drand
◆ Generation Phase
◆ The Chain
◆ Future Directions
➔ The League of Entropy
◆ Goal of the League
◆ The Production Network
◆ Governance Model
◆ Filecoin: A drand client

4. Intro & Context
Technical Background
drand
The League of Entropy

5. Why do we need randomness ?
● Lotteries, jury selection, election event audits…
● Protocols & Cryptography:
○ Protocols: leader election in Proof of Stake blockchains, Tor (path selection...), sharding...
○ Gossiping: randomly choosing peers in the 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…
○ Statistics: sampling, reducing bias in controlled trials in medicine
● Even for cleromancy and divination … !

6. Why Do We Need
GOOD Randomness ?
● Rigged lotteries: Hot Lotto Fraud Scandal¹ where an insider rigged the drawing of more than
14.3 millions of dollars in prizes
● Rigged pseudo random number generator: DUAL_EC_DRBG² is a CSPRNG.
○ Suspicions of a backdoor being hidden by... the NSA !
○ NYT confirmed non-released documents + Snowden releases
○ Led for example to widely publicized Juniper backdoors³]
● Non robust ransomware: Linux.Encoder.1⁴ uses timestamp as a seed to generate encryption
keys. However timestamp is kept in clear with encryption…
→ Need of a foundational internet protocol for randomness
1. https://en.wikipedia.org/wiki/Hot_Lotto_fraud_scandal
2. https://en.wikipedia.org/wiki/Dual_EC_DRBG
3. https://www.wired.com/2015/12/researchers-solve-the-juniper-mystery-and-they-say-its-partially-the-nsas-fault/
4. https://en.wikipedia.org/wiki/Linux.Encoder.1

7. Randomness in Blockchains
One of the reasons why Ethereum 2 has taken so much time
Industry moving to use separate chains for randomness (eg ETH2, FIL)
Solution Reliability Issues
Proof of work Runs $200B+ financial
networks for 5-10
years
● Expensive and inefficient computationally
● Economies of scale leads to centralization
● Cannot extract randomness from blocks in a fully secure way
On-chain randomness for
Proof-of-Stake
Deployed to run large
financial networks
($5B+) in last 2 years
● Many variations, most of them biasable by miners
● Only Cardano has a proven and running system but very high finality
time (2-3 d)
● Randomness tied to the lottery usage - unusable for applications
Verified Delay Functions (VDFs) Not used in practice ● Lots of R&D but likely 2~5 years away from wide use
Blockchains run leader elections to determine block producer

8. What kind of randomness
do we need ?
In the decentralized web, we often need the following properties:
● Unpredictable: Can’t predict the next bytes/numbers, at all times
● Bias-resistant: Can’t bias the final output in a certain way
● Publicly verifiable: Anybody can verify output is a “legit” random number
● Decentralized: Output is produced by a set of (independent) active parties.
● Available: The system must always be able to deliver random numbers (at least liveness)

9. Previous attempts to
generate randomness
Some examples:
● NIST Randomness beacon¹ based on quantum entanglement:
○ unpredictability, autonomy, consistency
○ We still need to trust NIST… ( remember DUAL_EC_RNG )
● Bitcoin²: Using blockchain as a source of random value
○ Promising, but slow, relies on PoW which is inefficient and leads to centralization
● Randhound³: the jackpot!
○ Scalable, bias-resistant, unpredictable, publicly verifiable, decentralized
○ Relies on solid cryptographic assumptions, uses ECC
○ But offers probabilistics guarantees, has complex setup, large transcript to verify, multiple RTT, 6s generation… Can we
do simpler & faster ?
1. https://www.nist.gov/programs-projects/nist-randomness-beacon
2. https://eprint.iacr.org/2015/1015
3. https://eprint.iacr.org/2016/1067.pdf

10. Intro & Context
Technical Background
drand
The League of Entropy

11. Threshold Cryptography!
● Threshold cryptography allows to decentralize
many centralized cryptographic protocols
(signatures, encryption...)
● Main idea:
○ Any t participants out of n need to
participate to create signature
● By generating a threshold signature, we can derive
verifiable randomness in a decentralized way!
1
3
5
2
4
3 out of 5
required

12. Threshold Randomness: 2 Phases
Setup Phase
● A predefined list of nodes must run this
protocol
● Can think of it as a trusted setup party
● Complexity is O(N^2)
● Bonus: same setup phase can be used to
change a current group into another
Randomness Generation
● Combines partial information from
different nodes to create
randomness
● Lightweight and fast protocol

13. Background - (t-n) Shamir Secret Sharing
f(x) = s + a1
* x + … + at-t1
* xt-1 s1
= f(1), s2
= f(2), … , sn
= f(n)
T shares {si
}
Lagrange Interpolation
s
● Goal: Split a value in n shares, such that at least t shares are needed to
reconstruct the original value (t ≤ n)
● Idea: k points (x,y) of a polynomial of degree k-1 can uniquely reconstruct this
polynomial.
● Protocol:
○ Dealer creates polynomial f(x) of degree t-1,
○ First coefficient is the secret value s
○ Send to each share holder i their share f(i) -> n shares in total

14. Background - (t-n) Distributed Key Generation
f1
(x) = s1
+ a1,1
* x + … + a1,t-1
* xt-1
f2
(x) = s2
+ a2,1
* x + … + a2,t-1
* xt-1
fn
(x) = sn
+ an,1
* x + … + an,t-1
* x t-1
s1,1
= f1
(1) s1,2
= f1
(2) ... s1,n
= f1
(n)
+ s2,1
= f2
(1) s2,2
= f2
(2) ... s2,n
= f2
(n)
+ sn,1
= fn
(1) sn,2
= fn
(2) ... sn,n
= fn
(n)
= s1
s2
... sn
● Goal: Create shares of a private key that no party knows, with at least t shares needed to
reconstruct the private key
● Idea: Run n secret sharing protocol in parallel and each node adds all its shares
● Secret key s = ∑ si
is recoverable by using Lagrange Interpolation on t shares si
● Public key is P = s * G with
○ G a generator of the group
○ P is publicly distributively computed by sharing commitments Fi
(x) = fi
(x) * G
s
+
+

15. Background - BLS signatures
3 groups with a mapping e
such that :
● e: (G1
x G2
) → GT
● Bilinearity: e( aR1
, bR2
) =
e( R1
, R2
)^(ab)
1. https://www.iacr.org/archive/asiacrypt2001/22480516.pdf
● Signature over message M with
private key s : sig = H(M)^(s) over G1
● Verification with public key P : e( sig,
G2
) ≟ e( H(M) , P )
● H is a collision resistant hash
function
● Need t partial signatures sigi
=
H(M)^(si
) to reconstruct one final
signature sig (Lag. interp.)
● BLS Verification with distributed
public key P works !
Pairing based
cryptography
BLS
signature¹
Threshold BLS
signature

16. Intro & Context
Technical Background
drand
The League of Entropy

17. Drand
● Drand is a software ran by a set of independent nodes that collectively produce
randomness
● Decentralized randomness service using threshold cryptography
○ (t-n) Distributed Key Generation: t = n/2
○ Key is defined on G2
of the BLS12-381 pairing curve (same as eth2)
● Binds together independent entropy sources into a publicly verifiable one
● Drand is open source¹, coded in Go
○ Originally from DEDIS@EPFL, moved to independent organization¹
○ Now supported by Protocol Labs
● Tested, audited, and deployed (more on that later)
● Simple: `curl https://api.drand.sh/public/latest` ->
1. https://github.com/drand/drand

18. Drand: The Protocol - Generation
● Randomness generation is a threshold BLS signature
protocol using the shares from the setup phase
○ The hash of the final signature is the randomness !
1. Each node requests a partial signature to at least t
nodes
2. Reconstruction of final signature with at least t valid
partial signatures
● Properties:
○ Unpredictable & unbiasable from BLS properties
○ Publicly verifiable (ensures at least t nodes participated)
○ Decentralized
○ Available: clients can always retrieve randomness
○ Fast: cost is RTT time + Lagrange interpolation
1.
Broadcast
Partial
Signatures

19. Drand: The Protocol - Generation
● Randomness generation is a threshold BLS signature
protocol using the shares from the setup phase
○ The hash of the final signature is the randomness !
1. Each node requests a partial signature to at least t
nodes
2. Reconstruction of final signature with at least t valid
partial signatures
● Properties:
○ Unpredictable & unbiasable from BLS properties
○ Publicly verifiable (ensures at least t nodes participated)
○ Decentralized
○ Available: clients can always retrieve randomness
○ Fast: cost is RTT time + Lagrange interpolation
2.
Reconstruction

20. Drand: The Protocol - Chain
Rounds: drand increase chain’s length periodically, every epoch.
● At each new round, there’s only one possible new randomness
(unbiasability).
● drand has recently (July 2021) exceeded 1M rounds!
Time - Round consistency:
● 1 round = 1 unix timestamp
Chain: signatures form a chain !
● new_rand = Signature( H( round || previous_randomness) )
● WIP v2: unchained randomness
○ new_rand = Signature( H( round) )
○ Security relies on threat model so there is no compromise
○ Unchaining will enable timelock encryption and mitigation of frontrunning
attacks!
Time 0s Time 30s Time 60s
Round 1 Round 2 Round 3

21. Intro & Context
Technical Background
drand
The League of Entropy

22. The League of Entropy
The League is a global drand
network composed of multiple
independent, diversified
organizations
● Created in June 2019¹ with
initially 10 members
● It is now composed of 16
members, 23 nodes and a
threshold of 12.
1. https://www.cloudflare.com/leagueofentropy/

23. Goal of the League
● The network provides “Randomness as a Service”
● In the same way that we all have access to:
○ DNS - Highly available source of naming information
○ NTP - Highly available source of timing information
○ Certificate Authorities - Trusted network delivering certificates
○ Certificate Transparency - Certificate authenticity information provided by a private network (Google,
Cloudflare, DigiCert…)
→ drand: Foundational internet protocol for randomness

24. Production Ready Network
● High availability and DDoS resistance
○ Redundancy, network protection, and monitoring/maintenance
● Distribution network separated from randomness generation
● Global distribution & Diversified distribution paths
○ Partner diversity (profile, geography)
○ Distributed over HTTP, libp2p, Tor, Twitter…
● Codebase audited (public report¹), continuous integration, testnet
● Health monitoring (prometheus, alerts if randomness doesn’t come through)
1. https://drive.google.com/file/d/1fCy1ynO78gJLCNbqBruzHx7bh72Tu-q2/view

25. Production Ready Network

26. Governance model
Goal is to have a set of participants as large and
as diverse as possible
● Geographic position, jurisdiction, interests, internet /
server provider
New member applications are open
● Some criteria must be met to be eligible
The network changes on a quarterly basis
● Members vote for new arrivals
● Shares are refreshed
USA
Switzerland
Chile
Portugal
Great Britain
on-prem
AWS
Cloudflare
Azure
Exoscale
Jurisdiction
Partner Diversity
Israel

27. ● Filecoin: largest production grade consumer of drand
● Randomness stored in block header in Filecoin
○ Each epoch is mapped to a drand round
● Miners elected via drand randomness
○ Similar to PoS but with storage power
○ H(rand) < myPower / totalPower ?
Consumable via HTTP requests through curl:
Consumers of drand Header
Epoch
76283
Rand
e87fc2
Header
Epoch
76284
Rand
63ab8a
Header
Epoch
76285
Rand
13dfea
Round
89712
Rand
e87fc2
Round
89713
Rand
63ab8a
Round
89714
Rand
13dfea

28. Thank you !
For more information and/or if you want to reach out, go to:
https://drand.love
https://leagueofentropy.com
https://github.com/drand/drand