35
Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons Samvid Dharanikota, Michael Jensen, Sebastian Kristensen, Mathias Michno, Yvonne-Anne Pignolet, Rene Hansen, Stefan Schmid @csunivie

Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

  • Upload
    others

  • View
    8

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

Breeding Unicorns Developing Trustworthy andScalable Randomness BeaconsSamvid Dharanikota Michael Jensen Sebastian Kristensen Mathias Michno Yvonne-Anne Pignolet Rene Hansen Stefan Schmid

csunivie

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

2

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

3

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Can be solved byproducing

randomness locallymyself

(eg devurandom using quantum

photonics etc)

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

4

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

5

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

IEEE Blockchain Atlanta USA 6

Vision Randomness Beacon

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

bull Introduced by Michael O Rabin in 1983

IEEE Blockchain Atlanta USA 7

Vision Randomness Beacon

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

8

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 2: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

2

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

3

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Can be solved byproducing

randomness locallymyself

(eg devurandom using quantum

photonics etc)

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

4

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

5

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

IEEE Blockchain Atlanta USA 6

Vision Randomness Beacon

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

bull Introduced by Michael O Rabin in 1983

IEEE Blockchain Atlanta USA 7

Vision Randomness Beacon

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

8

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 3: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

3

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Can be solved byproducing

randomness locallymyself

(eg devurandom using quantum

photonics etc)

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

4

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

5

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

IEEE Blockchain Atlanta USA 6

Vision Randomness Beacon

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

bull Introduced by Michael O Rabin in 1983

IEEE Blockchain Atlanta USA 7

Vision Randomness Beacon

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

8

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 4: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

4

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

5

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

IEEE Blockchain Atlanta USA 6

Vision Randomness Beacon

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

bull Introduced by Michael O Rabin in 1983

IEEE Blockchain Atlanta USA 7

Vision Randomness Beacon

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

8

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 5: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull In algorithm design

bull Faster algorithms through randomization

bull Symmetry breaking in distributed algorithms

bull Secure cryptographic protocols based on random seeds (eg elliptic curves)

bull In entertainment

bull Lotteries games (Roulette)

bull Drafts in sports

bull In politics

bull Military drafts assignment of kids to schools

bull Blockchain more soon

5

Randomness An Important Tool of Our (Digital) Society

IEEE Blockchain Atlanta USA

Requires randomness thatis trustworthy for everybody Output ofbdquoshared randomnessldquo isrelevant to multiple

stakeholders

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

IEEE Blockchain Atlanta USA 6

Vision Randomness Beacon

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

bull Introduced by Michael O Rabin in 1983

IEEE Blockchain Atlanta USA 7

Vision Randomness Beacon

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

8

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 6: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

IEEE Blockchain Atlanta USA 6

Vision Randomness Beacon

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

bull Introduced by Michael O Rabin in 1983

IEEE Blockchain Atlanta USA 7

Vision Randomness Beacon

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

8

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 7: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Vision service emitting unpredictable randomvalues hellip

bull Public seen by bdquoeverybodyldquo

bull Introduced by Michael O Rabin in 1983

IEEE Blockchain Atlanta USA 7

Vision Randomness Beacon

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

8

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 8: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

8

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 9: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull When group of users need to agree on some random value but do not trust each otherbull Eg

bull Lotteries

bull Secure elections

bull Prevent selfish mining

bull Blockchaindistributed systemslsquo consensus mechanisms

bull Overcoming slow bootstrapping in zero-knowledge proofs

bull Rabinlsquos example providing security to e-mail based protocols with minimal trust

9

When Are Randomness Beacons Useful

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 10: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Eg NISTlsquos randomness beacon

bull One new value per minute

10

Available today

IEEE Blockchain Atlanta USA

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 11: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Eg NISTlsquos randomness beacon

bull 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

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 12: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

12

Trustworthy

IEEE Blockchain Atlanta USA

13

Trustworthy

IEEE Blockchain Atlanta USA

How to do better Design choices and tradeoffs

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 13: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

13

Trustworthy

IEEE Blockchain Atlanta USA

How to do better Design choices and tradeoffs

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 14: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

14

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 15: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Private source eg NIST beacon

bull Potentially high quality and high rate randomness

bull But denies user access to inspect generation process

bull Requires trust not okbull Publicly available data financial data bitcoin block hashes lottery data weather ()

bull Nice idea but sufficiently random Rate

bull User input outsource to the users ie locally generated randomness

bull Users responsible to provide input

15

Design Choice 1 Input Sources

IEEE Blockchain Atlanta USA

How random should it beAs random as they need

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 16: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

16

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 17: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Autocratic collector eg run by a third party bull Computation is blackbox no proof of honesty

bull Specialized Multi-Party Computation (MPC) collectively produce randomnessbull hellip typically from their own inputs

bull Despite significant work in the field this approach is difficult to scale

bull Addition or removal of a user requires a new setup phase

bull But might fit in a controlled private context

bull Transparent authority model single entity collects inputs and publishes them bull Focus on transparency users can observe and verify the beacon

17

Design Choice 2 Beacon Operator

IEEE Blockchain Atlanta USA

Byzantine behavior possible but difficult to hide

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 18: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull A randomness beacon requiring minimal trustbull Based on the transparent authority model which relies on user input

bull Beacon operator has no private information

bull Allows users to bull Join any time and at low overhead

bull Make subtle decisions on when to trust the output

bull Practical bull Prototype demonstrates scalability of our approach

bull Beacon can be deployed on distributed ledger platforms

18

Our Contributions

IEEE Blockchain Atlanta USA

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 19: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull No private information all inputs are hashed and released to the public in batches before the computation

bull Uses commitments and verifiable delay function to ensure that the operator cannot try more thanone commitment before running out of time

bull The beacon protocol also lets users verify

bull inclusion of their input in the randomness generation (by committing to user inputs beforestarting the computation)

bull correct calculation of the random value from the provided inputs

bull Several practical optimizations (eg for scalability)

19

Our Approach in a Nutshell

IEEE Blockchain Atlanta USA

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 20: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

20

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 21: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

21

A Deeper Dive

IEEE Blockchain Atlanta USA

bull To support bdquochoosableldquo randomness a userlsquos input rate is not limited (except for DoS)

bull To increase security

bull Fast and transparent publishing input output and any data needed for verification needs to be published as soon as possible

bull ldquoDeterministicrdquo any party can compute the randomness alongside the beacon operator

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

bull For scalability different channels for input and output

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 22: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

22

Delay Function

IEEE Blockchain Atlanta USA

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 23: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

23

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 24: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Inherently sequential functions that require a given amount of time to run

bull No benefit from parallel execution

bull Eg sloth but also others

bull Idea

bull Cannot compute the delay function in the time between the userslsquo input and the receiving thebeaconrsquos commitment to the input

tCOMMITMENT minus tINPUT lt TDELAYFUNCTION

bull Operator cannot try more than one commitment before running out of time

bull But while hard to compute easy to verify Eg sequential hashing

24

Delay Function

IEEE Blockchain Atlanta USA

User can choosethreshold

Prevents input manipulation and last-draw attacks

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 25: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull During the input collection phase usersindependently submit inputs to the beacon

bull These inputs are aggregated into a Merkle Tree theroot is input to the computation phase

bull This can also be used as commitment data that allowsfor efficient verification of inclusion of a userlsquos input in logarithmic time

26

Combining Inputs

IEEE Blockchain Atlanta USA

Hash 00 Hash 01 Hash 10 Hash 11

Hash 0 Hash 1

Top Hash

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 26: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Beacon operation input collection phase followed by computation phasebull But computation (delay function) takes much time where users cannot submit inputbull Solution parallel beacon operation

bull Several delay functions run in parallel but offset in time and on different input

27

Pipelining

IEEE Blockchain Atlanta USA

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 27: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Based on Python and ZeroMQ

bull Two proxies

bull Forward proxy between computation and publishers (forwards outputs commitments and proofs)

bull Stream proxy situated between input collectors and input processors

bull Publicly available at httpsgithubcomrandomchainrandbeacon

28

Proof-of-Concept Implementation

IEEE Blockchain Atlanta USA

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 28: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

Stream proxy (bottleneck) canhandle 1000s of msgsec

29

Evaluation

IEEE Blockchain Atlanta USA

Building Merkle tree isfairly fast

Sloth computation time for different parameters

High asymmetry computation time vsverification time

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 29: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Lottery the random value determines a winner randomly from the participants

bull Tradeoffs how much of the beacon is on-chain (as a smart contract) and how much is off-chainbull 3 players

bull Owner - Runs the lottery (eg smart contract owner)

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

bull Beacon - Beacon operator that provides a random value lucky winner

bull Goal of lottery owner shave off some of the usersrsquo participation payments as a rewardbull Users only participate if they trust random value provided by the beacon

34

Distributed Ledger Implementation eg 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 off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 30: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

35

Lottery Implementation Options

IEEE Blockchain Atlanta USA

36

Lottery Implementation Options

IEEE Blockchain Atlanta USA

Maximum Offchain

All beacon-related logic is off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 31: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

36

Lottery Implementation Options

IEEE Blockchain Atlanta USA

Maximum Offchain

All beacon-related logic is off-chain only the lottery logic is on-chainbull The users send inputs to the beacon off-chain and obtain

commitment off-chainbull Thereafter they send the lottery payment to the smart

contractbull When the off-chain beacon value computation has finished

the lottery smart contract fetches the value and determines the winner

bull Users can verify 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 contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 32: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

37

Lottery Implementation Options

IEEE Blockchain Atlanta USA

ITV

Adding beacon incentive and on-chain commitment (ITV) Compensated beacon operator with the smart contractbull The beacon publishes its public key and a nonce and locks

some funds in the smart contractbull The beacon loses its locked funds if verification fails bull If the verification succeeds the owner beacon and winner

receive rewardsbull 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

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 33: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

38

Ethereum Smart Contract and Gas Cost

IEEE Blockchain Atlanta USA

bull Implemented an Ethereum smart contract

bull Figure shows the gas costs for fetching the value from the beacon and drawing a winner for different number of users for the OFF model

bull As expected linear increase of the gas cost

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 34: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

bull Design and implementation of a randomness beacon

bull Transparent and open no trust needed

bull Beacon output can be publicly verified

bull Performance study also of the sloth protocol

bull Lottery case study realization tradeoffs

bull Much future work Eg 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

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40
Page 35: Breeding Unicorns: Developing Trustworthy and Scalable ... · Breeding Unicorns: Developing Trustworthy and Scalable Randomness Beacons. Samvid Dharanikota, Michael Jensen , Sebastian

40

Thanks Questions

  • Slide Number 1
  • Slide Number 2
  • Slide Number 3
  • Slide Number 4
  • Slide Number 5
  • Slide Number 6
  • Slide Number 7
  • Slide Number 8
  • Slide Number 9
  • Slide Number 10
  • Slide Number 11
  • Slide Number 12
  • Slide Number 13
  • Slide Number 14
  • Slide Number 15
  • Slide Number 16
  • Slide Number 17
  • Slide Number 18
  • Slide Number 19
  • Slide Number 20
  • Slide Number 21
  • Slide Number 22
  • Slide Number 23
  • Slide Number 24
  • Slide Number 26
  • Slide Number 27
  • Slide Number 28
  • Slide Number 29
  • Slide Number 34
  • Slide Number 35
  • Slide Number 36
  • Slide Number 37
  • Slide Number 38
  • Slide Number 39
  • Slide Number 40