breeding unicorns: developing trustworthy and scalable ... · breeding unicorns: developing...
TRANSCRIPT
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-