1 of 110

Randomness beacons in theory and practice

Joseph Bonneau

Real World Crypto

March 28, 2025

2 of 110

Dedicated to Ross Anderson (1956-2024)

3 of 110

An ideal randomness beacon [Rabin83]

Goals (high level):

    • Statistically uniform randomness
    • Public consensus
    • High bandwidth
    • Attackers can’t:
      • Manipulate
      • Predict
      • Block

time

epoch 1

4169

epoch 2

9772

epoch 3

6015

...

...

4 of 110

Beacons can power verifiable lotteries

5 of 110

Beacons can power verifiable lotteries

6 of 110

Many use cases beyond lotteries

  • Games
  • Randomized audits
  • Parameter setup for cryptographic protocols
  • Leader election in consensus protocols
  • Randomized transaction ordering
  • Challenges for non-interactive cryptographic proofs

Goal: Many applications driven by a public randomness beacon

7 of 110

State of the art has barely changed for millenia!

8 of 110

This talk: distributed randomness beacons

    • Multiparty protocol with n participants, produce output Ωi in epoch i
    • Up to t out of n nodes are controlled by the adversary

time

Ω1

Ω2

Ω3

...

entropy

entropy

entropy

9 of 110

Classic: Commit-Reveal

 

c3

c2

c1

10 of 110

Classic: Commit-Reveal

 

 

e3

e2

e1

11 of 110

Classic: Commit-Reveal

 

 

e2

e1

12 of 110

DRB design comparison

Protocol

Per-Round

Comm.

Threshold to Manipulate

Threshold to Predict

Threshold to Block

Notes

commit-reveal-fail

O(n)

n

n

1

13 of 110

DRB design comparison

Protocol

Per-Round

Comm.

Threshold to Manipulate

Threshold to Predict

Threshold to Block

Notes

commit-reveal-fail

O(n)

n

n

1

commit-reveal-restart

O(n)

1

1

14 of 110

Commit-reveal-punish

  1. Commit/deposit

c1,$

c3,$

c2,$

15 of 110

Commit-reveal-punish

  1. Commit/deposit

  1. Reveal + refund
    1. Participants who don’t reveal lose funds
    2. Restart if any participant aborts

e2

e1

$

$

16 of 110

DRB design comparison

Protocol

Per-Round

Comm.

Threshold to Manipulate

Threshold to Predict

Threshold to Block

Notes

commit-reveal-fail

O(n)

n

n

1

commit-reveal-restart

O(n)

1

1

commit-reveal-punish

O(n)

1

1

economic security

17 of 110

Commit-reveal-punish: RANDAO

  • Deployed in Ethereum since 2020
    • Used for committee selection
  • Also available to smart contracts
    • block.prevrandao
  • Proposer can reveal VRF or withhold
    • Withholding precludes block reward
  • Withholding is profitable! [AW24]

18 of 110

Commit-reveal-punish: RANDAO

  • Deployed in Ethereum since 2020
    • Used for committee selection
  • Also available to smart contracts
    • block.prevrandao
  • Proposer can reveal VRF or withhold
    • Withholding precludes block reward
  • Withholding is profitable! [AW24]

Optimal RANDAO Manipulation in Ethereum. Kaya Alpturer, S. Matthew Weinberg. AFT 2024.

19 of 110

Commit-reveal-recover

  1. Commit
    1. Publish ci = Commit(ei) as in classic CR
    2. Secret-share ei with all other nodes
      1. PVSS: Publicly verifiable secret sharing

c2 , PVSS(e2)

c1 , PVSS(e1)

c3, PVSS(e3)

20 of 110

Commit-reveal-recover

  1. Commit
    1. Publish ci = Commit(ei) as in classic CR
    2. Secret-share ei with all other nodes
      1. PVSS: Publicly verifiable secret sharing

  • Reveal
    1. Publish ei as in classic CR
  • Recover
    1. Honest participants reconstruct any missing ei

e2

e1

e3

PVSS.reconstruct()

Ω

21 of 110

Commit-reveal-recover variants

  • Better PVSS
    • SCRAPE [CD 17]

  • Amortized PVSS
    • HERB [CSO 19]
    • Albatross [CD 20]

  • Remove optimistic case (share-reconstruct-aggregate)
    • RandShare [SJKGGKFF 17]
    • SecRand [GSX 20]

22 of 110

DRB design comparison

Protocol

Per-Round

Comm.

Threshold to Manipulate

Threshold to Predict

Threshold to Block

Notes

commit-reveal-fail

O(n)

n

n

1

commit-reveal-restart

O(n)

1

1

commit-reveal-punish

O(n)

1

1

economic security

commit-reveal-recover

O(n2)

t

t

n-t

23 of 110

Pseudorandom DRBs

  1. Setup
    1. Output is t-out-of-n secret-shared VRF key
    2. Can be distributed setup (DKG) or centralized

e3

e2

e1

PubKeyDRB

24 of 110

Pseudorandom DRBs

  1. Setup
    1. Output is t-out-of-n secret-shared VRF key
    2. Can be distributed setup (DKG) or centralized

  1. Output
    1. Compute VRF on round input ri
    2. Can be static (epoch number) or prior Ω
    3. Collect partial VRF evaluations
    4. Combine to output distributed VRF

σ3

σ2

σ1

VRF(ri , PubKeyDRB)

ri

25 of 110

Pseudorandom DRB variants

  • drand/DFINITY
    • Threshold BLS signatures

  • STROBE [BCKKLNNRS 21]
    • Threshold RSA decryption, with history generation

  • RandHerd [SJKGGKFF 17]
    • Threshold Schnorr, sharded into groups

  • DDH-DRB, GLOW-DRB [GLOW 20]
    • Threshold DDH-VRF (like BLS, but NIZK instead of pairings)

26 of 110

DRB design comparison

Protocol

Per-Round

Comm.

Threshold to Manipulate

Threshold to Predict

Threshold to Block

Notes

commit-reveal-fail

O(n)

n

n

1

commit-reveal-restart

O(n)

1

1

commit-reveal-punish

O(n)

1

1

economic security

commit-reveal-recover

O(n2)

t

t

n-t

pseudorandom

O(n)

t

n-t

requires setup;

no forward security

27 of 110

drand: a production pseudorandom DRB

  • Launched 2019

  • Threshold BLS signatures
    • BLS12-381 curve

  • Currently 20 nodes
    • t=11 required to sign

  • 256 bits every 30 seconds

  • Nodes run by academics + industry

28 of 110

Reveal-delay (Unicorn) [LW15]

  1. Reveal
    1. Raw entropy, no commitments needed!

e3

e1

e2

29 of 110

Reveal-delay (Unicorn) [LW15]

  • Reveal
    • Raw entropy, no commitments needed!

e3

e1

e2

Just

One

Honest

Node

30 of 110

Reveal-delay (Unicorn) [LW15]

  1. Reveal
    1. Raw entropy, no commitments needed!

  1. Delay + combine
    1. Modern approach: use a VDF
      1. Slow (sequential) to compute
      2. Efficiently verifiable

e3

e1

e2

Ω

31 of 110

Reveal-delay (Unicorn) [LW15]

  1. Reveal
    1. Raw entropy, no commitments needed!

  1. Delay + combine
    1. Modern approach: use a VDF
      1. Slow (sequential) to compute
      2. Efficiently verifiable

e1

e2?

?

Last revealer(s) can’t compute VDF fast enough to bias

e3?

32 of 110

Delay functions are a powerful tool

Fast

Intractable

Encryption

Decryption

Signing

Verification

Hashing

Key search

Discrete log

Factoring

Collision-

finding

Delay functions:

take a specified number of sequential steps

VDFs

Timed commitments

Time-lock encryption

Delay encryption

...

33 of 110

Delay-based DRB variants

  • Frequent output: RandRunner [SJSHW20]
    • Deliver output more often than delay parameter via pipelining

  • Efficient optimistic case: Bicorn [CATB23]
    • Skip delay function if all participants are honest

  • Sublinear communication: Cornucopia [CCB24]
    • Leader gathers contributions and broadcasts succinct commitment

34 of 110

Delay-based DRBs in practice: Chia

  • Used for consensus
    • Launched 2021

  • VDF: Repeated squaring in class group
    • 1024-bit discriminant
    • Wesolowski proofs [W19]

35 of 110

DRB design comparison

Protocol

Per-Round

Comm.

Threshold to Manipulate

Threshold to Predict

Threshold to Block

Notes

commit-reveal-fail

O(n)

n

n

1

commit-reveal-restart

O(n)

1

1

commit-reveal-punish

O(n)

1

1

economic security

commit-reveal-recover

O(n2)

t

t

n-t

pseudorandom

O(n)

t

n-t

requires setup;

no forward security

delay-based

O(n)

n

n

added latency

36 of 110

VDF designs are relatively new

37 of 110

Dishonest-majority DRB without delay functions?

38 of 110

Dishonest-majority DRB without delay functions?

  • Classic result: Dishonest majority DRBs impossible
    • Limits on the security of coin flips when half the processors are faulty. Richard Cleve. TOC 1986.

  • Practical observation: Dishonest majority DRBs possible with VDFs

  • New result: Dishonest majority DRB require delay functions!
    • Good Things Come to Those Who Wait: Dishonest-Majority Coin-Flipping Requires Delay Functions. Joseph Bonneau, Benedikt Bünz, Miranda Christ, Yuval Efron. Eurocrypt 2025.
    • Simple delay function, not full VDF
      • Not parameterizable, not efficiently verifiable
    • Assumes network synchrony

39 of 110

Why design to tolerate n-1 dishonest nodes?

  • Dishonest majority enables open participation
    • No security downside to adding more participants!

40 of 110

DRB design comparison

Protocol

Round

Efficiency

Threshold to Manipulate

Threshold to Predict

Threshold to Block

Notes

commit-reveal-fail

O(n)

n

n

1

commit-reveal-restart

O(n)

1

1

commit-reveal-punish

O(n)

1

1

economic security

commit-reveal-recover

O(n2)

t

t

n-t

pseudorandom

O(n)

t

n-t

requires setup;

no forward security

delay-based

O(n)

n

n

added latency

41 of 110

Which DRB should I use?

commit-reveal (vulnerable)

Clear economic model?

commit-reveal-punish

Honest majority?

delay-based DRB

Static participant set?

pseudorandom DRB

Small participant set?

commit-reveal-recover

committee-based DRB

yes

no

yes

yes

no

42 of 110

Open questions (protocol design)

  • Secret Leader Election
    • DRBs where only winner finds out they have won

  • Silent setup
    • Use existing public keys for psuedorandom DRB with no (or limited) setup

  • Optimistic protocols
    • Faster execution if all nodes (or chosen leader) honest

  • Certified randomness
    • Use quantum computation, only need one node!

43 of 110

Open questions (engineering)

  • Simpler API for developers
    • Smart contract integration: Aptos Roll, Mysten sui::random

  • VDF deployment
    • Security requires public access to VDF hardware

  • Local randomness generation
    • DRB is no better than nodes’ RNGs!

  • Ensuring public trust

44 of 110

Ensuring public trust is the primary challenge

45 of 110

Thank you!

For more, see 3 detailed surveys:

SoK: Decentralized randomness beacon protocols. Raikwar, Mayank, and Danilo Gligoroski. ACISP 2022. https://arxiv.org/pdf/2205.13333

SoK: Distributed Randomness Beacons. Kevin Choi, Athira Manoj and Joseph Bonneau. IEEE S&P 2023. https://eprint.iacr.org/2023/728

SoK: Public Randomness. Kavousi, Alireza, Zhipeng Wang, and Philipp Jovanovic. EuroS&P 2024. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=10629002

46 of 110

Required disclosures

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities, digital assets, tokens, and/or cryptocurrencies are for illustrative purposes only and do not constitute a recommendation to invest in any such instrument nor do such references constitute an offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

47 of 110

Backup slides

48 of 110

Detailed comparison in SoK paper

SoK: Distributed Randomness Beacons.

Kevin Choi, Athira Manoj and Joseph Bonneau.

IEEE Security & Privacy (Oakland) 2023

https://eprint.iacr.org/2023/728

49 of 110

Current work on delay-based DRBs

Bicorn: eliminate delay function in optimistic case!

Bicorn: An optimistically efficient distributed randomness beacon

Kevin Choi, Arasu Arun, Nirvan Tyagi and Joseph Bonneau.

Financial Crypto 2023

https://eprint.iacr.org/2023/221

Cornucopia: scale to millions of contributors with an untrusted coordinator!

Cornucopia: Distributed randomness beacons at scale

Miranda Christ, Kevin Choi, and Joseph Bonneau.

(in submission)

https://eprint.iacr.org/2023/1554

50 of 110

VDFs are a potential game-changer

  • The only way we know to get to a dishonest majority model
    • Without trusted hardware or economic assumptions

  • This is true for many other protocols beyond randomness!
    • Example: auctions, voting

51 of 110

Do we need a dishonest majority?

  • Consensus requires an honest majority...

  • But, attacks on randomness are invisible
    • Consensus attacks typically visible to the public

52 of 110

Delay functions enable participatory protocols

  • Every participant in a massive online game or lottery can contribute!
    • On-chain costs are constant

  • Observation: participants don’t care who else participates!
    • Only need to check that their own contribution is included
    • “The more the merrier”

53 of 110

Open questions

  • Can we make delay functions practical?

  • How do cryptographic DRBs fit with existing regulations and laws?

  • Will cryptographic DRBs be convincing to policy makers?

  • Will cryptographic DRBs be convincing to users?

54 of 110

Papers cited

SoK: Distributed Randomness Beacons.

Kevin Choi, Athira Manoj and Joseph Bonneau.

IEEE Security & Privacy (Oakland) 2023

https://eprint.iacr.org/2023/728

Bicorn: An optimistically efficient distributed randomness beacon

Kevin Choi, Arasu Arun, Nirvan Tyagi and Joseph Bonneau.

Financial Crypto 2023

https://eprint.iacr.org/2023/221

Cornucopia: Distributed randomness beacons at scale

Miranda Christ, Kevin Choi, and Joseph Bonneau.

(in submission)

https://eprint.iacr.org/2023/1554

55 of 110

Commit-reveal-delay (Bicorn) [CATB23]

As secure as Unicorn, but with a fast optimistic case!

  • Fast if all participants are honest

56 of 110

Commit-reveal-delay (Bicorn) [CATB23]

  1. Commit
    1. Using a variant of timed commitments

c3

c2

c1

57 of 110

Commit-reveal-delay (Bicorn) [CATB23]

  1. Commit
    1. Using a variant of timed commitments

  1. Reveal
    1. If all reveal, result immediately available

e3

e2

e1

Ω

58 of 110

Commit-reveal-delay (Bicorn) [CATB23]

  1. Commit
    1. Using a variant of timed commitments

  1. Reveal
    1. If all reveal, result immediately available

  1. Delay (pessimistic case)
    1. Force open any unopened commitments
    2. Homomorphism enables single delay computation
    3. Identical result to optimistic case (no bias possible)

c3

c2

c1

Ω

59 of 110

Cornucopia [CCB24]

As secure as Unicorn, but with a constant-size broadcast!

  • Using a semi-trusted coordinator

60 of 110

Cornucopia [CCB24]

N users

Public Bulletin Board

Coordinator

Contribution ri

Inclusion proof πi

Commitment R

Result Ω = Delay(R)

  • Verify ri ∊ R
  • Verify Ω = Delay(R)

Output Ω is guaranteed random if ri is random

... regardless of other participant’s actions!

Result Ω

61 of 110

Cornucopia [CCB24]

  • N users submit their contribution ri to coordinator

  • Coordinator accumulates all contributions
    • R = Accumulate(r1, r2, ... , rN)
    • Each user receives πi = ProveInclusion(R, rN)
  • Public random output Ω = Delay(R)
    • Any single party can compute this. Efficiently verified using a VDF

Security proven using a new accumulator property:

insertion security

62 of 110

Many combinations are possible

  • Punishments can be added to many protocols
    1. Discourage withholding attacks which harm efficiency

  • Tricky to combine parallel protocols
    • Last protocol can subvert others
    • Delay functions patch this!

  • Committee-based protocol can use any DRB as a subroutine

63 of 110

Slight improvement: better entropy combination

  • Poor choices: linear function
    • e.g. addition, xor
    • Attacker can choose any outcome
  • Better: hash function
    • Attacker must grind to find good outcome
  • Classic line of research: low-influence functions
    • last mover must have influence Ω(1/n)

e3

e2

e1

64 of 110

Committee DRB options

  1. Freshly generated entropy
    • Commit-reveal-recover variants
  2. Precommitted entropy
    • Randomness comes from unpredictability of committee

65 of 110

Unbiasability security game

Ω0

Ω1

Ωb

b=1

honest run

infiltrated run

Unbiasability: Attacker has negligible advantage guessing b

66 of 110

Expected attack costs for commit-reveal-punish

  • Attacker gains utility +U from event which occurs with probability p

  • Attacker expects (1/p - 1) aborts

  • Require a deposit d such that d > U(1-p)/p

Might be okay for low probability events

67 of 110

Approaches we won’t discuss in detail

  • Centralized beacons [e.g. NIST, random.org]
    • No verifiability whatsoever
  • Physical randomness
    • No cryptographic verifiability
  • “Implicit beacons” [e.g. stock market, blockchain data]
    • Unclear security guarantees
    • ... but commonly used in the early days of Ethereum! (block.blockhash)

68 of 110

Generalized security definition framework

  1. Unbiasability
    • Attackers participating in the protocol cannot produce distinguishable bias
  2. Liveness
    • Attackers participating in the protocol cannot prevent output (Ω=⟂)
  3. Unpredictability
    • Attackers cannot predict any property of the output (Ω=⟂)
      • Intra-unpredictability (within an epoch)
      • Inter-unpredictability (between epochs)

69 of 110

Public randomness: an ancient challenge

kleroterion, Ancient Greece dice, Ancient Rome

70 of 110

DRB design flow chart

commit-reveal (vulnerable)

Clear economic model?

commit-reveal-punish

Honest majority?

delay-based DRB

Static participant set?

pseudorandom DRB

Small participant set?

commit-reveal-recover

yes

no

yes

yes

71 of 110

Many additional practical considerations

  • Efficiency
    • Communication complexity
    • Verifier complexity
    • Delay computation requirements
  • Worst-case damage
    • Biasing vs. predictability
    • Recovery from faults
  • Ad hoc participation (re-keying costs)

72 of 110

Long-term goal: deploying DRBs outside of web3

Key challenge: explaining limits of physical randomness, benefits of DRBs

73 of 110

Many avenues for future work

  • Cryptographic
    • Improved single secret leader election (SSLE)
    • Develop definitions in UC framework
    • Prove adaptive security of (sub)protocols
    • Harness traditional crypto literature on randomness extractors
    • Prove fundamental limits on DRBs in each model
  • Engineering
    • Improve practicality of verifiable delay functions
  • Economics
    • Attacker costs with more complex attacker utility function
    • Security model for implicit beacons (asset prices, blockchain data)

74 of 110

Detailed comparison in SoK paper

SoK: Distributed Randomness Beacons.

Kevin Choi, Athira Manoj and Joseph Bonneau.

IEEE Security & Privacy (Oakland) 2023

https://eprint.iacr.org/2023/728

75 of 110

Important disclosures

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities, digital assets, tokens, and/or cryptocurrencies are for illustrative purposes only and do not constitute a recommendation to invest in any such instrument nor do such references constitute an offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

76 of 110

Strawman: Rock-Paper-Scissors

Ω = e1 + e2 + e3 (mod k)

Secure given any one honest participant... assuming perfect synchrony

e3

e2

e1

77 of 110

Manipulating Rock-Paper-Scissors with Δ>0

    • Last participant sets e3 = Ω* - e1 - e2
      • For desirable outcome Ω*

Ω* (forced beacon output)

e3

e2

e1

78 of 110

Public randomness: an ancient challenge

kleroterion, Ancient Greece dice, Ancient Rome

79 of 110

Verifiable Delay Functions [BBBF18]

  • Setup(t, λ) → pp

  • Eval(pp, x) → y, π

  • Verify(pp, x, y, π) → Y/N

V: efficient to verify

D: t-sequential to solve

F: unique output

API

Security goals

80 of 110

Timeline for a verifiable lottery

  1. Commit to lottery algorithm
  2. Open audit period
  3. Read random seed from beacon
  4. Run algorithm using seed
  5. Independent verification

for p in players:

p.rank = H(p, R)

sort(players)

for p in players:

p.rank = H(p, R)

sort(players)

+

81 of 110

Timeline for a verifiable lottery (take 2)

  1. Run lottery algorithm n times
  2. Open audit period
  3. Read random seed from beacon
  4. Select from precomputed outputs

for p in players:

p.rank = H(p, R)

sort(players)

+

Alice

Alice

Alice

Alice

Alice

82 of 110

Physical randomness can be faked

83 of 110

Physical randomness can fail

US conscription lottery, 1969

84 of 110

Physical randomness can fail

US conscription lottery, 1969

1. Load in order 2. Rotate axially 3. Draw from top

1

2

3

4

5

6

7

8

9

7

4

1

8

5

2

9

6

3

1

3

2

6

4

5

8

9

7

85 of 110

Physical randomness can fail

US conscription lottery, 1969

86 of 110

Commit-reveal: real-world example

  1. Put die under cup

87 of 110

Commit-reveal: real-world example

  1. Put die under cup
  2. Roll die under cup

88 of 110

Commit-reveal: real-world example

  1. Put die under cup
  2. Roll die under cup
  3. Lift cup

89 of 110

Commit-reveal: real-world example

  1. Put die under cup
  2. Roll die under cup
  3. Lift cup
  4. Combine die values

+ + =

(mod 6)

90 of 110

Beacons often implemented via authority

91 of 110

Committee-based DRBs

  1. Select Committee
    1. Deterministic/randomized
    2. Public/secret elections

92 of 110

Committee-based DRBs

  1. Select Committee
    1. Deterministic/randomized
    2. Public/secret elections

  1. Committee runs another DRB
    1. Typically commit-reveal-recover or pseudorandom
    2. May run for many epochs

c2 , PVSS(e2)

c1 , PVSS(e1)

c3, PVSS(e3)

Ω

93 of 110

Committee selection strategies

  1. Public
    • Round-robin
    • Leader-based selection
    • Random selection (use previous output Ωi-1)
  2. Private
    • E.g. verifiable random function (VRF)
    • Single secret-leader election (SSLE)

Better

adaptive security

94 of 110

Example committee-based DRBs

Freshly generated entropy

Precommitted entropy

Public selection

Private selection

Ouroboros [KRBO 17]

RandHound [SJKGGKFF 17]

SPURT [DVIR 21]

OptRand [BSKN 23]

HydRand [SJSW 20]

GRandPiper [BSKN 21]

Algorand [GHMVZ 17]

Variant of NV [NNLNNLN 19]

95 of 110

Pros/cons of committee-based DRBs

  • Pro
    1. Scalable costs with large numbers of participants
    2. Flexible/modular construction possible

  • Challenges
    • Committee selection is an extra risk
    • Adaptive security is challenging

Better SSLE would help

96 of 110

Observe: VDFs can patch many DRBs

  • Stock-market/asset prices
  • “Hash the blockchain”
  • Commit-reveal-punish
    • Including Ethereum’s RANDAO

97 of 110

DRB design flow chart

commit-reveal (vulnerable)

Clear economic model?

commit-reveal-punish

Honest majority?

delay-based DRB

Static participant set?

pseudorandom DRB

Small participant set?

commit-reveal-recover

committee-based DRB

yes

no

yes

yes

no

98 of 110

Commit-reveal-punish

  • Advantages
    • efficient
      • O(n) communication, compute
    • easily implemented

  • Cons
    • Requires capital lockup
    • Benign faults must be punished
    • Hard to bound attacker utility if beacons have multiple purposes

99 of 110

DRB design flow chart

commit-reveal (vulnerable)

Clear economic model?

commit-reveal-punish

Honest majority?

delay-based DRB

Static participant set?

pseudorandom DRB

Small participant set?

commit-reveal-recover

committee-based DRB

yes

no

yes

yes

no

100 of 110

Commit-reveal-recover

  1. Commit
    1. Publish ci = Commit(ei) as in classic CR
    2. Secret-share ei with all other nodes
      1. PVSS: Publicly verifiable secret sharing

  • Reveal
    1. Publish ei as in classic CR

e2

e1

e3

Ω

101 of 110

Commit-reveal-recover

  • Advantages
    • Flexible participation
    • Per-round entropy

  • Challenges
    • Relatively inefficient
      • O(n2) communication
    • Complex protocols
    • If t needed to compute, n-t can block liveness
    • Reconstruction causes extra overhead

102 of 110

Pseudorandom DRBs

  • Advantages
    • Efficient
      • O(n) communication, compute
    • Dishonest majority cannot manipulate
      • Can only predict or stall

  • Challenges
    • If t needed to compute, n-t can block liveness
    • Malicious coalition can predict infinitely far into the future
    • No recovery from compromise
      • Prudent to periodically re-key

103 of 110

Commit-reveal-recover

  • Commit
    • Publish ci = Commit(ei) as in classic CR
    • Secret-share ei with all other nodes
      • PVSS: Publicly verifiable secret sharing

c2 , PVSS(e2)

c1 , PVSS(e1)

c3, PVSS(e3)

104 of 110

Commit-reveal-recover

  • Commit
    • Publish ci = Commit(ei) as in classic CR
    • Secret-share ei with all other nodes
      • PVSS: Publicly verifiable secret sharing

  • Reveal
    • Publish ei as in classic CR

e2

e1

e3

Ω

105 of 110

Commit-reveal-recover

  • Commit
    • Publish ci = Commit(ei) as in classic CR
    • Secret-share ei with all other nodes
      • PVSS: Publicly verifiable secret sharing

  • Reveal
    • Publish ei as in classic CR
  • Recover
    • Honest participants reconstruct any missing ei

e2

e1

e3

PVSS.reconstruct()

Ω

106 of 110

Commit-reveal-recover variants

  • Better PVSS
    • SCRAPE [CD 17]

  • Amortized PVSS
    • HERB [CSO 19]
    • Albatross [CD 20]

  • Remove optimistic case (share-reconstruct-aggregate)
    • RandShare [SJKGGKFF 17]
    • SecRand [GSX 20]

107 of 110

Commit-reveal-recover

  • Advantages
    • Flexible participation
    • Per-round entropy

  • Challenges
    • Relatively inefficient
      • O(n2) communication
    • Complex protocols
    • If t needed to compute, n-t can block liveness
    • Reconstruction causes extra overhead

108 of 110

DRB design flow chart

commit-reveal (vulnerable)

Clear economic model?

commit-reveal-punish

Honest majority?

delay-based DRB

Static participant set?

pseudorandom DRB

Small participant set?

commit-reveal-recover

committee-based DRB

yes

no

yes

yes

no

109 of 110

Delay-based DRBs

  • Advantages
    • Secure under dishonest majority
    • Efficient
      • O(n) communication, compute. Can be reduced w/leader
    • Flexible participation
    • Per-round entropy
    • Guaranteed output delivery

110 of 110

Delay-based DRBs

  • Advantages
    • Secure under dishonest majority
    • Efficient
      • O(n) communication, compute. Can be reduced w/leader
    • Flexible participation
    • Per-round entropy
    • Guaranteed output delivery

  • Challenges
    • Delay functions induce latency
    • Some party must compute the delay function
      • a public good?
    • Relatively new cryptographic assumptions
    • Intra-predictability: attacker with faster VDF may learn outcome early