Module: drand - the Distributed Randomness Beacon

1. Drand: the Distributed Randomness Beacon ResNetLab on Tour

2. A randomness beacon as a foundational Internet protocol Distributed, bias-resistant, unpredictable and publicly-veriﬁable 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 ﬂavours 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 ﬁeld for RSA, or even ECC ○ Schemes: Diﬃe 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 conﬁrmed 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 ﬁnal output in a certain way ● Publicly veriﬁable: 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 ineﬃcient and leads to centralization ● Randhound³: the jackpot! ○ Scalable, bias-resistant, unpredictable, publicly veriﬁable, 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

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 veriﬁable randomness in a decentralized way! 1 3 5 2 4 3 out of 5 required

12. Threshold Randomness: 2 Phases Setup Phase ● A predeﬁned 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

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 deﬁned on G2 of the BLS12-381 pairing curve (same as eth2) ● Binds together independent entropy sources into a publicly veriﬁable 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

22. The League of Entropy The League is a global drand network composed of multiple independent, diversiﬁed 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.cloudﬂare.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 Cloudﬂare 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

Module: drand - the Distributed Randomness Beacon

Estás leyendo una previsualización.

Eche un vistazo a continuación

Module: drand - the Distributed Randomness Beacon

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a Module: drand - the Distributed Randomness Beacon (20)

Más reciente (20)