o uroboros p raos
play

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

Nov 10, 2023 •248 likes •864 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

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

  2. Roadmap ● Proof-of-work vs. Proof-of-stake blockchains ● Ouroboros Praos ● Protocol Description ● Security Analysis

  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 ●

  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 ? …………….

  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]

  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.

  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

  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

  9. Previous proof-of-stake solutions with rigorous guarantees Eventual (Nakamoto-style) Consensus: ● Ouroboros [KRDO16] ● Snow White [DPS16] Blockwise Byzantine Agreement: ● Algorand [CM16]

  10. Ouroboros Provably guarantees ● persistence: stable transactions are immutable ● liveness: new transactions included eventually

  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

  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

  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!)

  14. Ouroboros Praos: Protocol Description

  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

  16. Ouroboros Praos: Protocol overview ● time divided into consecutive, disjoint slots

  17. Ouroboros Praos: Protocol overview ● time divided into consecutive, disjoint slots at most 1 block per slot allowed ●

  18. Ouroboros Praos: Protocol overview ● time divided into consecutive, disjoint slots ● epoch : sequence of R slots

  19. Ouroboros Praos: Protocol overview ● 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 ●

  20. Ouroboros Praos: Protocol overview ● 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 ●

  21. Ouroboros Praos: Protocol overview ● 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 ●

  22. Ouroboros Praos: Protocol overview ● 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

  23. Ouroboros Praos: Protocol overview ● 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(.)

  24. Hashing for epoch randomness unique, pseudorandom Verifiable Random Functions: ● Evaluate sk ( input ) = ( output , proof ) ● Verify pk ( input , output , proof ) = 0/1 H(.)

  25. Hashing for epoch randomness Verifiable Random Functions: Txs ● Evaluate sk ( input ) = ( output , proof ) H(prev) ● Verify pk ( input , output , proof ) = 0/1 Slot # VRF output ● every leader inserts a separate VRF (value,proof) VRF proof into block sig Li ( ) H(.)

  26. Hashing for epoch randomness Verifiable Random Functions: Txs ● Evaluate sk ( input ) = ( output , proof ) H(prev) ● Verify pk ( input , output , proof ) = 0/1 Slot # VRF output ● every leader inserts a separate VRF (value,proof) VRF proof into block ● hash of VRF values from initial ⅔ of epoch give sig Li ( ) randomness for the whole next epoch H( || ||...)

  27. Single-epoch setting Focus on one epoch of length R ● static stake distribution ● ideal randomness

  28. Leader selection: local, private Verifiable Random Functions: ● Evaluate sk ( input ) = ( output , proof ) ● Verify pk ( input , output , proof ) = 0/1 Leader selection lottery for stakeholder U i : Evaluate sk ( rnd , slot ) < � ( stake i ) ( output , proof ) included in the block

  29. Leader selection: local, private Verifiable Random Functions: ● Evaluate sk ( input ) = ( output , proof ) ● Verify pk ( input , output , proof ) = 0/1 Leader selection lottery for stakeholder U i : Evaluate sk ( rnd , slot ) < � ( stake i ) ● similar idea previously in NXT, Algorand ● needs unpredictability under malicious key generation ● UC-functionality + efficient realization from CDH+RO

  30. Leader selection: local, private Verifiable Random Functions: ● Evaluate sk ( input ) = ( output , proof ) ● Verify pk ( input , output , proof ) = 0/1 Leader selection lottery for stakeholder U i : Evaluate sk ( rnd , slot ) < � ( stake i ) ● similar idea previously in NXT, Algorand ● needs unpredictability under malicious key generation ● UC-functionality + efficient realization from CDH+RO

  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”

  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

  33. Block signing: Key-evolving signatures KES are signature schemes, where: ● pk remains the same Txs ● sk updated in every step, old sk erased ● impossible to forge old signatures with H(prev) new keys Slot # ● used for signing blocks ... ● helps achieve adaptive security ● UC-functionality + realization sig Li ( )

  34. Validity of a chain A valid blockchain in single-epoch setting: 1 2 3 4 5 6 7 ● increasing slot numbers ● each block contains: correct VRF-pair proving eligibility ● correct VRF-pair for randomness derivation ● KES-signature by eligible leader ●

  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.

  36. Ouroboros Praos: Security Analysis

  37. Proven Guarantees ✓ Common Prefix ( k ): Any 2 chains possessed by 2 honest parties: one 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.

  38. Proven Guarantees ✓ Common Prefix ( k ): Any 2 chains possessed by 2 honest parties: one 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

  39. Proof Outline 1. CP, CG, CQ ● single-epoch setting, static corruption

More recommend