OUROBOROS PRAOS: AN ADAPTIVELY-SECURE, SEMI-SYNCHRONOUS

Similar documents
Lecture 12. Algorand

Formally Specifying Blockchain Protocols

A Scalable Proof-of-Stake Blockchain in the Open Setting

CONSENSUS PROTOCOLS & BLOCKCHAINS. Techruption Lecture March 16 th, 2017 Maarten Everts (TNO & University of Twente)

SpaceMint Overcoming Bitcoin s waste of energy

How Formal Analysis and Verification Add Security to Blockchain-based Systems

Alternative Consensus Algorithms. Murat Osmanoglu

Algorand: Scaling Byzantine Agreements for Cryptocurrencies

SCP: A Computationally Scalable Byzantine Consensus Protocol for Blockchains

Introduction to Cryptoeconomics

Data Consistency and Blockchain. Bei Chun Zhou (BlockChainZ)

Cryptocurrency and Blockchain Research

Problem: Equivocation!

A Lightweight Blockchain Consensus Protocol

Secure Multiparty Computation

Proof of Stake Made Simple with Casper

BlockFin A Fork-Tolerant, Leaderless Consensus Protocol April

CS 261 Notes: Algorand

CS 4770: Cryptography. CS 6750: Cryptography and Communication Security. Alina Oprea Associate Professor, CCIS Northeastern University

ENEE 457: E-Cash and Bitcoin

Consensus & Blockchain

PaLa: A Simple Partially Synchronous Blockchain

Blockchains & Cryptocurrencies

Blockchain. CS 240: Computing Systems and Concurrency Lecture 20. Marco Canini

Bitcoin as a Transaction Ledger: A Composable Treatment

How Bitcoin achieves Decentralization. How Bitcoin achieves Decentralization

EECS 498 Introduction to Distributed Systems

Hybrid Consensus. Tai-Ning Liao, Xian-Ming Pan, Zhao-Heng Chiu, Imu Lin 1/65

Secure Multiparty Computation: Introduction. Ran Cohen (Tel Aviv University)

hard to perform, easy to verify

2-hop Blockchain: Combining Proof-of-Work and Proof-of-Stake Securely

BYZANTINE CONSENSUS THROUGH BITCOIN S PROOF- OF-WORK

Secure Multi-Party Computation Without Agreement

Blockchain for Enterprise: A Security & Privacy Perspective through Hyperledger/fabric

Solida: A Blockchain Protocol Based on Reconfigurable Byzantine Consensus

Analyzing Bitcoin Security. Philippe Camacho

Computer Security. 14. Blockchain & Bitcoin. Paul Krzyzanowski. Rutgers University. Spring 2019

Proof-of-Stake Protocol v3.0

Lecture 3. Introduction to Cryptocurrencies

Scaling Nakamoto Consensus to Thousands of Transactions per Second

TOPPERCASH TOPPERCASH WHITEPAPER REFORM THE BEST OF BLOCKCHAIN

CS 4770: Cryptography. CS 6750: Cryptography and Communication Security. Alina Oprea Associate Professor, CCIS Northeastern University

Dfinity Consensus, Explored

I. Introduction. II. Security, Coinage and Attacks

POLARIS ADAPTIVE STATE SHARDING TECHNOLOGY, A SECURE SHARDING PROTOCOL FOR BLOCKCHAINS.

Distributed Concurrence Ledgers 16 May, 2016

ECC: Peer-to-Peer Electronic Cash with Trustless Network Services

Secure digital certificates with a blockchain protocol

Hyperledger fabric: towards scalable blockchain for business

Bitcoin, a decentralized and trustless protocol

RapidChain: Scaling Blockchain via Full Sharding

An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings draft-paillisse-sidrops-blockchain-01

Harmony Open Consensus for 10B People

Alternative Consensus

A Blockchain-based Mapping System

Peer-to-peer Sender Authentication for . Vivek Pathak and Liviu Iftode Rutgers University

arxiv: v2 [cs.dc] 12 Sep 2017

Overview & White Paper.

The security and insecurity of blockchains and smart contracts

CS573 Data Privacy and Security. Cryptographic Primitives and Secure Multiparty Computation. Li Xiong

Enhanced Immutability of Permissioned Blockchain Networks by Tethering Provenance with a Public Blockchain Network

Secure Algorithms and Data Structures for Massive Networks

Sharding. Making blockchains scalable, decentralized and secure.

Key concepts of blockchain

CRYPTOGRAPHIC PROTOCOLS: PRACTICAL REVOCATION AND KEY ROTATION

DisLedger - Distributed Concurrence Ledgers 12 August, 2017

What is Proof of Work?

Multi-Theorem Preprocessing NIZKs from Lattices

ICS 421 & ICS 690. Bitcoin & Blockchain. Assoc. Prof. Lipyeow Lim Information & Computer Sciences Department University of Hawai`i at Mānoa

The Balance Attack Against Proof-Of-Work Blockchains: The R3 Testbed as an Example

Whitepaper Rcoin Global

GENESIS VISION NETWORK

The Balance Attack or Why Forkable Blockchains Are Ill-Suited for Consortium

Bitcoin and Blockchain

BLOCKCHAIN The foundation behind Bitcoin

Transactions as Proof-of-Stake! by Daniel Larimer!

Bitcoin. CS6450: Distributed Systems Lecture 20 Ryan Stutsman

BBc-1 : Beyond Blockchain One - An Architecture for Promise-Fixation Device in the Air -

REM: Resource Efficient Mining for Blockchains

KDC COIN WHITEPAPER KDC COIN WHITEPAPER.

Distributed Consensus Protocols

Blockchain Beyond Bitcoin. Mark O Connell

As a 3rd generation currency, not only are transactions secured, private and fast, you actually get paid for holding DigitalPrice coins.

Arvind Krishnamurthy Fall Collection of individual computing devices/processes that can communicate with each other

Practical Byzantine Fault Tolerance. Miguel Castro and Barbara Liskov

Chapter 13. Digital Cash. Information Security/System Security p. 570/626

SOME OF THE PROBLEMS IN BLOCKCHAIN TODAY

Adaptively Secure Broadcast, Revisited

Research Statement. Yehuda Lindell. Dept. of Computer Science Bar-Ilan University, Israel.

Cryptographic Primitives and Protocols for MANETs. Jonathan Katz University of Maryland

Biomedical and Healthcare Applications for Blockchain. Tiffany J. Callahan Computational Bioscience Program Hunter/Kahn Labs

Initial Assumptions. Modern Distributed Computing. Network Topology. Initial Input

Using Chains for what They re Good For

The Not-So-Short ZILLIQA Technical FAQ

Secure Multiparty Computation

Decentralized prediction game platform, powered by public

Cardano Transaction Fees

Alternatives to Blockchains. Sarah Meiklejohn (University College London)

Adaptively Secure Broadcast, Revisited

CSE 5852, Modern Cryptography: Foundations Fall Lecture 26. pk = (p,g,g x ) y. (p,g,g x ) xr + y Check g xr +y =(g x ) r.

Transcription:

OUROBOROS PRAOS: AN ADAPTIVELY-SECURE, SEMI-SYNCHRONOUS PROOF-OF-STAKE BLOCKCHAIN Bernardo David Tokyo Tech & IOHK Peter Gaži IOHK Aggelos Kiayias U. Edinburgh & IOHK Eurocrypt 2018 Alexander Russell U. Connecticut

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

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

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

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]

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.

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

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

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

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

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

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

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

Ouroboros Praos: Protocol Description

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

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

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

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

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

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

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

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

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(.)

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

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

Hashing for epoch randomness Verifiable Random Functions: Evaluate (input) = (output, proof) sk Verify (input, output, proof) = 0/1 pk 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 H(...) Txs H(prev) Slot # VRF output VRF proof sigli( )

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

Leader selection: local, private Verifiable Random Functions: Evaluate (input) = (output, proof) sk Verify (input, output, proof) = 0/1 pk Leader selection lottery for stakeholder Ui: Evaluatesk(rnd,slot) < (stakei) (output,proof) included in the block

Leader selection: local, private Verifiable Random Functions: Evaluate (input) = (output, proof) sk Verify (input, output, proof) = 0/1 pk 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 Verifiable Random Functions: Evaluate (input) = (output, proof) sk Verify (input, output, proof) = 0/1 pk 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: choice of (.) α [0,1] f [0,1] ratio of non-empty slots f is a protocol parameter slightly sublinear growth maintains independent aggregation

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

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 Txs H(prev) Slot # used for signing blocks helps achieve adaptive security UC-functionality + realization... sigli( )

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

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.

Ouroboros Praos: Security Analysis

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.

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

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

Proof Outline 1. 2. CP, CG, CQ single-epoch setting, static corruption Adaptive adversaries dominated by a greedy static adversary

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

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

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)

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

Reduction to synchronous case Synchronous case [KRDO17] synchronous forks (special case) no empty slots (no )

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!

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

2. Adaptive adversaries

2. Adaptive adversaries consider leadership elections for individual coins equivalent thanks to independent aggregation

2. Adaptive adversaries consider leadership elections for individual coins equivalent thanks to independent aggregation let the adversary corrupt individual coins more powerful than before

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

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

3. Lifting to multiple epochs

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(...)

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

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...) CG+CQ: honest block affects randomness

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...) CG+CQ: honest block affects randomness CG+CP: randomness stabilizes

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

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]

Thank you for your attention! Ouroboros: [Crypto 17] https://eprint.iacr.org/2016/889 Ouroboros Praos: https://eprint.iacr.org/2017/573 Ouroboros Genesis: https://eprint.iacr.org/2018/378 [Eurocrypt 18]