O UROBOROS P RAOS : A N ADAPTIVELY - SECURE , SEMI - SYNCHRONOUS - - PowerPoint PPT Presentation

▶
o uroboros p raos
SMART_READER_LITE
LIVE PREVIEW

O UROBOROS P RAOS : A N ADAPTIVELY - SECURE , SEMI - SYNCHRONOUS - - PowerPoint PPT Presentation

Nov 10, 2023 248 likes •872 views

O UROBOROS P RAOS : A N ADAPTIVELY - SECURE , SEMI - SYNCHRONOUS PROOF - OF - STAKE BLOCKCHAIN Bernardo David Peter Gai Aggelos Kiayias Alexander Russell Tokyo Tech IOHK U. Edinburgh U. Connecticut & IOHK & IOHK Eurocrypt 2018

slide-1
SLIDE 1

Peter Gaži IOHK

OUROBOROS PRAOS:

AN ADAPTIVELY-SECURE, SEMI-SYNCHRONOUS

PROOF-OF-STAKE BLOCKCHAIN

Eurocrypt 2018

Aggelos Kiayias

  • U. Edinburgh

& IOHK Bernardo David Tokyo Tech & IOHK Alexander Russell

  • U. Connecticut
slide-2
SLIDE 2

Roadmap

  • Proof-of-work vs. Proof-of-stake blockchains
  • Ouroboros Praos
  • Protocol Description
  • Security Analysis
slide-3
SLIDE 3

The problem Bitcoin solves

  • Allows a collection of parties to agree on a dynamic, common

sequence of transactions—a ledger.

  • persistence: past transactions in ledger are immutable
  • liveness: new transactions are eventually included
  • parties may arise and disappear
  • some parties may seek to disrupt the system
slide-4
SLIDE 4

Bitcoin as a leader election process, proof of work

  • parties compete for the right to extend
  • winning certificate: PoW solution
  • Pr[success] proportional to computing power

?

…………….

slide-5
SLIDE 5

Bitcoin: Laudatory remarks

  • Simple
  • neatly solves a challenge: consensus with a fluid

population of participants

  • Sidesteps previous impossibility results
  • thanks to a new assumption (honest majority of
  • comp. power)
  • Amenable to formal analysis
  • [GKL15,PSS17,BMTZ17]
slide-6
SLIDE 6

Bitcoin: Criticism

  • relies on an ongoing computational race
  • power consumption estimates:
  • on the order of GWs
  • almost tripled over the last 6 months
  • Attack cost proportional to the energy spent in the

attack period.

slide-7
SLIDE 7

Challenge: Replace “proof-of-work” with alternate resource lottery

  • other physical resources, with different properties
  • disk space
  • useful computation/storage
  • ...
  • virtual resource: coin itself

⇒ Proof of Stake

slide-8
SLIDE 8

Proof of Stake: stake-based lottery

  • blockchain tracks ownership of coins among parties
  • Idea: participants elected proportionally to stake

⇒ no need for physical resources

  • hard to implement securely
slide-9
SLIDE 9

Previous proof-of-stake solutions with rigorous guarantees

Eventual (Nakamoto-style) Consensus:

  • Ouroboros [KRDO16]
  • Snow White [DPS16]

Blockwise Byzantine Agreement:

  • Algorand [CM16]
slide-10
SLIDE 10

Ouroboros

Provably guarantees

  • persistence: stable transactions are immutable
  • liveness: new transactions included eventually
slide-11
SLIDE 11

Ouroboros

Provably guarantees

  • persistence: stable transactions are immutable
  • liveness: new transactions included eventually

if

  • adversary has minority stake throughout
  • adversary subject to corruption delay
  • communication is synchronous
slide-12
SLIDE 12

Ouroboros Praos

Provably guarantees

  • persistence: stable transactions are immutable
  • liveness: new transactions included eventually

if

  • adversary has minority stake throughout
  • adversary subject to corruption delay
  • communication is synchronous
slide-13
SLIDE 13

Ouroboros Praos in a Nutshell

First eventual-consensus PoS secure

  • in a semi-synchronous communication model
  • despite fully adaptive corruptions

via

  • local, private leader selection
  • forward-secure signatures
  • blockchain hashing for randomness (scalability!)
slide-14
SLIDE 14

Ouroboros Praos: Protocol Description

slide-15
SLIDE 15

Communication Model

  • assume synchronized clocks
  • time divided into slots
  • honest messages may be adversarially delayed by at

most slots

  • is unknown to the protocol
  • adversary may send arbitrary messages to arbitrary

subsets, arriving at arbitrary times

slide-16
SLIDE 16

Ouroboros Praos: Protocol overview

  • time divided into consecutive, disjoint slots
slide-17
SLIDE 17

Ouroboros Praos: Protocol overview

  • time divided into consecutive, disjoint slots
  • at most 1 block per slot allowed
slide-18
SLIDE 18
  • time divided into consecutive, disjoint slots
  • epoch: sequence of R slots

Ouroboros Praos: Protocol overview

slide-19
SLIDE 19
  • time divided into consecutive, disjoint slots
  • epoch: sequence of R slots
  • slot leader: a player allowed to create block in that slot
  • selected proportionally to his/her stake

Ouroboros Praos: Protocol overview

slide-20
SLIDE 20
  • time divided into consecutive, disjoint slots
  • epoch: sequence of R slots
  • slot leader: a player allowed to create block in that slot
  • selected proportionally to his/her stake
  • independent for each slot and each player
  • => empty slots, multi-leader slots

Ouroboros Praos: Protocol overview

slide-21
SLIDE 21
  • time divided into consecutive, disjoint slots
  • epoch: sequence of R slots
  • slot leader: a player allowed to create block in that slot
  • selected proportionally to his/her stake
  • independent for each slot and each player
  • => empty slots, multi-leader slots

Ouroboros Praos: Protocol overview

slide-22
SLIDE 22
  • time divided into consecutive, disjoint slots
  • epoch: sequence of R slots
  • slot leader: a player allowed to create block in that slot
  • stake distribution: snapshot from last block 2 epochs ago

Ouroboros Praos: Protocol overview

slide-23
SLIDE 23
  • time divided into consecutive, disjoint slots
  • epoch: sequence of R slots
  • slot leader: a player allowed to create block in that slot
  • stake distribution: snapshot from last block 2 epochs ago
  • randomness: hash of values in prefix of previous epoch

H(.)

Ouroboros Praos: Protocol overview

slide-24
SLIDE 24

Hashing for epoch randomness

Verifiable Random Functions:

  • Evaluatesk(input) = (output, proof)
  • Verifypk(input, output, proof) = 0/1

H(.)

unique, pseudorandom

slide-25
SLIDE 25

Hashing for epoch randomness

Verifiable Random Functions:

  • Evaluatesk(input) = (output, proof)
  • Verifypk(input, output, proof) = 0/1
  • every leader inserts a separate VRF (value,proof)

into block

Txs H(prev) Slot # sigLi( )

VRF proof

VRF output

H(.)

slide-26
SLIDE 26

Hashing for epoch randomness

Verifiable Random Functions:

  • Evaluatesk(input) = (output, proof)
  • Verifypk(input, output, proof) = 0/1
  • every leader inserts a separate VRF (value,proof)

into block

  • hash of VRF values from initial ⅔ of epoch give

randomness for the whole next epoch

Txs H(prev) Slot # sigLi( )

VRF output

VRF proof

H( || ||...)

slide-27
SLIDE 27

Single-epoch setting

Focus on one epoch of length R

  • static stake distribution
  • ideal randomness
slide-28
SLIDE 28

Leader selection: local, private

Verifiable Random Functions:

  • Evaluatesk(input) = (output, proof)
  • Verifypk(input, output, proof) = 0/1

Leader selection lottery for stakeholder Ui: Evaluatesk(rnd,slot) < (stakei)

(output,proof) included in the block

slide-29
SLIDE 29

Verifiable Random Functions:

  • Evaluatesk(input) = (output, proof)
  • Verifypk(input, output, proof) = 0/1

Leader selection lottery for stakeholder Ui: Evaluatesk(rnd,slot) < (stakei)

  • similar idea previously in NXT, Algorand
  • needs unpredictability under malicious key generation
  • UC-functionality + efficient realization from CDH+RO

Leader selection: local, private

slide-30
SLIDE 30

Leader selection: local, private

Verifiable Random Functions:

  • Evaluatesk(input) = (output, proof)
  • Verifypk(input, output, proof) = 0/1

Leader selection lottery for stakeholder Ui: Evaluatesk(rnd,slot) < (stakei)

  • similar idea previously in NXT, Algorand
  • needs unpredictability under malicious key generation
  • UC-functionality + efficient realization from CDH+RO
slide-31
SLIDE 31

Leader selection: choice of (.)

α∊[0,1] f ∊[0,1]

  • ratio of non-empty slots f is a protocol parameter
  • slightly sublinear growth
  • maintains “independent aggregation”
slide-32
SLIDE 32

Block signing: Key-evolving signatures

KES are signature schemes, where:

  • pk remains the same
  • sk updated in every step, old sk erased
  • impossible to forge old signatures with

new keys

slide-33
SLIDE 33

Block signing: Key-evolving signatures

KES are signature schemes, where:

  • pk remains the same
  • sk updated in every step, old sk erased
  • impossible to forge old signatures with

new keys

  • used for signing blocks
  • helps achieve adaptive security
  • UC-functionality + realization

Txs H(prev) Slot # sigLi( ) ...

slide-34
SLIDE 34

Validity of a chain

A valid blockchain in single-epoch setting:

  • increasing slot numbers
  • each block contains:
  • correct VRF-pair proving eligibility
  • correct VRF-pair for randomness derivation
  • KES-signature by eligible leader

1 2 3 4 5 6 7

slide-35
SLIDE 35

The Protocol (single epoch)

  • For each slot:
  • Collect all transactions.
  • Collect all broadcast blockchains. Cull according to

validity; maintain the longest one C.

  • If leader, add a new block in this slot with all

transactions (consistent with C) to the end of C. Sign it and broadcast.

slide-36
SLIDE 36

Ouroboros Praos: Security Analysis

slide-37
SLIDE 37

Proven Guarantees

✓ Common Prefix (k): Any 2 chains possessed by 2 honest parties:

  • ne is a prefix of the other except for at most k last blocks.

✓ Chain Growth (s,): Any chain possessed by an honest party has

at least s blocks over any sequence of s slots. ✓ Chain Quality (k): Any chain possessed by an honest party contains an honest block among last k blocks.

slide-38
SLIDE 38

Proven Guarantees

✓ Common Prefix (k): Any 2 chains possessed by 2 honest parties:

  • ne is a prefix of the other except for at most k last blocks.

✓ Chain Growth (s,): Any chain possessed by an honest party has

at least s blocks over any sequence of s slots. ✓ Chain Quality (k): Any chain possessed by an honest party contains an honest block among last k blocks. These are known to imply what we want:

✓ Persistence ✓ Liveness

slide-39
SLIDE 39

Proof Outline

  • 1. CP, CG, CQ
  • single-epoch setting, static corruption
slide-40
SLIDE 40

Proof Outline

  • 1. CP, CG, CQ
  • single-epoch setting, static corruption
  • 2. Adaptive adversaries
  • dominated by a “greedy” static adversary
slide-41
SLIDE 41

Proof Outline

  • 1. CP, CG, CQ
  • single-epoch setting, static corruption
  • 2. Adaptive adversaries
  • dominated by a “greedy” static adversary
  • 3. Lifting to multiple epochs
  • security of the (stake dist., randomness)-update

mechanism

slide-42
SLIDE 42
  • 1. Single-epoch, static CP, CG, CQ

Unlike a bitcoin adversary, our adversary:

  • knows which slots he controls ahead of time
  • can generate multiple blocks per slot for free

This additional power can be contained.

  • extension of a blockchain calculus from [KRDO17]
  • here: only CP
slide-43
SLIDE 43

Characteristic strings and forks

In a fixed execution...

  • characteristic string: describes the leader assignment
  • fork: tree that captures all constructed chains
  • one char. string admits many forks
  • some forks are bad (create large CP-violation)
slide-44
SLIDE 44

Characteristic strings and forks

In the random experiment...

  • symbols of char. string are i.i.d.
  • Goal: w.h.p. we get a char. string that admits no bad

forks

slide-45
SLIDE 45

Reduction to synchronous case

Synchronous case [KRDO17]

  • synchronous forks (special case)
  • no empty slots (no ⊥)
slide-46
SLIDE 46

Reduction to synchronous case

Synchronous case [KRDO17]

  • synchronous forks (special case)
  • no empty slots (no ⊥)

Reduction mapping ⍴(w): {0,1,⊥}* →{0,1}*

  • results in an “almost” binomial distribution
  • preserves CP-violations!
slide-47
SLIDE 47

Bounding synchronous CP

Theorem from [KRDO17,RMKQ17]: Draw w=w1…wn from the binomial distribution with parameter (1-)/2. Then Pr[k-CP violation] ≤ ne -Ω(k). Proof:

  • martingale argument
slide-48
SLIDE 48
  • 2. Adaptive adversaries
slide-49
SLIDE 49
  • 2. Adaptive adversaries
  • consider leadership elections for individual coins
  • equivalent thanks to “independent aggregation”
slide-50
SLIDE 50
  • 2. Adaptive adversaries
  • consider leadership elections for individual coins
  • equivalent thanks to “independent aggregation”
  • let the adversary corrupt individual coins
  • more powerful than before
slide-51
SLIDE 51
  • 2. Adaptive adversaries
  • consider leadership elections for individual coins
  • equivalent thanks to “independent aggregation”
  • let the adversary corrupt individual coins
  • more powerful than before
  • yet-uncorrupted coins are indistinguishable
  • thanks to key-evolving signatures
slide-52
SLIDE 52
  • 2. Adaptive adversaries
  • consider leadership elections for individual coins
  • equivalent thanks to “independent aggregation”
  • let the adversary corrupt individual coins
  • more powerful than before
  • yet-uncorrupted coins are indistinguishable
  • thanks to key-evolving signatures
  • “greedy” static adversary dominates any adaptive one
slide-53
SLIDE 53
  • 3. Lifting to multiple epochs
slide-54
SLIDE 54
  • 3. Lifting to multiple epochs
  • stake distribution: snapshot from the last block 2 epochs ago
  • randomness: hash of VRF-values in first ⅔ of previous epoch

H( || ||...)

slide-55
SLIDE 55
  • 3. Lifting to multiple epochs
  • stake distribution: snapshot from the last block 2 epochs ago
  • randomness: hash of VRF-values in first ⅔ of previous epoch

H( || ||...) CG+CP: stake distribution stabilizes

slide-56
SLIDE 56
  • 3. Lifting to multiple epochs
  • stake distribution: snapshot from the last block 2 epochs ago
  • randomness: hash of VRF-values in first ⅔ of previous epoch

H( || ||...) CG+CQ: honest block affects randomness CG+CP: stake distribution stabilizes

slide-57
SLIDE 57
  • 3. Lifting to multiple epochs
  • stake distribution: snapshot from the last block 2 epochs ago
  • randomness: hash of VRF-values in first ⅔ of previous epoch

H( || ||...) CG+CQ: honest block affects randomness CG+CP: stake distribution stabilizes CG+CP: randomness stabilizes

slide-58
SLIDE 58
  • 3. Lifting to multiple epochs
  • stake distribution: snapshot from the last block 2 epochs ago
  • randomness: hash of VRF-values in first ⅔ of previous epoch

H( || ||...)

  • some “grinding” still possible
  • small number of “resamplings”
  • insufficient to boost exponentially small error probabilities
slide-59
SLIDE 59

Follow-up: Ouroboros Genesis

Improved Ouroboros Praos that:

  • provides bootstrapping from genesis block
  • UC-realizes the Ledger functionality from [BMTZ17]
  • achieves security with dynamic availability

[Badertscher, Gaži, Kiayias, Russell, Zikas’18]

slide-60
SLIDE 60

Thank you for your attention!

  • Ouroboros:

[Crypto’17]

https://eprint.iacr.org/2016/889

  • Ouroboros Praos:

[Eurocrypt’18]

https://eprint.iacr.org/2017/573

  • Ouroboros Genesis:

https://eprint.iacr.org/2018/378