Breeding Unicorns: Developing Trustworthy and Scalable Randomness - - PowerPoint PPT Presentation

Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons

Samvid Dharanikota, Michael Jensen, Sebastian Kristensen, Mathias Michno, Yvonne-Anne Pignolet, Rene Hansen, Stefan Schmid

@csunivie

• In alg

lgori rithm design:

• Faster algorithms through randomization
• Symmetry breaking in distributed algorithms
• Secure cryptographic protocols based on random seeds (e.g., elliptic curves)
• In entertainment:
• Lotter

eries es, game mes (Roulette)

• Drafts in sports
• In politics:
• Military drafts

ts, assignment of kids to schools

• Block
• ckch

chain: more soon

2

Randomness: An Important Tool of Our (Digital) Society

IEEE Blockchain, Atlanta, USA

• In alg

lgori rithm design:

• Faster algorithms through randomization
• Symmetry breaking in distributed algorithms
• Secure cryptographic protocols based on random seeds (e.g., elliptic curves)
• In entertainment:
• Lotter

eries es, game mes (Roulette)

• Drafts in sports
• In politics:
• Military drafts

ts, assignment of kids to schools

• Block
• ckch

chain: more soon

3

Randomness: An Important Tool of Our (Digital) Society

IEEE Blockchain, Atlanta, USA

Can be solved by producing randomness locally myself (e.g., /dev/urandom, using quantum photonics, etc.)

• In alg

lgori rithm design:

• Faster algorithms through randomization
• Symmetry breaking in distributed algorithms
• Secure cryptographic protocols based on random seeds (e.g., elliptic curves)
• In entertainment:
• Lotter

eries es, game mes (Roulette)

• Drafts in sports
• In politics:
• Military drafts

ts, assignment of kids to schools

• Block
• ckch

chain: more soon

4

Randomness: An Important Tool of Our (Digital) Society

IEEE Blockchain, Atlanta, USA

Requires randomness that is trustworthy for everybody! Output of „shared randomness“ is relevant to multiple stakeholders.

• In alg

lgori rithm design:

• Faster algorithms through randomization
• Symmetry breaking in distributed algorithms
• Secure cryptographic protocols based on random seeds (e.g., elliptic curves)
• In entertainment:
• Lotter

eries es, game mes (Roulette)

• Drafts in sports
• In politics:
• Military drafts

ts, assignment of kids to schools

• Block
• ckch

chain: more soon

5

Randomness: An Important Tool of Our (Digital) Society

IEEE Blockchain, Atlanta, USA

Requires randomness that is trustworthy for everybody! Output of „shared randomness“ is relevant to multiple stakeholders.

• Vision: service emitting unpr

predi dictable random

• m

values es …

• Public:

: seen by „everybody“

IEEE Blockchain, Atlanta, USA 6

Vision: Randomness Beacon

• Vision: service emitting unpr

predi dictable random

• m

values es …

• Public:

: seen by „everybody“

• Introduced by Mich

chael O

• O. Rabi

bin in 1983

IEEE Blockchain, Atlanta, USA 7

Vision: Randomness Beacon

• When group of users need to agree on some random value but do not
• t trust

st each ch ot

• ther
• E.g.:
• Lotteries
• Secure electio

tions

• Prevent selfish

shmini ning ng

• Blockchain/distributed systems‘ conse

sensu sus mechanisms

• Overcoming slow bootstrapping in zero-knowledge proofs
• Rabin‘s example: providing security

ity to toe-ma mail based protocols with thmin inimal trust st

8

When Are Randomness Beacons Useful?

IEEE Blockchain, Atlanta, USA

• When group of users need to agree on some random value but do not
• t trust

st each ch ot

• ther
• E.g.:
• Lotteries
• Secure electio

tions

• Prevent selfish

shmini ning ng

• Blockchain/distributed systems‘ conse

sensu sus mechanisms

• Overcoming slow bootstrapping in zero-knowledge proofs
• Rabin‘s example: providing security

ity to toe-ma mail based protocols with thmin inimal trust st

9

When Are Randomness Beacons Useful?

IEEE Blockchain, Atlanta, USA

• E.g.: NIST‘s randomness beacon
• One new value per minute

10

Available today?!

IEEE Blockchain, Atlanta, USA

• E.g.: NIST‘s randomness beacon
• One new value per minute

11

Available today?!

IEEE Blockchain, Atlanta, USA

Trustworthy?

12

Trustworthy?

IEEE Blockchain, Atlanta, USA

13

Trustworthy?

IEEE Blockchain, Atlanta, USA

How to do better? Design choices and tradeoffs!

• Private

e so source ce: e.g., NIST beacon

• Potentially hi

high h qu quality and nd hi high r h rate randomness

• But denies user access to inspect generation process
• Requires trust: not
• t ok
• k
• Publ

blicl cly av avai ailab able data: financial data, bitcoin block hashes, lottery data, weather (?)

• Nice idea, bu

but: sufficiently random? Rate?

• Use

User r input ut: outsource to the users, i.e., locally generated randomness

• Users responsible to provide input!

14

Design Choice 1: Input Sources

IEEE Blockchain, Atlanta, USA

• Private

e so source ce: e.g., NIST beacon

• Potentially hi

high h qu quality and nd hi high r h rate randomness

• But denies user access to inspect generation process
• Requires trust: not
• t ok
• k
• Publ

blicl cly av avai ailab able data: financial data, bitcoin block hashes, lottery data, weather (?)

• Nice idea, bu

but: sufficiently random? Rate?

• Use

User r input ut: outsource to the users, i.e., locally generated randomness

• Users responsible to provide input!

15

Design Choice 1: Input Sources

IEEE Blockchain, Atlanta, USA

How random should it be? As random as they ey n need eed!

• Autoc
• cratic c

col

• llector: e.g. run by a third party
• Computation is blackbox, no p
• proo
• of of
• f hon
• nesty
• Specialized M

Multi-Pa Party Com

• mputation
• n (

(MPC): collectively produce randomness

• … typically from their own inputs
• Despite significant work in the field, this approach is difficu

cult t to

• sca

cale

• Addi

ddition or rem emoval of a f a u user er requires a new setup phase

• But might fit in a controlled private context
• Trans

nsparent nt author

• rity model

el: single entity collects inputs and publishes them

• Focus on trans

nsparenc ncy: users can observe and verify the beacon

16

Design Choice 2: Beacon Operator

IEEE Blockchain, Atlanta, USA

• Autoc
• cratic c

col

• llector: e.g. run by a third party
• Computation is blackbox, no p
• proo
• of of
• f hon
• nesty
• Specialized M

Multi-Pa Party Com

• mputation
• n (

(MPC): collectively produce randomness

• … typically from their own inputs
• Despite significant work in the field, this approach is difficu

cult t to

• sca

cale

• Addi

ddition or rem emoval of a f a u user er requires a new setup phase

• But might fit in a controlled private context
• Trans

nsparent nt author

• rity model

el: single entity collects inputs and publishes them

• Focus on trans

nsparenc ncy: users can observe and verify the beacon

17

Design Choice 2: Beacon Operator

IEEE Blockchain, Atlanta, USA

Byzantine behavior possible, but dif iffic icult to

• hi

hide!

• A randomness beacon requiring mi

minima mal t trust

• Based on the trans

nspa parent nt auth thority ty model which relies on user ser inpu nput

• Beacon operator has no private

te i informatio tion

• Allows users to
• Joi
• in any t

ny time and at low overhead

• Make subtle decisions on when to

to tr trust the output

• Practical:
• Prototype demonstrates scalability

ity of our approach

• Beacon can be deployed on distributed ledg

dger platforms

18

Our Contributions

IEEE Blockchain, Atlanta, USA

• No private information: all inp

nputs a are hashed ed a and rel elea eased to to th the p public in batches before the computation

• Uses commi

mmitme ments and ver verifiable le del elay function

• n to ensure that the operator canno

nnot tr try mor

• re tha

han

• n
• ne commi

mmitment before running out of time

• The beacon protocol also lets use

sers ver verify:

• in

inclusio ion of

• f the

heir inp nput in the randomness generation (by commi mmitting to user inputs before starting the computation)

• corre

rrect ca calcu culati tion of the random value from the provided inputs

• Several practic

ical o

• ptimiz

izatio ions (e.g., for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain, Atlanta, USA

20

A Deeper Dive

IEEE Blockchain, Atlanta, USA

• To

To suppor

• rt „choos
• sable“

“ rando ndomness: : a user‘s input rate is not limited (except for DoS)

• To

To increase se secu curity:

• Fast a

and t trans nspa parent nt publishi hing: : input, output, and any data needed for verification needs to be published as soon as possible

• “Dete

terminis istic tic”: ”: any party can compute the randomness alongside the beacon operator

• Op

Open: anyone can contribute to the beacon to influence random generation

• For
• r scalabil

ility: : different channels for input and output

21

A Deeper Dive

IEEE Blockchain, Atlanta, USA

• To

To suppor

• rt „choos
• sable“

“ rando ndomness: : a user‘s input rate is not limited (except for DoS)

• To

To increase se secu curity:

• Fast a

and t trans nspa parent nt publishi hing: : input, output, and any data needed for verification needs to be published as soon as possible

• “Dete

terminis istic tic”: ”: any party can compute the randomness alongside the beacon operator

• Op

Open: anyone can contribute to the beacon to influence random generation

• For
• r scalabil

ility: : different channels for input and output

• Inherently seq

equen ential func nctions ns that require a given amount of time to run

• No benefit from parallel execution
• E.g., slot
• th, but also others
• Idea:
• Cannot compute the delay function in the time between the users‘ input and the receiving the

beacon’s commitment to the input:

tCOMMITMENT − tINPUT < TDELAYFUNCTION

• Operator cannot try more than one commitment before running out of time
• But while hard to compute, easy

sy to to ver verify! E.g., seq equen ential ha hashi hing.

22

Delay Function

IEEE Blockchain, Atlanta, USA

• Inherently seq

equen ential func nctions ns that require a given amount of time to run

• No benefit from parallel execution
• E.g., slot
• th, but also others
• Idea:
• Cannot compute the delay function in the time between the users‘ input and the receiving the

beacon’s commitment to the input:

tCOMMITMENT − tINPUT < TDELAYFUNCTION

• Operator cannot try more than one commitment before running out of time
• But while hard to compute, easy

sy to to ver verify! E.g., seq equen ential ha hashi hing.

23

Delay Function

IEEE Blockchain, Atlanta, USA

User can choose threshold

• Inherently seq

equen ential func nctions ns that require a given amount of time to run

• No benefit from parallel execution
• E.g., slot
• th, but also others
• Idea:
• Cannot compute the delay function in the time between the users‘ input and the receiving the

beacon’s commitment to the input:

tCOMMITMENT − tINPUT < TDELAYFUNCTION

• Operator cannot try more than one commitment before running out of time
• But while hard to compute, easy

sy to to ver verify! E.g., seq equen ential ha hashi hing.

24

Delay Function

IEEE Blockchain, Atlanta, USA

User can choose threshold

Prevents in input m manip ipulatio ion and last st- draw aw at attac acks.

• During the input collection phase, users

independently submit inputs to the beacon

• These inputs are aggregated into a Mer

erkle le Tree ee: the root is inp nput to to the he com

• mputation
• n pha

hase

• This can also be used as commitment data that allows

for ef efficien ent ver verification of

• f incl

clusi sion of

• f a

a use ser‘s inp nput in logarithmic time

26

Combining Inputs

IEEE Blockchain, Atlanta, USA Hash 00 Hash 01 Hash 10 Hash 11 Hash 0 Hash 1

Top Hash

• Beacon operation: inp

nput col

• llection
• npha

hase followed by com

• mputation
• n pha

hase

• But: computation (delay function) takes much time, where users canno

nnot su subm bmit inp nput

• Solution: parallel beacon operation
• Several delay functions run

un in n paralle llel, but offs ffset in time and on different input

27

Pipelining

IEEE Blockchain, Atlanta, USA

• Based on Python and ZeroMQ
• Two proxies:
• For
• rward prox
• xy between computation and publishers (forwards outputs, commitments, and

proofs)

• Stream

m pr proxy xy situated between input collectors and input processors

• Publicly available at: https://github:com/randomchain/randbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain, Atlanta, USA

Stream m prox

• xy (bottleneck) can

handle 1000s of msg/sec

29

Evaluation

IEEE Blockchain, Atlanta, USA

Building Me Merkle tree ee is fairly fast Slot

• th computation time

for different parameters Hi High asymm mmetry: computation time vs verification time

• Lotte

ttery: : the random value determines a winner randomly from the participants

• Tradeo

eoffs how much of the beacon is on

• n-cha

hain (as a smart contract) and how much is of

• ff-cha

hain

• 3 players:
• Ow

Owner - Runs the lottery (e.g. smart contract owner)

• User

ser - Takes part in the lottery by sending a small payment to the lottery smart contract

• Beacon
• n - Beacon operator that provides a random value / lucky winner
• Goal of lot
• ttery ow
• wner: shave off some of the users’ participation payments as a rew

eward

• Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation, e.g.: Lottery Application

IEEE Blockchain, Atlanta, USA

35

Lottery: Implementation Options

IEEE Blockchain, Atlanta, USA

36

Lottery: Implementation Options

IEEE Blockchain, Atlanta, USA

Maximum Offchain All beacon-related logic is of

• ff-cha

hain: only the lottery logic is on- chain:

• The users send

nd in input uts to the beacon off-chain and ob

• btain

commi mmitme ment off-chain

• Thereafter they sen

end t the e lotter ery p paymen ent to the smart contract

• When the off-chain beacon value computation has finished,

the lottery smart contract fet fetches the he v value and determines the winne nner

• Users can verify

fy if the beacon matches the commitment and complain off-chain and decide not to trust this beacon in the future.

37

Lottery: Implementation Options

IEEE Blockchain, Atlanta, USA

ITV Adding beacon incentive and on-chain commitment (ITV): Compensated beacon operator with the smart contract

• The beacon publishes its public key and a nonce and loc
• cks

so some f funds s in the smart contract

• The beacon los
• ses its locked funds if

if verific icatio ion f fail ils.

• If the verification succeeds, the owner, beacon and winner

recei eive r e rewards.

• The verification of the correct execution of sloth on the Merkle

root is performed on-chain

38

Ethereum Smart Contract and Gas Cost

IEEE Blockchain, Atlanta, USA

• Implemented an Et

Ethereum smart contract

• Figure shows the gas co

s cost sts s for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

• As expected, line

near incr crease se of the gas cost

• Design and implementation of a randomness beacon
• Transparent and open: no trust needed
• Beacon output can be publicly verified
• Performance study, also of the sloth protocol
• Lottery case study: realization tradeoffs
• Much futur

ure wor

• rk! E.g., while nobody can bias the output, some parties may still know outcome a

bit earlier than others.

39

Conclusions

IEEE Blockchain, Atlanta, USA

40

• Thanks. Questions?