Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Blockchain and Smart Contracts

Blockchain & Smart contract talk @ Distributed System course http://apice.unibo.it/xwiki/bin/view/Courses/Sd1819

  • Login to see the comments

Blockchain and Smart Contracts

  1. 1. Blockchain and Smart Contracts Distributed System / Technologies Sistemi Distribuiti / Tecnologie Giovanni Ciatto Andrea Omicini giovanni.ciatto@unibo.it andrea.omicini@unibo.it Dipartimento di Informatica, Scienza e Ingegneria (DISI) Alma Mater Studiorum – Universit`a di Bologna Academic Year 2018/2019 Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 1 / 121
  2. 2. Talk Outline 1 Wetting your apetite 2 Fundamentals 3 State Machine Replication 4 The Blockchain’s main elements 5 Universal SMR 6 Smart contracts 7 Do we need BCT? Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 2 / 121
  3. 3. Wetting your apetite “Blockchain, the technology behind Bitcoin” Blockchain = Bitcoin More precisely: Blockchain ⊃ Cryptocurrencies ⊃ Bitcon Blockchain Smart Contracts Cryptocurrencies HyperLedger Fabric Ethereum Bitcoin Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 4 / 121
  4. 4. Wetting your apetite First of all. . . The Blockchain is . . . . . . a general model for distributed & decentralised computation may be implemented in several ways, within heterogeneous application domains, and with disparate goals Bitcoin [27] is . . . . . . one specific Blockchain implementation in one specific application domain (cryptocurrencies) with a specific goal (digitalize & decentralize fiat currency) Smart-contracts-enabled Blockchains are . . . . . . a particular sort of Blockchain exposing (some declination of) the notion of Smart Contract [32] making them interesting in even more application domains Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 5 / 121
  5. 5. Wetting your apetite The Blockchain at a glance Shared, append-only, transparent, and distributed ledger i.e., a register keeping track of the order & timing of transactions i.e., changes to some common data Secured using cryptographic schemes e.g. 1-way hash functions, digital signatures and certificates, encryption The ledger is replicated on multiple nodes of a P2P network removing need for a trusted centralized intermediary making the ledger immutable Transactions are approved and propagated through consensus preventing data loss/corruption due to machines crashing/lying i.e., providing robustness against Byzantine failures Ideal use case: secure hub for mutually untrusted parties which need to interact Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 6 / 121
  6. 6. Wetting your apetite Expectations for the future I Gartner Hype Cycle for Emerging Technologies, 2016 Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 7 / 121
  7. 7. Wetting your apetite Expectations for the future II Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 8 / 121
  8. 8. Wetting your apetite Expectations for the future III Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 9 / 121
  9. 9. Fundamentals Cryptographic Tools One-way hash functions hash( ) Properties ! = easy, × = infeasible digest = H(input) input → digest × digest → input × P(H(x) = H(y) | x = y) ≈ 0 small ∆input =⇒ big ∆digest Goal: revealing tempering attempts Example: the SHA512 hash function hash("Alice->Bob: 1 $"): "b35f8926bc17290dc4f4febb98bd1..." hash("Allce->Bob: 1 $"): "ff65fc2d9d8cf76917d47b0c7a0a7..." hash("Alice->bob: 2 $"): "7042a70cc7ec19c5cc17bf89390d1..." Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 11 / 121
  10. 10. Fundamentals Cryptographic Tools Public-private key cryptography Functioning: users hold two keys Public key is publicly available Private key is kept secret ? ? Properties ! = easy, × = infeasible creating key-couple encrypt with one key decrypt the other key × decrypt with wrong key × find one key from the other one Goals: confidentiality & authenticity Common use cases public keys are essentially users identifiers authenticity can be proved by encrypting with public keys Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 12 / 121
  11. 11. Fundamentals Schemes Hash Chains Hash functions can be used to build hash chains: Properties Keep track of some sequence of events, i.e., their relative order eventi+1 is stored within a block bi+1 = H(bi , i + 1, eventi+1) It is easy to detect attempt to alter/tamper the past Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 13 / 121
  12. 12. Fundamentals Schemes Digital Signatures Functioning Senders attach signatures to their messages signature = EncryptPub(H(message)) Signatures can be easily verified by everyone knowing Pub It guarantees authenticity Alleged sender ≡ actual sender It guarantees integrity Messages were not tampered Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 14 / 121
  13. 13. Fundamentals Applications Timestamping service By including timestamps in hash chains, we get a timestamping service: Properties Blocks are assumed to be appended (almost) periodically Several simultaneous events may be stored within the same block Keeps track of what happened and when Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 15 / 121
  14. 14. Fundamentals Applications Notary service – Basic Idea By making timestamping services only accept correctly signed events, we get a notary service: ! below, letters A, . . . , F represent user identities Properties Signatures must be valid otherwise, events cannot be notarised in the general case, arbitrarly complex validation rules can be employed Keeps track of who did what and when Provides non-repudiation of events and their timing Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 16 / 121
  15. 15. Fundamentals Applications Notary service – Applications A notary service may have several real-world useful applications: a shared ledger keeping track of orders, shipments, and payments between companies e.g. providers and suppliers in a supply chain a voting system (with open voting) keeping track of who already voted which option an open registry keeping track of public calls and their applications a registry for building ownerships, keeping track of property transfer a punching in/out system for employees a cryptocurrency =) About applications In general, any use case where 2 or more parties may be tempted to lie about what they did or when may take advantage of a notary service Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 17 / 121
  16. 16. Fundamentals Applications Notary service – Example A punching in/out notary service for employees: Each emploee can either enter or exit at a given time Notice that after each block, a resulting state can be computed taking into account all events occurred so far ! white boxes in the image Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 18 / 121
  17. 17. Fundamentals Applications Notary service – Architecture In practice, a notary service may be implemented as a distributed system having a logically centralised, architecture: The central server is in charge of verifying events validity maintaining the hash chain storing the events data It may be redundant but it is controlled by a single party/organization Clients send new events Single point of trust The party/organization running the server may be(come) corrupted and arbitrarly alter the ordering/timings of events, or prevent a particular system from participating. No defence against this problem. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 19 / 121
  18. 18. Fundamentals Applications The need for replication I 1 In order to avoid centralisation of trust, we may replicate the notary service in such a way that each replica is controlled by a different party/organization 2 Whenever a client sends a new event to a replica, is it propagated to all the other replicas Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 20 / 121
  19. 19. Fundamentals Applications The need for replication II 3 Each replica stores a copy of the hash chain and the events 4 It is still possible for a replica to be compromised/corrupted, but as long as the most of them are not, temper attempts can be detected “most”? how many? Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 21 / 121
  20. 20. Fundamentals Applications The need for replication III 3 Essentially, we are proposing to replicate the sofware validating the many events sent by users State Machine Replication This is the aim of the State Machine Replication approach [28, 12] Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 22 / 121
  21. 21. State Machine Replication Overview State Machine Replication (SMR) [28, 12] Main idea Executing the same (not necessarily finite) state machinea over multiple independent (possibly distributed) processors, in parallel, in order to achieve: fault tolerance (to stops, crashes, lies, bugs, etc) availability and reactivity data / software replication & untamperability a State machine ≈ program A network of replicas The processors constitute a peer-to-peer (P2P) network of replicas, all exposing the same observable behaviour ! no assumption about the topology Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 24 / 121
  22. 22. State Machine Replication Deterministic computations Deterministic stateless computations Input −→ Computation −→ Output The computation is deterministic if it always produces the same output when it is performed on the same input. Can be arbitrarily replicated Replicas can be run in parallel Deterministic§ class Calculator { int sum(int x, int y) { return x + y; } } ¦ ¥ Non-deterministic§ class Lottery { int extract(int max) { Random fate = new Random (); return fate.nextInt(max); } } ¦ ¥ Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 25 / 121
  23. 23. State Machine Replication Deterministic computations Deterministic stateful computations I (Input, State) −→ Computation −→ (Output, State ) The computation is deterministic if it always produces the same output when it is performed on the same input and state. Can be arbitrarily replicated replicas run in parallel All replicas must be initialised within the same initial state All inputs must be submitted to all replicas in the same order1 They all move through the same sequence of states Maintaining the consistency of the state among inputs 1 input ≈ method call Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 26 / 121
  24. 24. State Machine Replication Deterministic computations Deterministic stateful computations II § class Ledger { Map String , Integer balances = // all accounts to 0 boolean deposit(String userID , int x, Signature s) { if (s.verify(userID , x)) { balances[userID] += x; return true; } return false; } boolean transfer(String sndr , String rcvr , int x, Signature s) { if (s.verify(sndr , rcvr , x) balances[sndr] = x) { balances[sndr] -= x; balances[rcvr] += x; return true; } return false; } } ¦ ¥ Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 27 / 121
  25. 25. State Machine Replication Deterministic computations Deterministic stateful computations III Non-deterministic§ class RaceCondition { int shared = 0; Thread t1 = new Thread( () - shared ++ ); Thread t2 = new Thread( () - shared -- ); int guess () { t1.start (); t2.start (); t1.join (); t2.join (); return shared; } } ¦ ¥ The Blockchain . . . is essentially a means for replicating deterministic stateful computations, aimed at enforcing the rules of a particular business logic Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 28 / 121
  26. 26. State Machine Replication Deterministic computations Example – Cryptocurrencies: a prototype Notary service + replication + Ledger class ≈ cryptocurrency Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 29 / 121
  27. 27. State Machine Replication Problems of Open Distributed Systems SMR and Open Distributed Systems – Problems SMR implies a (possibly open) Distributed System (DS), which introduces some challenges: Messages may be lost, corrupted, reordered, or duplicated by the network while in transit2 =⇒ each replica may perceive a different view on the system events how to enforce the same ordering of events for all replicas? Lack of global time across distributed machines it is difficult to keep clocks synchronized among replicas =⇒ no trivial solution for events ordering (e.g. timestamps) how to share a common view of time? Consistency, Availability, Partition-resistance (CAP) theorem [9] what if replicas cannot (temporarily) communicate with each other? Byzantine Generals Problem [23] and Byzantine Faults what if some replica crashes or misbehaves (because is buggy or corrupted)? 2 messages ≈ inputs to replicated processes Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 30 / 121
  28. 28. State Machine Replication Problems of Open Distributed Systems SMR and Open Distributed Systems SMR implies a (possibly open) Distributed System (DS), which introduces some challenges: Messages may be lost, corrupted, reordered, or duplicated by the network while in transit robust transport protocols such as TCP hash functions for integrity Lack of global time across distributed machines well known studied problem into the literature reasonable to assume machines have access to UTC3 through NTP4 Consistency, Availability, Partition-resistance (CAP) theorem [9] ∼ eventual consistency Byzantine Generals Problem [23] and Byzantine faults ∼ redundancy + Byzantine fault-tolerant consensus algorithms 3 Universal Coordinated Time 4 Network Time Protocol Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 31 / 121
  29. 29. State Machine Replication CAP theorem CAP theorem [9] In DS with several machines serving some shared data to multiple clients: Availability Partition Tolerance Consistency CA AP CP Consistency (C): all clients always . . . see the same view on data, even after updates Availability (A): all clients always . . . receive some timely response, even with failures Partition-resistance (P): the system . . . keeps operating regardless of network partitions Theorem: you cannot have more than 2 of them If you want P, you must choose between A and C Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 32 / 121
  30. 30. State Machine Replication CAP theorem Eventual Consistency The blockchain essentially chooses P and A Similarly to distributed databases (e.g. MongoDB or noSQL in general) it provides eventual consistency often, consistency is governed by probabilistic rules Eventual Consistency Sooner or later, in finite time, things will become consistenta a where “sooner or later” ≈ “in reasonable time” Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 33 / 121
  31. 31. State Machine Replication Byzantine Fault Tolerance Byzantine Faults I 1 Alice and Bob, simultaneously try to update a replicated system by contacting a replica 2 The final result depends on the requests ordering Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 34 / 121
  32. 32. State Machine Replication Byzantine Fault Tolerance Byzantine Faults II 3 All replicas must agree on an ordering for the operations to be committed Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 35 / 121
  33. 33. State Machine Replication Byzantine Fault Tolerance Byzantine Faults III 4 Byzantine faults (i): inconsistencies may arise prevent agreements Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 36 / 121
  34. 34. State Machine Replication Byzantine Fault Tolerance Byzantine Faults IV 5 Byzantine faults (ii): nodes may be deliberately lying 6 Some 4th replica may break the impasse. . . Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 37 / 121
  35. 35. State Machine Replication Byzantine Fault Tolerance Consensus I Due to the value possibly stored in the ledger, bad actors may have economic incentives to try and cause faults e.g. money or advantages In the absence of Byzantine Fault Tolerance (BFT), a may replica alter the blocks timing or ordering, or excluding particular events The perspective of a replica producing Byzantine faults is dreadful w.r.t. consistency: it may indefinitely prevent agreements Blockchain, similarly to distributed databases, usually employs BFT consensus algorithms in order to prevent Byzantine failures Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 38 / 121
  36. 36. State Machine Replication Byzantine Fault Tolerance Consensus II BFT consensus algorithm A distributed protocol aimed at making a SMR system resistant (i.e., guarantee eventual consistency) to Byzantine failures It turns out distributed consensus is impossible under any of the following assumptions: 1 the underlying network is asynchronous [19], i.e., if messages can be arbitrarily re-ordered or delayed this is why all consensus protocols proceed through periodic rounds 2 the amount f of Byzantine-faulty replicas is such that f ≥ 1 3N, being N the total amount of replicas [23] this is why we needed the 4th replica Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 39 / 121
  37. 37. The Blockchain’s main elements Disclaimer Most of Blockchain-related works describe a specific blockchain technology (BCT henceforth) using a bottom-up approach. I believe this approach hinders generality and limits the discussion about what we can do on top of BCTs. In this section, I try to present the blockchain in a top-down way, synthesising informations from a number of sources, being [27], [33], [5] the most prominent ones. Errors and misunderstanding are possible, and in any case they are my sole responsibility. The following description of the blockchain architecture and functioning is strongly inspired to Ethereum5, being the most mature, studied, and documented smart-contracts-enabled BCT. — G. Ciatto 5 https://github.com/ethereum/wiki/wiki/White-Paper Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 41 / 121
  38. 38. The Blockchain’s main elements Blockchain overview Generally speaking, a Blockchain Technology (BCT) is . . . A clever implementation of a SMR system keeping track of which users own some assets (representations), by means of a replicated ledger, updated through consensus users — are identified though public keys and must sign their transactions with them assets — may be anything having some value, an owner, and, possibly, some mutable state to be tracked e.g. events, money, documents, notary acts, property acts, contracts, etc ledger — is a replicated notary service holding assets’ property/state evolution consensus — a distributed protocol aimed at maintaining and updating the ledger replicas in sync Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 42 / 121
  39. 39. The Blockchain’s main elements The architecture of a BCT R1 R2 R3 C1 C2 C3 Consensus Replicas R1, . . . , RN actually store a copy of the whole ledger Clients C1, . . . , CM may propose some asset updates to any Ri they need not to store the whole ledger Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 43 / 121
  40. 40. The Blockchain’s main elements User identifiers User identifiers Users They are supposed to own (at least) one (Kpub, Kpr ) key pair They are identified by some function f (Kpub) of their public key e.g. 1-way-hash functions e.g. digital certificates issued by some trusted CA ! Identifiers are also known as addresses in this context Permissioned vs Permissionless ! important consequences in a few slides Either each user owns multiple non-intelligible identifiers. . . Pseudonymity Decentralised × Sybil-attack [16] . . . or he/she owns a single certified identifier × Single point of failure/trust Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 44 / 121
  41. 41. The Blockchain’s main elements The world state The world state I The system state SystemState ::= Asset | SystemState ∪ SystemState Asset ::= UserID , AssetState The system state conceptually consists of a set of asset representations, each one specifying the owner of the asset where: UserID = f (KU pub), and KU pub is the public key of some user U Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 45 / 121
  42. 42. The Blockchain’s main elements The world state The world state II The asset state e.g. AssetState ::= Balance e.g. AssetState ::= Balance , Data The account state conceptually consists of several fields keeping track of what a particular entity currently owns The actual fields may vary depending on the blockchain nature: e.g. BCTs coming with native cryptocurrencies, usually keep track of users’ balances (at least) e.g. Other BCTs, may let users keep track of custom data Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 46 / 121
  43. 43. The Blockchain’s main elements The world state The world state – Several possible implementations Account-based e.g. Ethereum [33] Unspent Transaction Output (UTXO) e.g. Bitcoin [27] Versioned Key-Value store e.g. Hyperledger Fabric [5] Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 47 / 121
  44. 44. The Blockchain’s main elements Transactions Transactions (a.k.a. inputs, messages, TXs) I Definition TX ::= UserID , Operation , Arguments , Signature Transactions represent variations of the system state yet to be performed UserID — the address of the user issuing the TX, i.e., f (KU pub) Operation — a description of the operation to be applied on the system state Arguments — some arguments for the aforementioned operation Signature — the cryptographic signature of the TX Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 48 / 121
  45. 45. The Blockchain’s main elements Transactions Transactions (a.k.a. inputs, messages, TXs) II The particular set of possible operation and the corresponding transaction structures is application-specific. In the general case, you need at least: an operation creating new assets an operation updating existing assets Example: cryptocurrencies transactions ! recall the Ledger script TX ::= UserID , deposit, Value , Signature | UserID , transfer, UserID , Value , Signature where the two UserID fields represents the sender and receiver Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 49 / 121
  46. 46. The Blockchain’s main elements Transactions Transactions (a.k.a. inputs, messages, TXs) III Transactions validity A transaction is valid if: (i) it is well formed, (ii) the signature matches the issuer address, and (iii) the signature certifies the transaction integrity Transactions execution A valid transaction tx can be applied to a system state s by means of function γ, producing a novel system state s , a.k.a. the resulting state of tx: γ(s, tx) = s Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 50 / 121
  47. 47. The Blockchain’s main elements Transactions Transactions (a.k.a. inputs, messages, TXs) IV ! valid transaction ! wrong signature Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 51 / 121
  48. 48. The Blockchain’s main elements Transactions Transactions (a.k.a. inputs, messages, TXs) V Depending on the specific use case at hand, it may happen that s ≡ s : for instance, because the sender has not enough money in s or because some other application-level error occurred Function γ and SMR In practice, function γ(·, ·) is the state machine (i.e., program) being replicated Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 52 / 121
  49. 49. The Blockchain’s main elements Blocks and block chains Blocks and block chains I Definition Block ::= PrevHash , Height , Time , Metadata , TxList TxList ::= TX , SystemState | TxList , TxList Blocks are timestamped, hash-linked lists of transactions and their corresponding resulting states PrevHash — the hash of the previous block Height — the index of the current block Time — the timestamp of the current block Metadata — some application-specific metadata TxList — the list of transactions included into the current block and (the hashes of) their resulting states Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 53 / 121
  50. 50. The Blockchain’s main elements Blocks and block chains Blocks and block chains II Thus, a block bi is a 5-uple bi = ( phi , hi , tsi , mi , (tx1 i , r1 i , . . . , txni i , rni i ) ) where rj i is the resulting state after applying all transaction txk i contained in bi for k = 1, . . . , j ni is the total amount of transactions contained in bi Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 54 / 121
  51. 51. The Blockchain’s main elements Blocks and block chains Blocks and block chains III Blocks local validity Provided that the local replica’s last known block is bi−1, a novel block bi is locally valid if: phi ≡ H(bi−1) hi ≡ hi−1 + 1 ≡ i tsi − tsi−1 ∈ [ ∆t − ε; ∆t + ε ] ! ∆t and ε are blockchain specific parameters r1 i = γ(r ni−1 i−1 , tx1 i ) rj i = γ(rj−1 i , txj ) ∀j ∈ 2, . . . , ni Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 55 / 121
  52. 52. The Blockchain’s main elements Blocks and block chains Blocks and block chains IV Blocks execution A locally valid block bi can be applied to the system state si−1 = r ni−1 i−1 produced by the previous block bi−1 by means of function Γ, producing a novel state si , a.k.a. the resulting state of bi : Γ(si−1, bi ) = rni i ≡ si by applying all transactions in bi respecting their order, through γ(·, ·) We assume that s0 = ∅ Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 56 / 121
  53. 53. The Blockchain’s main elements Blocks and block chains Blocks and block chains V TXs hash( ) Index i-1 Timestamp TXs hash( ) Index i Timestamp TXs hash( ) Index i+1 Timestamp Statei-1 Statei Statei+1 Int. States Int. States Int. States Figure: Graphical representation of the Block-chain from the global p.o.v. ! “Int. States” = “Intermediary states” Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 57 / 121
  54. 54. The Blockchain’s main elements Blocks and block chains Blocks and block chains VI Figure: Graphical representation of blocks execution Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 58 / 121
  55. 55. The Blockchain’s main elements Blocks and block chains Recap: Blocks features Replication + Hash-chaining Untamperability of the past Hash-chain + Time + Ordering Timestamping/notary service [20] Hash-chain + Crypt. signatures Accountability Non-repudiation They are supposed to be published (almost) periodically remember parameter ∆t? ! In the general case limn→∞ P[inconsistent(Bi )] = 0, where Bi is the ith block n is the amount of successor blocks of Bi inconsistent(Bi ) is true if not all nodes agree on the content of Bi Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 59 / 121
  56. 56. The Blockchain’s main elements Blocks and block chains The transaction block workflow The genesis block The very first block is assumed to be somehow shared between the replicas Transactions life-cycle — part 1 0 a user U wants to update the system state 1 he/she properly compiles it with operation and arguments 2 he/she signs it with his/her private key KU pr 3 he/she spreads the transaction to on or more replicas ... Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 60 / 121
  57. 57. The Blockchain’s main elements Blocks and block chains A block’s life II Blocks life-cycle — part 1 Each node, periodically with period ∆t: 1 listens for transactions published by clients 2 validates executes them ! invalid transactions are simply dropped 3 compiles the new local candidate block 4 participates to the consensus algorithm with other replicas i.e., negotiates the next block with its peers Byzantine faults may arise . . . because of corrupted replicas, or simply because replicas may have perceived TXs in different order This is why we need step 4! Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 61 / 121
  58. 58. The Blockchain’s main elements Blocks and block chains A block’s life II Transactions life-cycle — part 2 ... 4 the transaction is validated by peers upon reception and dropped if invalid 5 each transaction is eventually executed producing an intermediary state 6 they are both included into some block 7 the block is eventually appended to the blockchain i.e. a consensus protocol confirms the block (there including its transactions) ! These life-cycles may vary a lot depending on the specific consensus algorithm employed Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 62 / 121
  59. 59. The Blockchain’s main elements Blocks and block chains The network point of view Transactions Blocks Blockchain Miners Clients Figure: Graphical representation of the Block-chain from the network p.o.v. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 63 / 121
  60. 60. The Blockchain’s main elements Consensus Mining Consensus Mining I Permission-ed BCTs Constrain users’ IDs through CAs ⇓ “Classical” quorum/leader-based consensus algorithms BFT algorithms e.g. PBFT [11] e.g. BFT-SMaRt [30] e.g. HoneyBadger BFT [26] Non-BFT algorithms e.g. Paxos [21] e.g. Raft [22] e.g. ZooKeeper, Google Chubby Permission-less BCTs Open access to any (Kpub, Kpr ) ⇓ “Novel” competition-based approaches e.g. Proof-of-Work [8] e.g. Proof-of-Stake [1] e.g. Proof-of-Elapsed-Time [13] e.g. IOTA Tangle [2] Comparisons surveys in [7, 10] ! CA = Certification Authority Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 64 / 121
  61. 61. The Blockchain’s main elements Consensus Mining Consensus Mining II Permission-ed BCTs “Classical” quorum/leader-based consensus algorithms Assumptions on the amount N of replicas, and their IDs UB up to ∼ 100 / 1000 High throughput in terms of TXs/second OoM ∼ 1000 TXs/s “Exact” consistency Ideal for closed multi- administrative organizations Solves Sybil attack with CAs Permission-less BCTs “Novel” competition-based approaches No assumption on N UB virtually ∞ Low throughput OoM ∼ 10 TXs/s Probabilistic consistency Ideal for open systems eg cryptocurrencies Solves Sybil attack with PoW ! UB = Upper Bound ! OoM = Order of Magnitude Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 65 / 121
  62. 62. The Blockchain’s main elements The Sybil attack The Sybil attack Distributed P2P systems/protocols where: critical decisions are often made on a majority basis entities must vote in order for a majority to be established entities are identified within the system by means of their IDs it is easy or economically feasible for an attacker to create several IDs may be subject to the Sybil attack [15]. Sybil attack An attacker subverts the P2P system by creating a large number of pseudonymous identities, using them to gain a disproportionately large influence within the system Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 66 / 121
  63. 63. The Blockchain’s main elements The PBFT protocol The PBFT protocol I The “Practical byzantine fault tolerance” (PBFT) algorithm [11] is a BFT consensus protocol where: a leader is elected among the replicas clients send their requests to the leader and wait for at least (f + 1) replies from the replicas where f = maximum amount of faulty replicas the leader multi-casts each request to the other replicas replicas exchange several messages, negotiating an agreement this process traverses two rounds: prepare, and commit finally, replicas send their responses back to the requesting client Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 67 / 121
  64. 64. The Blockchain’s main elements The PBFT protocol The PBFT protocol II When the leader is expected to be faulty (e.g. timeouts) a new one must be selected This, again, implies replicas negotiating the next leader Problems How many messages must be exchanged in case N = 1000? What could happen if fictitious replicas IDs could be created? Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 68 / 121
  65. 65. The Blockchain’s main elements The Proof-of-Work mechanism Proof-of-Work (PoW), a.k.a. mining I PoW was originally conceived for preventing email spam [8] Nowadays, it is what endows cryptocurrencies with their value PoW = computational puzzle + branch resolution strategy The computational puzzle Replicas (a.k.a. miners) compete to be the first one to solve a computational puzzle, approximately once every ∆t ± ε seconds The proof of the effort is easy to verify and included into the block only blocks containing the proof are considered valid The first one replica succeeding with the puzzle, mined the next block of the blockchain Difficulty must be variable and controllable Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 69 / 121
  66. 66. The Blockchain’s main elements The Proof-of-Work mechanism Proof-of-Work (PoW), a.k.a. mining II Example: Bitcoin’s computational puzzle Editing (a field of) the candidate block until its hash starts with a given amount of 0 Algorithm sketch 1 Candidate block bi = ( phi , hi , tsi , mi , ¯txi ), where mi = 0 2 While H(bi ) ≥ hthreshold : increase mi by 1 Example: Ethereum’s computational puzzle A ∼ 1 GiB pseudo-random graph is generated in a reproducible way Candidate block’s content used to select some parts of the graph Such parts are hashed together and included into the block Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 70 / 121
  67. 67. The Blockchain’s main elements The Proof-of-Work mechanism Proof-of-Work (PoW), a.k.a. mining III Mined blocks are published over the P2P network of replicas but propagation on the network requires time Other honest replicas accept as soon as they hear of it they recognise they’ve lost the round they start mining on top of the new block Simultaneously, some other replica may have mined another block maybe because it hasn’t still received the other block maybe because it’s corrupt Such a situation is known as branch and it represent an inconsistency Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 71 / 121
  68. 68. The Blockchain’s main elements The Proof-of-Work mechanism Proof-of-Work (PoW), a.k.a. mining IV Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 72 / 121
  69. 69. The Blockchain’s main elements The Proof-of-Work mechanism Proof-of-Work (PoW), a.k.a. mining V Branches represent many possible versions of the transactions ledger The branch resolution strategy Branches are unavoidable A local rule must be employed by replicas to decide which branch should be considered the true one As long the majority of replicas follow the rule, a single branch should eventually be selected by all replicas =⇒ eventual consistency Example: Bitcoin’s branch resolution strategy Longest chain rule Example: Ethereum’s branch resolution strategy Greedy Heaviest Observed SubTree (GHOST [29]) Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 73 / 121
  70. 70. The Blockchain’s main elements The Proof-of-Work mechanism Longest chain rule I Honest replicas must always consider the longest chain they heard about first Even if a branching occurs, the two branches wont evolve at the exact same speed A branch will eventually become longer, more quickly than the other Eventually the other branch will be abandoned (becoming orphan) We cannot prevent corrupt replicas from generating branches but how likely is it a single replica produces a longer branchin a fewer time than the others? Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 74 / 121
  71. 71. The Blockchain’s main elements The Proof-of-Work mechanism Longest chain rule II r = adversaryCP honestsCP P[n | r] = 1 − n k=0 (nr)k e−nr k! (1 − rn−k) (see [27]) 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 2 3 4 5 6 7 8 9 10 P(n)-ProbabilitàsuccessoDSA n - Numero di blocchi 10% 15% 20% 25% 30% 35% 40% In Bitcoin: nthreshold = 6 ≈ 1h since E[∆T] = 10m 99.999% secure if adversaryCP 13% totalCP Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 75 / 121
  72. 72. The Blockchain’s main elements The Proof-of-Work mechanism PoW interesting features Competition-based, local, eventually-consistent, stochastic approach Self-adaptive mining difficulty, s.t. E[∆t] = const updates compensate the computing power variation of the replicas e.g., in Bitcoin hthreshold is periodically updated e.g., Ethereum comes with similar mechanism + ASIC-resistance Only computing power (CP) matters here Sybil-attack resistant CP distribution Majority rule (51% attack) [18] Notice that no the invariant E[∆t] = const implicitly states . . . . . . the system maximum update frequency is 1/E[∆t] Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 76 / 121
  73. 73. The Blockchain’s main elements The Proof-of-Work mechanism PoW, incentives and disincentives Hp: miners are rational, i.e. selfish Why should miners honestly participate the PoW-based consensus? Likely, those are not even their own transactions PoW is costly in terms of resources, and, therefore, real money Economic incentives Miners “winning” the computational puzzle are rewarded with money such money is created ex-nihilo by the protocol it is an incentive for fairly competing well-behaving Economic disincentives Symmetrically, attacks such are deliberate branching are not strictly prevented but they are made extremely costly Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 77 / 121
  74. 74. The Blockchain’s main elements The Proof-of-Work mechanism PoW, cryptocurrencies, and security Within cryptocurrencies-based Blockchains . . . PoW, economical value, and security are stricly related 1 PoW endows the cryptocurrency with its economical value 2 Miners require economical compensation for their job 3 The miners’ job is the gasoline of a blockchain system 4 Miners will behave honestly as long as it is convenient to do so 5 It is convenient as long as the cryptocurrency has value Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 78 / 121
  75. 75. The Blockchain’s main elements Blockchain generations Three Blockchain generations I In [31], a popular classification of BCTs is introduced: Three BCT generations 1 Cryptocurrencies 2 Custom assets 3 Smart contracts ! The model presented so far essentially includes generations 1 and 2 ! images taken from [3] Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 79 / 121
  76. 76. The Blockchain’s main elements Blockchain generations Three Blockchain generations II Several expected applications Interesting applications for generations 1-2: remittance for online purchases, in place of PayPal smart property unified medical records non-censurable social/news shared balances public calls naming systems access control voting systems Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 80 / 121
  77. 77. The Blockchain’s main elements Blockchain generations Towards Smart Contracts What about generation 3? So far, we’ve described a trustable way for storing/updating data without single-points-of-trust How can we trust the users producing that data? We could automatise asset-management workflows via software . . . we must still trust developers and organizations producing the software We need trustable computational entities (i.e. agents) able to automatically manage assets =⇒ i.e., Smart Contracts Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 81 / 121
  78. 78. Universal SMR “Universal” State Machine Replication UTM : TM = Interpreter : Program = ??? : SMR ! UTM def = Universal Turing Machine — TM def = Turing Machine We could replicate a stateful deterministic program implementing a particular business logic ! e.g. a bank ledger In the exact same way, we could replicate a deterministic program implementing an interpreter ! ≈ a program which executes other programs i.e., what we call “Universal State Machine Replication” (USMR) The admissible operations on such a replicated interpreter should enable users deploy, undeploy, or invoke programs Smart-contracts-enabled Blockchains essentially act as replicated “universal” state machines on which smart contracts can be deployed ! Smart contract ≈ a program deployed on such a machine Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 83 / 121
  79. 79. Universal SMR “Universal” State Machine Replication – Example § class VirtualMachine { Map String , Program processes = // empty Compiler cc = // ... void deploy(String pid , String code) { Program newProgram = cc.compile(code); processes[pid] += newProgram; } Object invoke(String pid , Object [] args) { Object result = null; if (processes. containsKey (pid)) { result = processes[pid]. call(args); } return result; } } ¦ ¥ Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 84 / 121
  80. 80. Smart contracts Definition Smart contracts (SC) [32] Definition Smart contracts (SC) are stateful, user-defined, reactive, immutable – therefore trustable –, and deterministic processes executing replicated and expressive computations on the Blockchain Stateful — they encapsulate their own state, like OOP’s objects Reactive — they can only be triggered by some off-chain client User-defined — users can deploy their own smart contracts implementing any business logic Immutable — their code cannot be altered after deployment Replicated — the blockchain acts as a replicated interpreter for such processes Expressive — they are expressed with a Turing-complete language Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 86 / 121
  81. 81. Smart contracts Interesting properties expectations Smart contracts interesting features SCs can be used to automate workflows involving ≥ 2 parties they can act as intermediaries between the parties reducing failures due to corrupted/selfish human operators making such workflow (more) trustable Immutability + Inspectability + Accountability + Replication =⇒ can be trusted in handling critical assets (even easier with native cryptocurrency) The code is always right, the true history is on the Blockchain reducing disputes removing the need for arbitration Lack of situatedness: totally disembodied [25] data computation like the cloud, but with no single point of trust In a given moment, N copies exists of a given SC, one for each replica but they always compute as one “smart contract instance” = “the many copies of a SC instance” Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 87 / 121
  82. 82. Smart contracts Interesting properties expectations Let’s visualise smart contract instances Transactions Blocks Blockchain Miners Clients Smart contracts SCs instances are cloned too among the servers replicas In the image, the colour represents identity Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 88 / 121
  83. 83. Smart contracts Functioning Smart contracts functioning Usually, at least two operations are provided to clients: deploy — accepts the SC code and has the effect of instantiating it on all the replicas, generating a univoke identifier/address for the SC invoke — accepts a SC identifier and a number of arguments and it has the effect of executing that SC with those arguments Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 89 / 121
  84. 84. Smart contracts Functioning Smart contracts deployment 1 Initially there exists no smart contract i.e., the system state comprehend no smart contract entity 2 A user can instantiate a smart contract by publishing its source/byte-code within a deployment TX the TX also initialises the SC state the protocol assigns an univocal address to the novel SC 3 Once the transaction is confirmed, you can assume the an SC instance is running on all replicas no such a big effort: it is just listening for invocations Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 90 / 121
  85. 85. Smart contracts Functioning Smart contracts invocation 1 Users can trigger a SC by publishing an invocation TX specifying the SC address as recipient providing some input data specifying the requested computation 2 Eventually, each replica will receive the TX and execute it the SC code usually specifies what to do with the provided arguments 3 If the computation terminates without exceptions, any produced side effects (on the SC state) become part of the new intermediate system state Otherwise, side effects are simply dropped, thus the new intermediate state coincides with the previous one 4 The wrapping block is eventually confirmed by the consensus protocol and the invoked computation can be actually considered executed Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 91 / 121
  86. 86. Smart contracts Updating the BCT model Updating the BCT model I Entities can either be Users or Smart Contracts EntityID ::= UserID | SmartContractID The System State is still a set of assets SystemState ::= Asset | SystemState ∪ SystemState Assets can either be Users’ data or Smart Contracts’ states Asset ::= UserID , Balance , Data | SmartContractID , SmartContractState ! the Balance field only makes sense for cruptocurrency-enabled BCTs Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 92 / 121
  87. 87. Smart contracts Updating the BCT model Updating the BCT model II Smart Contracts’ states are made of storage + code SmartContractState ::= Balance , Storage , Code ! in cruptocurrency-enabled BCTs, Smart Contracts can own money too! Think about some SC’s storage as an object’s fields in OOP Think about some SC’s code as an object’s methods in OOP A SC’s code can alter or being affected by its storage In a nutshell User hash(Public Key) Balance Private Public Keys Smart Contract Storage Balance Code Address Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 93 / 121
  88. 88. Smart contracts Updating the BCT model Updating the BCT model III Transactions can be deployments, invocations, or money transfers TX ::= EntityID , Operation , Signature Operation ::= deploy, Code | invoke, Arguments , SmartContractID | transfer, EntityID , Value In a nutshell ! the “gas” field will be presented in a few slides Receiver Sender Invocation Caller Arguments Gas Owner Deployment Code Callee Transfer Amount Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 94 / 121
  89. 89. Smart contracts Updating the BCT model Updating the BCT model IV The γ function executes TXs as follows: creating a new SCs in case of a deploy TX updates the invoked SC’s state in case of a invoke TX updates both the sender’s recipient’s balance in case of a transfer TX The Γ function is unchanged i.e., it still executed a block’s TXs sequentially We just described the Order-Execute architecture [5] Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 95 / 121
  90. 90. Smart contracts Expressiveness VS Termination Issues arising from Turing-completeness What would be the effect of invoking doSomething() such a SC?§ class Bomb { int i = 0; void doSomething () { while (true) { i = (i + 1) % 10; } } } ¦ ¥ Impossible to a-priori filter out non-terminating programs remember the Halting Problem? In DSs, users cannot be assumed to simply well-behave =⇒ Need to prevent/discourage users from deploying/invoking infinite or long computations Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 96 / 121
  91. 91. Smart contracts Expressiveness VS Termination Ethereum and Gas Ethereum proposes gas, i.e., making users pay for computation executions: TXs are endowed with two more fields: gasLimit gasPrice Miners could delay TXs having a low gasPrice Users can increase their priority by increasing gasPrice Upon execution, each bytecode instruction increases the g counter according to a price list defined in [33] Whenever g gasLimit an exception is raised, reverting side effects In any case, upon termination, the issuer balance is decreased of ∆ETH = gasPrice · g The winning miner can redeem ∆ETH as a compensation for its computational effort The economical dimension of computation has to be taken into account when designing Ethereum smart contracts Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 97 / 121
  92. 92. Smart contracts Solidity example Ethereum smart contract example with Solidity6 § contract Counter { event Increased(uint oldValue , address cause); // event definition address owner; uint value; function Counter () public { owner = msg.sender; } // -- constructor function inc(uint times) public { // -- API for (uint i = 0; i times; i++) { emit Increased(value ++, msg.sender); } } } ¦ ¥ 6 https://solidity.readthedocs.io Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 98 / 121
  93. 93. Smart contracts Solidity example Ethereum smart contract example with Solidity Dan--- 5.24 hash( ) CounterEve Alice--- 40 hash( ) BobAlice 20 State 0 Alicebalance = 20 Bobbalance = 20 Carl--- 5 hash( ) DanBob 3 Counter.solAlice State 1 Alicebalance = 20 Bobbalance = 17 Carlbalance = 5 Countervalue = 0 Danbalance = 3 Counterowner = Alice 7 inc(5) CounterCarl 50 inc(2) Increased(3, Carl) Increased(4, Carl) Eve--- 5.28 hash( ) CounterBob 11 inc(1) CounterDan 17 inc(2) Increased(0, Bob) Increased(1, Dan) Increased(2, Dan) State 2 Alicebalance = 20 Bobbalance = 16.89 Carlbalance = 5 Countervalue = 3 Danbalance = 2.83 Evebalance = 5.28 State 3 Alicebalance = 20 Bobbalance = 16.89 Carlbalance = 4.83 Countervalue = 5 Danbalance = 8.07 Evebalance = 4.93 Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 99 / 121
  94. 94. Smart contracts Use cases Use Cases Expectations Smart contracts are expected to act as intermediaries in: Automatic money management or payments e.g. Bills e.g. Insurances e.g. Shares distribution Shared governance e.g. Distributed Autonomous Organizations (DAOs) Automatic asset/goods/supply-chain tracking e.g. in combination with IoT Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 100 / 121
  95. 95. Smart contracts Use cases Smart contracts + Internet of Things (IoT) I Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 101 / 121
  96. 96. Smart contracts Use cases Smart contracts + Internet of Things (IoT) II 1 The possibly many goods movements could be automatically tracked by one or more interacting Smart Contracts 2 Departures and arrivals of goods may be detected by IoT sensors no way for the many involved actors to lie about quantities, or timings 3 SC could automatically perform payments as soon as movements are detected or refunds in case they are not 4 Founders, creditors, inspectors, and end-users can always know the distribution path of products they just have to agree on the policy enforced by the SCs code The idea main idea Delegating trust-critical decisions to transparent, and trustable SW agents Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 102 / 121
  97. 97. Smart contracts Issues Smart Contracts are quite immature No privacy or secrets No randomness Inter-SC communication re-entrancy Immutability Control flow pure reactiveness Disembodiment Lack of concurrency Granularity of the computational cost Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 103 / 121
  98. 98. Smart contracts Issues No privacy or secrets Notice that Every information ever published on the blockchain stays on the blockchain The private state of a smart contract is not secret Pseudo-anonymity can be broken with statistics or machine learning Illegal/anti-ethic behaviour can be revealed years later ! No secret voting?! Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 104 / 121
  99. 99. Smart contracts Issues Poor randomness Notice that It is difficult to achieve (pseudo-)randomness because of the lack non-determinism Real randomness cannot be employed (replicas would diverge) Most of the blocks observable information is manipulable by miners e.g. timestamp, height, hash, etc. Not trivial way to find a non-manipulable random seed ! No lottery?! Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 105 / 121
  100. 100. Smart contracts Issues Smart contract inter-communication Notice that SCs are essentially objects communicating by means of synchronous method calls the control flow originating from a user may traverse more than one SC the caller waits for the callee unattended re-entrancy if difficult to avoid [6, 24] and it may lead to undesired behavioural subtleties and frauds [17] ! is OOP the best programming paradigm? Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 106 / 121
  101. 101. Smart contracts Issues Impossibility to fix bugs Notice that SC code is immutable. Immutability is both a blessing and a curse. Buggy/fraudulent contracts cannot be fixed, updated, replaced, or un-deployed they will remain so, wasting miners resources Paramount importance of correct-design and formal validation a problem per se in Turing-complete languages Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 107 / 121
  102. 102. Smart contracts Issues Lack of pro-activeness Notice that SCs are purely reactive computational entities They always need to borrow some user’s control flow They are time-aware but not time-reactive ! They cannot schedule or postpone computations no periodic computation (e.g. payment) Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 108 / 121
  103. 103. Smart contracts Issues Disembodiment [25] lack of concurrency Notice that Computation is logically located everywhere and execution is strictly sequential Independent computation cannot be executed concurrently Computations only making sense locally need to be replicated globally ! Smart contracts cannot be used to parallelise computations Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 109 / 121
  104. 104. Smart contracts Issues Granularity of computation-related costs Notice that Ethereum is not the first platform applying a price to computation: e.g. common practice on the Cloud, and the X-as-a-Service paradigm BTW, is the instruction-level cost granularity the better one? e.g. In implementing the publish-subscribe mechanism, it is publisher paying the higher price [14] Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 110 / 121
  105. 105. Do we need BCT? Do me or my company need the Blockchain? [4] LOL. Seriously? YES! If its just you or your company You should use a replicated DB Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 112 / 121
  106. 106. Do we need BCT? Do my company and our partner need the Blockchain? [4] Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 113 / 121
  107. 107. Blockchain and Smart Contracts Distributed System / Technologies Sistemi Distribuiti / Tecnologie Giovanni Ciatto Andrea Omicini giovanni.ciatto@unibo.it andrea.omicini@unibo.it Dipartimento di Informatica, Scienza e Ingegneria (DISI) Alma Mater Studiorum – Universit`a di Bologna Academic Year 2018/2019 Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 114 / 121
  108. 108. References References I [1] Proof of stake. https://en.bitcoin.it/wiki/Proof_of_Stake. [2] The tangle. https://iotatoken.com/IOTA_Whitepaper.pdf. [3] Three generations of blockchain. http://biccur.com/blog/2016/12/16/three-generations-of-blockchain. [4] When do you need blockchain? decision models. https://medium.com/@sbmeunier/ when-do-you-need-blockchain-decision-models-a5c40e7c9ba1. [5] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukoli´c, Sharon Weed Cocco, and Jason Yellick. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. Proceedings of the Thirteenth EuroSys Conference on - EuroSys ’18, pages 1–15, jan 2018. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 115 / 121
  109. 109. References References II [6] Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. A survey of attacks on Ethereum smart contracts (SoK). Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 10204 LNCS(July):164–186, 2017. [7] Pierre-Louis Aublin, Rachid Guerraoui, Nikola Kneˇzevi´c, Vivien Qu´ema, and Marko Vukoli´c. The Next 700 BFT Protocols. ACM Transactions on Computer Systems, 32(4):1–45, jan 2015. [8] Adam Back. Hashcash - A Denial of Service Counter-Measure. Http://Www.Hashcash.Org/Papers/Hashcash.Pdf, (August):1–10, 2002. [9] Eric A. Brewer. Towards robust distributed systems (abstract). In Proceedings of the Nineteenth Annual ACM Symposium on Principles of Distributed Computing, PODC ’00, pages 7–, New York, NY, USA, 2000. ACM. [10] Christian Cachin and Marko Vukoli´c. Blockchain Consensus Protocols in the Wild. jul 2017. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 116 / 121
  110. 110. References References III [11] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance and proactive recovery. ACM Transactions on Computer Systems, 20(4):398–461, 2002. [12] Bernadette Charron-Bost, Fernando Pedone, and Andr´e Schiper, editors. Replication: Theory and Practice. Springer-Verlag, Berlin, Heidelberg, 2010. [13] Lin Chen, Lei Xu, Nolan Shah, Zhimin Gao, Yang Lu, and Weidong Shi. On security analysis of proof-of-elapsed-time (poet). In Paul Spirakis and Philippas Tsigas, editors, Stabilization, Safety, and Security of Distributed Systems, pages 282–297, Cham, 2017. Springer International Publishing. [14] Giovanni Ciatto, Stefano Mariani, and Andrea Omicini. Blockchain for trustworthy coordination: A first study with Linda and Ethereum. In (Appearing on) 1st International Workshop on Block Chain Technologies 4 Multi-Agent Systems (BCT4MAS 2018), 2018. [15] John R Douceur. The sybil attack. In International workshop on peer-to-peer systems, pages 251–260. Springer, 2002. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 117 / 121
  111. 111. References References IV [16] John R. Douceur. The Sybil Attack. pages 251–260, 2002. [17] Quinn Dupont. Experiments in Algorithmic Governance : A history and ethnography of “ The DAO ,” a failed Decentralized Autonomous Organization. Bitcoin and Beyond, pages 1–18, 2017. [18] Ittay Eyal and Emin G¨un Sirer. Majority is not enough: Bitcoin mining is vulnerable. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 8437:436–454, 2014. [19] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. Journal of the ACM, 32(2):374–382, 1985. [20] Stuart Haber and W.Scott Stornetta. How to time-stamp a digital document. Journal of Cryptology, 3(2):99–111, 1991. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 118 / 121
  112. 112. References References V [21] Leslie Lamport. The Part-Time Parliament. ACM Transactions on Computer Sys-tems, 16(2):133–169, 1998. [22] Leslie Lamport, Benjamin C. Reed, Flavio P. Junqueira, Diego Ongaro, John Ousterhout, Michael a Olson, Keith Bostic, Margo Seltzer, Cynthia Dwork, Nancy Lynch, Larry Stockmeyer, Jim Shore, Fred B Schneider, Leslie Lamport, Miguel Castro, Barbara H Liskov, H.Zou, F.Jahanian, Leslie Lamport, Dahlia Malkhi, Lidong Zhou, X Zhang, D. Zagorodnov, M Hiltunen, Keith Marzullo, R.D. Schlichting, Navin Budhiraja, Keith Marzullo, Fred B Schneider, Sam Toueg, R. Al-Omari, Arun K. Somani, G. Manimaran, Flavio P. Junqueira, Benjamin C. Reed, Marco Serafini, Navin Budhiraja, Rachid Guerraoui, Andr´e Schiper, M. Pease, R. Shostak, Leslie Lamport, Dahlia Malkhi, Lidong Zhou, Lamport July, Barbara H Liskov, and James Cowling. In Search of an Understandable Consensus Algorithm. Atc ’14, 22(2):305–320, 2014. [23] Leslie Lamport, Robert Shostak, and Marshall Pease. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 4(3):382–401, 1982. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 119 / 121
  113. 113. References References VI [24] Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. Making Smart Contracts Smarter. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security - CCS’16, pages 254–269, New York, New York, USA, 2016. ACM Press. [25] Stefano Mariani and Andrea Omicini. TuCSoN on Cloud: An event-driven architecture for embodied/disembodied coordination. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 8286 LNCS(PART 2):285–294, 2013. [26] Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The Honey Badger of BFT Protocols. [27] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. Www.Bitcoin.Org, page 9, 2008. [28] Fred B. Schneider. Implementing Fault-tolerant Services Using the State Machine Approach: A Tutorial. ACM Comput. Surv., 22(4):299–319, 1990. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 120 / 121
  114. 114. References References VII [29] Yonatan Sompolinsky and A Zohar. Accelerating Bitcoin’s Transaction Processing. Fast Money Grows on Trees, Not Chains. IACR Cryptology ePrint Archive, 881:1–31, 2013. [30] Jo˜ao Sousa and Alysson Bessani. From Byzantine consensus to BFT state machine replication: A latency-optimal transformation. Proceedings - 9th European Dependable Computing Conference, EDCC 2012, pages 37–48, 2012. [31] Melanie Swan. Blockchain: Blueprint for a New Economy. O’Reilly Media, Inc., 1st edition, 2015. [32] Nick Szabo. Smart Contracts: Building Blocks for Digital Markets. Alamut.Com, (c):16, 1996. [33] Gavin Wood. Ethereum: a secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper, pages 1–32, 2014. Ciatto, Omicini (DISI, Univ. Bologna) Blockchain and Smart Contracts A.Y. 2018/2019 121 / 121

×