Can we safely adapt the construction of permissionless blockchain to user demand ?
0 likes734 views
1) The document discusses adapting permissionless blockchain construction to user demand by allowing the number of blocks and block creation rate in a blockchain to self-adapt to transaction demand. 2) It proposes a system called Sycomore that moves from a chain of blocks to a directed acyclic graph (DAG) of blocks where the predecessor of a block is not predictable. 3) Sycomore aims to partition transactions over blocks in a way that is verifiable by anyone and allows the blockchain to scale to thousands of transactions per second while maintaining security properties like preventing double spending.
Can we safely adapt the construction of permissionless blockchain to user demand ?
- 1. 1 Can we safely adapt the construction of permissionless blockchain to user demand? Emmanuelle Anceaume (CNRS) Joint work with Antoine Durand (IRT SystemX), Romaric Ludinard (IMT-Atlantique), Bruno Sericola (INRIA) Journées Futur & Ruptures - January, 31st of January 2019
- 2. 2 Bitcoin is a cryptocurrency and payment system • Fully decentralized • No public key infrastructure • Permissionless Such constraints make the general problem of consensus impossible to solve • Relies on rational behavior and incentives mechanisms To reach a consensus on the cryptocurrency state
- 3. 3 Deconstructing Bitcoin Transactions Nakamoto consensus algorithm Communication network
- 4. 4 The state of the cryptocurrency system is represented by transactions • Transfers currency from one user to another • Does not contain any encrypted information nor confidential information Transaction 20ab3701i Transaction 74201ab3c UTXO UTXO = Unspent Transaction Output Output #2 account + ฿ + script Output #1 account + ฿ + script Output #1 account + ฿ + script Output #1 account + ฿ + script Input #1 Output ref. + script Transaction 1206ac34e Output #2 account + ฿ + script Output #3 account + ฿ + script Output #1 account + ฿ + script Input #1 Output ref. + script Input #2 Output ref. + script Input #1 Output ref. + script Input #2 Output ref. + script Do not forget Tx fees, i.e., ฿ input ฿ output UTXO
- 5. 5 Checking the ownership of an account • How can anyone check that I am the legitimate owner of an account since there are no identities in a transaction ? • Using « public keys as identities » principle 1 • Ownership = knowing a private key that redeems an output Account / address / UTXO = « single use » object • debited once • should be credited once 1. D. Chaum, « Untraceable Electronic Mail, Return Addresses, and Digital Pseudonums », Communications of the ACM 24(2), pp :84–90,1981
- 6. 6 Signed transactions guarantee that only the owner of an output can spend bitcoins However signatures do not prevent double-spending attacks • I.e., the fact that Alice spends an output twice A publicly, immutable, and totally ordered sequence of transactions
- 7. 7 2. Nakamoto Consensus protocol : Adversary model 2 The Computational Threshold Adversary (CTA) model • The adversary controls a minority of the total amount of computational power • The CTA model is also called the permissionless model • There is no membership protocol • Incorporates some degree of synchrony The Stake Threshold Adversary (STA) model • The adversary controls a minority stake in some limited resource, i.e., the crypto-currency • May allow to punish malicious parties via some stake deposit 2. Ittai Abraham and Dahlia Malkhi, « The blockchain consensus layer and BFT », The distributed Computing Column, 2017
- 8. 8 2. Nakamoto Consensus protocol Two ingredients : Leader Election Oracle + Heavier Fork Strategy 1 A leader election oracle by relying on the PoW mechanism • Each party is elected independently • The probability of electing each party is proportional to its relative computational power • Each party commits to a single block → Synchronize the creation of blocks → Prevent Sybil attacks → Incentivize correct behavior through currency creation
- 9. 9 2. Nakamoto Consensus protocol Two ingredients : Leader Election Oracle + Heavier Fork Strategy 2 The simple and local Heavier Fork Strategy • Select the chain which required the greatest among of work • Random nature of the PoW + Non-faulty leaders always use the chain which required the greatest among of work → One chain will be extended more than the others → The blockchain B0 Bi Bi+1 Bi+1
- 10. 10 2. Nakamoto Consensus protocol The goal of the Consensus Nakamoto protocol is to implement a blockchain replication protocol 3 • (Uniqueness) There is a unique chain of blocks (i.e., the blockchain) extracted from the tree • (Liveness) The blockchain is constantly growing • (Safety) The deeper a block is buried in the blockchain the harder it is to abort it • (Fairness) The proportion of blocks of non-faulty parties in the blockchain is proportional to their computation power 3. J. Garay and A. Kiayias, The Bitcoin Backbone Protocol : Analysis and Application, Eurocrypt 2015
- 11. 11 3. Peer-to-Peer Network • Topology formed through a randomized process • No coordinating entity • Broadcast is based on flooding/gossiping neighbors’ link Tx d - e Tx a - B Tx a - B Tx a - B Tx a - B Tx a - B Tx a - B Tx a - B Tx a - B Tx a - B Tx a - B Tx d - e Tx d - e Tx d - e Tx d - e Tx d - e Tx a - B Tx d - e Tx d - e Tx a - B Tx a - B Tx d - e
- 12. 12 Required properties 1. Connectivity • Each node should receive any broadcast information 2. Low latency 4 msg. transmission time block time interval 1 Allows to keep the probability of fork small (i.e. 10−3) PoW mechanism allows this ratio to continuously hold Safety requires to wait one hour (i.e., no instant finality) No more than 7 trans/s can be permanently confirmed in average ! ! 4. J. Garay and A. Kiayias, The Bitcoin Backbone Protocol : Analysis and Application, Eurocrypt 2015
- 13. 13 Electing a leader in a permissionless setting • Proof-of-work Works in practice and this is true since 2009 Security analysis Environmental issues Diminishing returns Distinction between miners and crypto-currency holders (i.e., miners control what is inside blocks) • Proof-of-work with useful computation, proof-of-space, proof-of-storage, . . . Physical resources • Proof-of-stake Abstract but limited resource : coin itself All the required information is already in the blockchain Numerous attacks
- 14. 14 Proof-of-stake approaches Proof-of-stake motto : « The probability for party p of winning the leader election is proportional to the fraction of currency p owns » • Eventual-consensus • Protocols that apply some form of longest-chain rule to the blockchain • Immutability of a block increases gradually • e.g. PPcoin, NXT, Ouroboros, . . . • Blockwise-BA • Immutability of a block is achieved by BA before working on the next one • e.g. Algorand
- 15. 15 Proof-of-stake approaches PoS approaches are subject to attacks 5 essentially because it costs nothing to create blocks and because of currency transfer from transacting parties to the parties that maintain the ledger • Checkpointing mechanisms • Provide newcomers with a relatively recent block (trust issue) • Prevent to adopt a new chain that originates to much in the past (knowledge of the honest chain) • Key-evolving cryptography : secret keys are evolving so that past signatures cannot be forged (does not apply to UTXO based model) • Enforce strict chain density statistics (knowledge of the number of parties at any time) • Add context in each transaction (knowledge of the honest chain) 5. P. Gazi, A. Kiayias, A. Russel, « Stake-Bleeding Attacks on Proof-of-Stake Blockchains », IOHK
- 16. 16 Preventing conflicts as soon as possible 1. Valid blocks should never be confronted with any other conflicting blocks → No fork ! → 0-confirmation delay 2. Valid transactions should never be confronted with any other conflicting transactions → No double spending attacks ! → Fast payments feasible
- 17. 17 Preventing conflicts as soon as possible 6 1. Valid blocks should never be confronted with any other conflicting blocks How ? Agreement on the unique block that can reference an earlier block in the blockchain 2. Valid transactions should never be confronted with any other conflicting transactions How ? Agreement on the unique transaction that can redeem unspent transaction outputs (UTXOs) 6. Joint work with Antoine Durand (IRT SystemX), Romaric Ludinard (IMT), Bruno Sericola (Inria) E. Anceaume, A. Guellier, R. Ludinard, UTXO as a proof of membership for Byzantine Agreements, IEEE Blockchain 2018.
- 18. 18 Model • Permissionless system • Partially synchronous environment • Adversary : no more than 1/3 of the total amount of money is held by the adversary • Nodes have access to safe cryptographic functions (hash function and signature scheme) • Each object of the system (i.e., UTXO, transaction and block) is assumed to be uniquely identified • No public key infrastructure to establish node identities
- 19. 19 Properties Most of the permissionless blockchain-based cryptosystems guarantee that : Property (Safety) If a valid transaction T is deeply confirmed at some non-compromised node then no transaction conflicting with T will ever be deeply confirmed by any non-compromised nodes Property (Liveness) Any conflict-free and valid transaction will eventually be deeply confirmed in the blockchain of all non-compromised nodes at the same height in the blockchain
- 20. 20 Properties We aim at strengthening both properties Property (Strong safety) If a valid transaction T is confirmed at some non-compromised node then no transaction conflicting with T will ever be confirmed by any non-compromised nodes Property (Strong liveness) Any valid transaction will eventually be confirmed in the blockchain of all non-compromised nodes at the same height in the blockchain
- 21. 21 Transaction validation protocol At most one transaction is allowed to use all the UTXOs referenced in its input set TRANSACTION WITH BOB VALID ?? YES ! ALICE
- 22. 22 Transaction validation protocol At most one transaction is allowed to re- deem all the UTXOs referenced in its input set
- 23. 23 Transaction validation protocol At most one transaction is allowed to re- deem all the UTXOs referenced in its input set TRANSACTION WITH BOB VALID ?? YES ! ALICE TRANSACTION WITH EVE VALID ?? NO!
- 24. 24 Block validation protocol Any validated block has at most one valid block as immediate successor VALID ?? YES ! Pred=0001001 Block 0000111
- 25. 25 Block validation protocol Any validated block has at most one valid block as immediate successor VALID ?? YES ! Pred=0001001 Block 0000111 Pred=0001001 Block 0000001 NO ! VALID ??
- 26. 26 A set of ingredients 1. Byzantine Agreement (BA) • Primitive enabling a set of committee members to agree on a single value, each member holding a possibly different initial value. • Tolerate the presence of a minority of malicious members
- 27. 27 2. « Public keys as identities » principle • Users, i.e. owners of accounts (owners of UTXOs), participate to BA 7 • Alternative to existing designs • Rely on the unique association UTXO/identity as a proof of membership for BA 7. E. Anceaume, A. Guellier, R. Ludinard, UTXO as a proof of membership for Byzantine Agreements, IEEE Blockchain 2018.
- 28. 28 3. Clustered-based Distributed Hash Table (DHT) • P2P overlay whose topology approximates a structured graph • For resiliency reasons, each vertex of the graph is a set of nodes • Nodes logically close to each other belong to the same cluster • e.g., PeerCube is a clustered-based overlay 8 resilient to adversarial behavior and robust to high churn 8. E. Anceaume, R. Ludinard and B. Sericola. Performance evaluation of large-scale dynamic systems. ACM Sigmetrics Performance Evaluation Review, 39(4), 2012.
- 29. 29 3. Clustered-based Distributed Hash Table (DHT) (cont’d) By reaching an agreement around the objects to be validated • Resistance to Eclipse attacks • IDs are random, ephemeral and verifiable • Resistance to Sybil attacks • Participation to committees is weighted by UTXOs amount • Resistance to Selfish attacks • Miners cannot create a block without disclosing it • No double-spending • No forks
- 30. 30 Sycomore : from a chain of blocks to a DAG of blocks 9 9. E. Anceaume, A. Guellier, R. Ludinard, B. Sericola, Sycomore : a Permissionless Distributed Ledger that self-adapts to Transactions Demand, IEEE NCA, 2018
- 31. 31 Sycomore : from a chain of blocks to a DAG of blocks • Transactions are partitioned over the blocks of the ledger - verifiable by anyone
- 32. 32 Sycomore : from a chain of blocks to a DAG of blocks • The number of blocks and their creation rate self-adapt to transactions demand - verifiable by anyone
- 33. 33 Sycomore : from a chain of blocks to a DAG of blocks • The predecessor of a block is not predictable - verifiable by anyone
- 34. 34 0 100 200 300 400 500 600 1 5 10 15 20 25 30 35 Meaninter-blocktime(s) c 1/(cλ0) • With c = 30 leaf blocks, a block is mined every 20s (7, 000 Tx/s) with a proba of fork of 10−6 • Bitcoin : a block every 10 mns (7 Tx/s) with a proba of fork of 10−3 • Could even go faster by relying on our structured DHT Mean inter-block time as a function of the number of leaf blocks c.
- 35. 35 Collaborations and financial support Current collaborations • Local : R. Ludinard (IMT Atlantique), B. Sericola and Y. Mocquard (Dionysos), F. Tronel (Cidre). • National : A. Durand (IRT SystemX), M. Potop-Butucaru (LIP6), A. Del Pozzo and S. Tucci (CEA) • International : P. Tzigas (Chalmers Univ), L. Querzoni (La Sapienza Univ), Financial support • PEPS INS2I Securite 2016 and 2017 : BIPs • Labex Cominlabs 2019 : Blockchain FM
- 36. 36 Collaborations and financial support We are looking for students, engineers, researchers to join us in this adventure to build a nice and secure infrastructure Thanks for your attention