Smart contracts Definition, applications, and impact November 14 th - PowerPoint PPT Presentation

CONFIDENTIAL Smart contracts Definition, applications, and impact November 14 th Brussels, Finance Watch Workshop 2017

CONFIDENTIAL Distributed Systems: challenges • Network of U S E R • actors following instructions • connections for sending and receiving messages • to collectively offer • coherent service to users • Nodes may be reliable (following instructions) or unreliable (nonresponsive, crashing, faulty/lying) • Connections may be reliable or unreliable (failing, arbitrarily slow) D I S T R I B U T E D S Y S T E M Footnotes 2

DRAFT FOR REVIEW CONFIDENTIAL Distributed system properties and CAP Theorem • Consistency: Clients get same response, independent of node accessed • Availability: All clients get a response eventually (fast enough) • Partition tolerance: All accessible nodes respond, even when internal communication is impossible (slow) Consistency, Availability and Partition tolerance Theorem: • Assume: All compute nodes reliable ; network connections unreliable • Cannot simultaneously have • Consistency: Every node gives the same answer. • Availability: Every node gives an answer eventually. • Partition tolerance: The system tolerates network partitions. • Inherent trade-off: • More consistency, less availability or less partition tolerance • More availability, less consistency or less partition tolerance • More partition tolerance, less consistency or less availability Footnotes 3

CONFIDENTIAL Classification of Blockchain / Distributed Ledger Technology • Blockchain and distributed ledger technology (DLT) are classified by two features: • Permissioned DLT or permissionless blockchain • Public blockchains or private/privacy keeping DLT • Public blockchain such as bitcoin or Ethereum have the following features: • Every body can participate without any access restrictions • Everybody has a full copy of all transactions or program code • No data stays private or privacy is kept • Cryptographically signed • All data is saved in the log append principle, i.e. data is only added but not erased • The central mechanism for consistency is organizing it into timestamp blocks • The mechanism for trustless verification is the consensus method • Footnotes 4

CONFIDENTIAL How does Bitcoin Blockchain work? • Anybody can run a bitcoin node: No authentication, permionless • Each node stores complete blockchain • Event: Payment (“ A transfers n bitcoins to B ”) • P2P communication: Gossip — tell all your neighbors about a new block • Protocol: No double spending; only owner can transfer • Authentication: public key cryptography (digital signature) • Consensus: Nakamoto — block giving longest chain is ``the’’ updated blockchain • Block validation: Check that block hash is correct and that protocol is obeyed — easy! • Block generation: Find nonce such that hash has n leading zeros — hard! Get money for it. Footnotes 5

DRAFT FOR REVIEW CONFIDENTIAL How does Ethereum work? • Ethereum is public blockchain similar to bitcoin network • Ethereum nodes all run a computer (called Ethereum virtual machine (EVM) similar to the Java virtual machine) • Ethereum has programming language called solidity to code “smart contracts” / programs which describe the business transaction between parties (nodes on the network) • Ethereum uses a blockchain to validate, update and execute the code by the same mechanism as in blockchain: • Every node has the same distributed ledger, i.e. has full history of all transactions (of code) • A consensus protocol validates the tranactions • A mining mechanism incl. currencies incentives the nodes to perform the validations • Smart contracts “consume” ethers/gas the ledgers internal currencies • Ethereum is basically a distributed computer with public distributed ledger Footnotes 6

DRAFT FOR REVIEW CONFIDENTIAL How does a DLT like Fabric or Corda work? • Recording and managing the evolution of agreements and between two or more identifiable parties in a way that is grounded in existing legal constructs and compatible with existing and emerging regulation • Choreographing workflow between firms without a central controller • Supporting consensus between firms at the level of individual deals, not a global system • Supporting the inclusion of regulatory and supervisory observer nodes • Validating transactions solely between parties to the transaction. • Supporting a variety of consensus mechanisms. • Restricting access to the data within an agreement to only those explicitly entitled or logically privileged to it. • There is no blockchain! • Corda and Fabric both possess an turing complete programming language • Corda has a (reduced) Java virtual machine to execute the Kotlin code of corda • Both are released as open source under Hyperledger (Linux foundation chapter) • Both are developed by commercial companies (Fabric= IBM, Corda=R3CEV) • Needs some trust in the network participants. • Small networks (few nodes, 1-2 notaries) are very similar to databases with no double spend Footnotes 7

DRAFT FOR REVIEW CONFIDENTIAL DLT like Corda/Fabric Node 1 Node 4 JVM Contract 1 Code JVM Local Syncroni Code SQL data Local sation Syncroni base SQL data rules sation base Notary rules Contract 1 Contract 1 Contract 2 Contract 3 JVM Contract 4 Code Contract 3 Local Contract 4 Contract 2 Syncroni SQL data sation base Node 3 rules Node 2 JVM Contract 1 Code JVM Local Syncroni Code Contract 2 SQL data Local sation Syncroni Contract 3 base SQL data rules sation base rules Contract 4 Contract 4 Contract 2 Contract 3 Footnotes 8

CONFIDENTIAL Smart contracts are neither! • Smart contract = “self-executing” contract • The notion on smart contract is generally understood as self-execution contract or automation of contract execution • The terms was already coined by Nick Szabo in 1994 • No proper definition exists and this term is mostly used for code in Ethereum or DLTs • Smart contract = program: • Has the data included and the execution logic • Implicit contract plus coded joint strategy for executing it • No separation of protocol (specification) and execution • Receives messages (responds to events) • Sends messages (generates events) • Cannot be stopped (!) • Popular blockchain/DLT systems written general purpose programming (turning complete) such as Java and derivatives • All issues and risk of normal computer networks exists Footnotes 9

CONFIDENTIAL Smart contracts are executed on virtual machines which brings in great risk • Blockchains (BC) such as Ethereum and some DLTs are virtual computers which run virtual machine • There huge programming language risk due the vulnerability of the Virtual Machines (EVM/JVM) • Exception handling (deliberate crashing) • Default methods (multi sig exploit) • Reentrancy (TheDao hack) • Programs are written in Turing complete programming languages: • Expressive • Unpredictable even with full access to the source code (Rice, 1953) • Cannot be formally verified • Time-stamp dependence: Who controls the clock? Footnotes 10

CONFIDENTIAL What Contract (protocols) • A good contract model is a protocol which specifies obligatory, permissible or prohibited actions/events by parties • Passive protocol of sequence of events which represents the actions of parties • An event is digital representation of real world action, transaction, etc. • Protocol is state machine which reacts to events changes its states • The change of the state, i.e. is a permitted or obligatory action actively performed by an party, i.e. contract execution • Bitcoin protocol: • Only owner may transfer amount • Transfer amount must be less than owner’s balance • No double spending (= bitcoin is a linear resource) • Bitcoin has only one fixed contract Footnotes 11

CONFIDENTIAL Making digital contracts and protocols work (and more similar to bitcoin system) • Contract specification language (CSL): • Passive protocol of finite set of objects and language combinators • Protocol react to events. Events need to executed/assigned by the agents • No combination of contract specification (who does what) and contract execution • Events are linked in a one-to-one relationship to contracts (linearity and monotonicity) • The language is domain specific language,restricted and not a Turing complete language • Usage of deontic modalities (logic) and logic: Full logic system • Formal verification, i.e. proof if two different contract specification codes are identical or not • Usage of software robots to generate the code to run on DLT/BC • The code written in the CSL/DSL is automatically transformed to “computer code” • Each language combinator can be proven to work and the entire code can be proven to work • Very similar to model based design used for critical systems, e.g. aerospace industry Footnotes 12