Slide 1

Slide 1 text

mchakravarty TacticalGrace justtesting.org Manuel M T Chakravarty Tweag I/O & IOHK Blockchains Are Functional

Slide 2

Slide 2 text

Blockchains Distributed immutable ledger

Slide 3

Slide 3 text

Wallets

Slide 4

Slide 4 text

Alice Bob Charlie Wallets

Slide 5

Slide 5 text

Alice Bob Charlie ₳100 ₳10 ₳52 Wallets

Slide 6

Slide 6 text

Alice Bob Charlie ₳100 ₳10 ₳52 ₳42 Wallets

Slide 7

Slide 7 text

Alice Bob Charlie ₳58 ₳52 ₳52 Wallets

Slide 8

Slide 8 text

Alice Bob Charlie ₳58 ₳52 ₳52 ₳20 Wallets

Slide 9

Slide 9 text

Alice Bob Charlie ₳58 ₳32 ₳72 Wallets

Slide 10

Slide 10 text

Alice Bob Charlie ₳58 ₳32 ₳72 Cheating? Wallets

Slide 11

Slide 11 text

Alice Bob Charlie ₳100 ₳10 ₳52

Slide 12

Slide 12 text

Alice Bob Charlie ₳100 ₳10 ₳52 Alice Bob Charlie Central Authority (Ledger) Bank

Slide 13

Slide 13 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) Bank

Slide 14

Slide 14 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) Bank

Slide 15

Slide 15 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) ₳42 to Bob Bank

Slide 16

Slide 16 text

Alice Bob Charlie Alice ₳58 Bob ₳52 Charlie ₳52 Central Authority (Ledger) Bank

Slide 17

Slide 17 text

Alice Bob Charlie Alice ₳58 Bob ₳52 Charlie ₳52 Central Authority (Ledger) ₳20 to Charlie Bank

Slide 18

Slide 18 text

Alice Bob Charlie Alice ₳58 Bob ₳32 Charlie ₳72 Central Authority (Ledger) Bank

Slide 19

Slide 19 text

Alice Bob Charlie Alice ₳58 Bob ₳32 Charlie ₳72 Central Authority (Ledger) Ordering? Bank

Slide 20

Slide 20 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) Bank

Slide 21

Slide 21 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) ₳20 to Charlie Bank

Slide 22

Slide 22 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) ₳20 to Charlie Invalid! Bank

Slide 23

Slide 23 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Authority (Ledger) Trust in central authority? Bank

Slide 24

Slide 24 text

Alice Bob Charlie Alice ₳0 Bob ₳0 Charlie ₳162 Authority (Ledger) Trust in central authority? Bank

Slide 25

Slide 25 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Cryptographic Ledger (Consensus) Blockchain

Slide 26

Slide 26 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Cryptographic Ledger (Consensus) ₳42 to Bob Blockchain

Slide 27

Slide 27 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 Cryptographic Ledger (Consensus) Blockchain

Slide 28

Slide 28 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 Cryptographic Ledger (Consensus) Transaction Blockchain

Slide 29

Slide 29 text

Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 Cryptographic Ledger (Consensus) ₳20 to Charlie Transaction Blockchain

Slide 30

Slide 30 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳20 Cryptographic Ledger (Consensus) Alice Bob Charlie Transaction Blockchain

Slide 31

Slide 31 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳20 Cryptographic Ledger (Consensus) Alice Bob Charlie Immutable, verifiable log Transaction Blockchain

Slide 32

Slide 32 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳20 Cryptographic Ledger (Consensus) Alice Bob Charlie How about other information? Transaction Blockchain

Slide 33

Slide 33 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳20 Cryptographic Ledger (Consensus) Alice Bob Charlie

Slide 34

Slide 34 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳20 Cryptographic Ledger (Consensus) Alice Bob Charlie Distributed Tamper-Resistant Store

Slide 35

Slide 35 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 Meal B㱺C ₳20 Drinks Cryptographic Ledger (Consensus) Alice Bob Charlie Distributed Tamper-Resistant Store

Slide 36

Slide 36 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) Alice Bob Charlie Distributed Tamper-Resistant Store

Slide 37

Slide 37 text

Distributed Tamper-Resistant Store Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus)

Slide 38

Slide 38 text

Distributed Tamper-Resistant Store Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) In-Game Achievement; Type: …; Witness: …; Reward: …

Slide 39

Slide 39 text

Distributed Tamper-Resistant Store Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) In-Game Achievement; Type: …; Witness: …; Reward: … Trade Record; Item: ; Conditions: …

Slide 40

Slide 40 text

Distributed Tamper-Resistant Store Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) In-Game Achievement; Type: …; Witness: …; Reward: … Trade Record; Item: ; Conditions: … On-chain: validation

Slide 41

Slide 41 text

Distributed Tamper-Resistant Store Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) In-Game Achievement; Type: …; Witness: …; Reward: … Trade Record; Item: ; Conditions: … On-chain: validation Off-chain: coordination, processing & validation

Slide 42

Slide 42 text

Distributed Tamper-Resistant Store Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) In-Game Achievement; Type: …; Witness: …; Reward: … Trade Record; Item: ; Conditions: … On-chain: validation Off-chain: coordination, processing & validation We need a “smart contract” language!

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

secure and share important records, such as records of identity asset registries (land title, patient health records, educational certifications) monitoring and regulating markets combat tax fraud; streamline tax calculation & collection

Slide 45

Slide 45 text

Distributed Tamper-Resistant Store Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) In-Game Achievement; Type: …; Witness: …; Reward: … Trade Record; Item: ; Conditions: … On-chain: validation Off-chain: coordination, processing & validation We need a “smart contract” language!

Slide 46

Slide 46 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) On-chain: validation scripts Off-chain: coordination code Data Structure Programming Language

Slide 47

Slide 47 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) On-chain: validation scripts Off-chain: coordination code Data Structure Programming Language Server Client

Slide 48

Slide 48 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) On-chain: validation scripts Off-chain: coordination code Data Structure Programming Language Server Client Server

Slide 49

Slide 49 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) On-chain: validation scripts Off-chain: coordination code Data Structure Programming Language l l l Consensus

Slide 50

Slide 50 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) Data Structure Consensus l Proof of Work (PoW) Proof of Stake (PoS) Permissioned Ledger public public walled

Slide 51

Slide 51 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) Data Structure Consensus l Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Permissioned Ledger public public walled

Slide 52

Slide 52 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) Data Structure Consensus l Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Investment in the system Permissioned Ledger public public walled

Slide 53

Slide 53 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) Data Structure Consensus l Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Investment in the system Permissioned Ledger public public walled Authorization required

Slide 54

Slide 54 text

public blockchains Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Investment in the system

Slide 55

Slide 55 text

public blockchains Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Investment in the system active and highly sophisticated research area

Slide 56

Slide 56 text

public blockchains Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Investment in the system active and highly sophisticated research area financial incentive for attacks is very high

Slide 57

Slide 57 text

public blockchains Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Investment in the system active and highly sophisticated research area financial incentive for attacks is very high cryptocurrencies are a conceptually necessity

Slide 58

Slide 58 text

Cryptographic ledger Distributed, immutable, verifiable log data structure

Slide 59

Slide 59 text

Cryptographic ledger Distributed, immutable, verifiable log data structure On-chain & off-chain contract code On-chain transaction validation & off-chain coordination

Slide 60

Slide 60 text

Cryptographic ledger Distributed, immutable, verifiable log data structure On-chain & off-chain contract code On-chain transaction validation & off-chain coordination Proof of Stake (PoS) Environmentally friendly, low-energy cryptographic proofs

Slide 61

Slide 61 text

Cryptographic ledger Distributed, immutable, verifiable log data structure On-chain & off-chain contract code On-chain transaction validation & off-chain coordination Proof of Stake (PoS) Environmentally friendly, low-energy cryptographic proofs High assurance development Formal methods, types, validation

Slide 62

Slide 62 text

Blockchain Layers

Slide 63

Slide 63 text

Blockchain Layers Network Layer transaction & block transport

Slide 64

Slide 64 text

Blockchain Layers Network Layer transaction & block transport conventional networking

Slide 65

Slide 65 text

Blockchain Layers Network Layer Consensus Layer transaction & block transport PoW, PoS, etc protocol conventional networking

Slide 66

Slide 66 text

Blockchain Layers Network Layer Consensus Layer transaction & block transport PoW, PoS, etc protocol conventional networking sophisticated cryptographic protocols

Slide 67

Slide 67 text

Blockchain Layers Network Layer Consensus Layer Ledger Layer transaction & block transport PoW, PoS, etc protocol ledger rules conventional networking sophisticated cryptographic protocols

Slide 68

Slide 68 text

Blockchain Layers Network Layer Consensus Layer Ledger Layer transaction & block transport PoW, PoS, etc protocol ledger rules conventional networking sophisticated cryptographic protocols accounting & transaction validation

Slide 69

Slide 69 text

Blockchain Layers Network Layer Consensus Layer Ledger Layer Contract Layer transaction & block transport PoW, PoS, etc protocol ledger rules user-defined validation & coordination conventional networking sophisticated cryptographic protocols accounting & transaction validation

Slide 70

Slide 70 text

Blockchain Layers Network Layer Consensus Layer Ledger Layer Contract Layer transaction & block transport PoW, PoS, etc protocol ledger rules user-defined validation & coordination conventional networking sophisticated cryptographic protocols accounting & transaction validation domain-specific

Slide 71

Slide 71 text

Blockchain Layers Network Layer Consensus Layer Ledger Layer Contract Layer conventional networking sophisticated cryptographic protocols accounting & transaction validation domain-specific }protocol formalisation (semi-)formal reasoning type systems property-based testing

Slide 72

Slide 72 text

Blockchain Layers Network Layer Consensus Layer Ledger Layer Contract Layer conventional networking sophisticated cryptographic protocols accounting & transaction validation domain-specific }protocol formalisation (semi-)formal reasoning type systems property-based testing functional contract languages contract formalisation certified compilation DSLs

Slide 73

Slide 73 text

Projects Principled approaches

Slide 74

Slide 74 text

æternity Cardano Concordium Libra Tezos Zilliqa

Slide 75

Slide 75 text

Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml C++ & OCaml æternity Cardano Concordium Libra Tezos Zilliqa Implementation and Reasoning Languages

Slide 76

Slide 76 text

Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml C++ & OCaml Agda, Coq & Isabelle Coq TBA Coq Coq æternity Cardano Concordium Libra Tezos Zilliqa Implementation and Reasoning Languages

Slide 77

Slide 77 text

Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml C++ & OCaml Agda, Coq & Isabelle Coq TBA Coq Coq Sophia (OCaml-like) Haskell Oak (Elm-like) Move (linear, effect control) Liquidity (OCaml-like) Scilla (effect control) æternity Cardano Concordium Libra Tezos Zilliqa Implementation and Reasoning Languages Smart Contract Languages

Slide 78

Slide 78 text

Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml C++ & OCaml Agda, Coq & Isabelle Coq TBA Coq Coq Sophia (OCaml-like) Haskell Oak (Elm-like) Move (linear, effect control) Liquidity (OCaml-like) Scilla (effect control) æternity Cardano Concordium Libra Tezos Zilliqa Implementation and Reasoning Languages Smart Contract Languages CSL (Deon Digital)

Slide 79

Slide 79 text

Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml C++ & OCaml Agda, Coq & Isabelle Coq TBA Coq Coq Sophia (OCaml-like) Haskell Oak (Elm-like) Move (linear, effect control) Liquidity (OCaml-like) Scilla (effect control) æternity Cardano Concordium Libra Tezos Zilliqa Implementation and Reasoning Languages Smart Contract Languages DAML (Digital Asset) CSL (Deon Digital)

Slide 80

Slide 80 text

Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml C++ & OCaml Agda, Coq & Isabelle Coq TBA Coq Coq Sophia (OCaml-like) Haskell Oak (Elm-like) Move (linear, effect control) Liquidity (OCaml-like) Scilla (effect control) æternity Cardano Concordium Libra Tezos Zilliqa Implementation and Reasoning Languages Smart Contract Languages DAML (Digital Asset) Marlowe (IOHK) CSL (Deon Digital)

Slide 81

Slide 81 text

Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml C++ & OCaml Agda, Coq & Isabelle Coq TBA Coq Coq Sophia (OCaml-like) Haskell Oak (Elm-like) Move (linear, effect control) Liquidity (OCaml-like) Scilla (effect control) æternity Cardano Concordium Libra Tezos Zilliqa Implementation and Reasoning Languages Smart Contract Languages DAML (Digital Asset) Simplicity (BlockStream) Marlowe (IOHK) CSL (Deon Digital)

Slide 82

Slide 82 text

Cardano https://cardano.org/

Slide 83

Slide 83 text

Cardano https://cardano.org/ Proof of Stake (PoS)

Slide 84

Slide 84 text

Cardano https://cardano.org/ Proof of Stake (PoS) FP and FM

Slide 85

Slide 85 text

Cardano https://cardano.org/ Proof of Stake (PoS) FP and FM Research driven

Slide 86

Slide 86 text

Cardano https://cardano.org/ Proof of Stake (PoS) FP and FM & other universities Research driven

Slide 87

Slide 87 text

Development From research to production

Slide 88

Slide 88 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 89

Slide 89 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 90

Slide 90 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 91

Slide 91 text

No content

Slide 92

Slide 92 text

Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol Aggelos Kiayias Alexander Russell† Bernardo David‡ Roman Oliynykov§ August 21, 2017 Abstract We present “Ouroboros”, the first blockchain protocol based on proof of stake with rig- orous security guarantees. We establish security properties for the protocol comparable to those achieved by the bitcoin blockchain protocol. As the protocol provides a “proof of stake” blockchain discipline, it o ers qualitative e ciency advantages over blockchains based on proof of physical resources (e.g., proof of work). We also present a novel reward mechanism for in- centivizing Proof of Stake protocols and we prove that, given this mechanism, honest behavior is an approximate Nash equilibrium, thus neutralizing attacks such as selfish mining. We also present initial evidence of the practicality of our protocol in real world settings by providing experimental results on transaction confirmation and processing. 1 Introduction A primary consideration regarding the operation of blockchain protocols based on proof of work (PoW)—such as bitcoin [30]—is the energy required for their execution. At the time of this writ- ing, generating a single block on the bitcoin blockchain requires a number of hashing operations exceeding 260, which results in striking energy demands. Indeed, early calculations indicated that the energy requirements of the protocol were comparable to that of a small country [32]. This state of a airs has motivated the investigation of alternative blockchain protocols that would obviate the need for proof of work by substituting it with another, more energy e cient, mechanism that can provide similar guarantees. It is important to point out that the proof of work mechanism of bitcoin facilitates a type of randomized “leader election” process that elects one of the miners to issue the next block. Furthermore, provided that all miners follow the protocol, this selection is performed in a randomized fashion proportionally to the computational power of each miner. (Deviations from the protocol may distort this proportionality as exemplified by “selfish mining” strategies [21, 38].) A natural alternative mechanism relies on the notion of “proof of stake” (PoS). Rather than miners investing computational resources in order to participate in the leader election process, they instead run a process that randomly selects one of them proportionally to the stake that each possesses according to the current blockchain ledger. University of Edinburgh and IOHK. [email protected]. Work partly performed while at the National and Kapodistrian University of Athens, supported by ERC project CODAMODA #259152. Work partly supported by H2020 Project #653497, PANORAMIX. † University of Connecticut. [email protected]. ‡ Aarhus University and IOHK, [email protected]. Work partly supported by European Research Council Starting Grant 279447. § IOHK, [email protected]. 1

Slide 93

Slide 93 text

Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol Aggelos Kiayias Alexander Russell† Bernardo David‡ Roman Oliynykov§ August 21, 2017 Abstract We present “Ouroboros”, the first blockchain protocol based on proof of stake with rig- orous security guarantees. We establish security properties for the protocol comparable to those achieved by the bitcoin blockchain protocol. As the protocol provides a “proof of stake” blockchain discipline, it o ers qualitative e ciency advantages over blockchains based on proof of physical resources (e.g., proof of work). We also present a novel reward mechanism for in- centivizing Proof of Stake protocols and we prove that, given this mechanism, honest behavior is an approximate Nash equilibrium, thus neutralizing attacks such as selfish mining. We also present initial evidence of the practicality of our protocol in real world settings by providing experimental results on transaction confirmation and processing. 1 Introduction A primary consideration regarding the operation of blockchain protocols based on proof of work (PoW)—such as bitcoin [30]—is the energy required for their execution. At the time of this writ- ing, generating a single block on the bitcoin blockchain requires a number of hashing operations exceeding 260, which results in striking energy demands. Indeed, early calculations indicated that the energy requirements of the protocol were comparable to that of a small country [32]. This state of a airs has motivated the investigation of alternative blockchain protocols that would obviate the need for proof of work by substituting it with another, more energy e cient, mechanism that can provide similar guarantees. It is important to point out that the proof of work mechanism of bitcoin facilitates a type of randomized “leader election” process that elects one of the miners to issue the next block. Furthermore, provided that all miners follow the protocol, this selection is performed in a randomized fashion proportionally to the computational power of each miner. (Deviations from the protocol may distort this proportionality as exemplified by “selfish mining” strategies [21, 38].) A natural alternative mechanism relies on the notion of “proof of stake” (PoS). Rather than miners investing computational resources in order to participate in the leader election process, they instead run a process that randomly selects one of them proportionally to the stake that each possesses according to the current blockchain ledger. University of Edinburgh and IOHK. [email protected]. Work partly performed while at the National and Kapodistrian University of Athens, supported by ERC project CODAMODA #259152. Work partly supported by H2020 Project #653497, PANORAMIX. † University of Connecticut. [email protected]. ‡ Aarhus University and IOHK, [email protected]. Work partly supported by European Research Council Starting Grant 279447. § IOHK, [email protected]. 1 Proof-of-Stake Sidechains Peter Gaˇ zi1, Aggelos Kiayias1,2, and Dionysis Zindros1,3 1 IOHK 2 University of Edinburgh 3 National and Kapodistrian University of Athens December 18, 2018 Abstract. Sidechains have long been heralded as the key enabler of blockchain scalability and inter- operability. However, no modeling of the concept or a provably secure construction has so far been attempted. We provide the first formal definition of what a sidechain system is and how assets can be moved between sidechains securely. We put forth a security definition that augments the known transaction ledger properties of persistence and liveness to hold across multiple ledgers and enhance them with a new “firewall” security property which safeguards each blockchain from its sidechains, limiting the impact of an otherwise catastrophic sidechain failure. We then provide a sidechain construction that is suitable for proof-of-stake (PoS) sidechain systems. As an exemplary concrete instantiation we present our construction for an epoch-based PoS system consistent with Ouroboros (Crypto 2017), the PoS blockchain protocol used in Cardano which is one of the largest pure PoS systems by market capitalisation, and we also comment how the construction can be adapted for other protocols such as Ouroboros Praos (Eurocrypt 2018), Ouroboros Genesis (CCS 2018), Snow White and Algorand. An important feature of our construction is merged-staking that prevents “goldfinger” attacks against a sidechain that is only carrying a small amount of stake. An important technique for pegging chains that we use in our construction is cross-chain certification which is facilitated by a novel cryptographic primitive we introduce called ad-hoc threshold multisignatures (ATMS) which may be of independent interest. We show how ATMS can be securely instantiated by regular and aggregate digital signatures as well as succinct arguments of knowledge such as STARKs and bulletproofs with varying degrees of storage e ciency. 1 Introduction Blockchain protocols and their most prominent application so far, cryptocurrencies like Bitcoin [27], have been gaining increasing popularity and acceptance by a wider community. While enjoying wide adoption, there are several fundamental open questions remaining to be resolved that include (i) Interoperability: How can di↵erent blockchains interoperate and exchange assets or other data? (ii) Scalability: How can blockchain protocols scale, especially proportionally to the number of participating nodes? (iii) Upgradability: How can a deployed blockchain protocol codebase evolve to support a new functionality, or correct an implementation problem? The main function of a blockchain protocol is to organise application data into blocks so that a set of nodes that evolves over time can arrive eventually to consensus about the sequence of events that took place. The consensus component can be achieved in a number of ways, the most popular is using proof-of-work [16] (cf. [27,17]), while a promising alternative is to use proof-of-stake (cf. [26,20,5,13]). Application data typically consists of transactions indicating some transfer of value as in the case of Bitcoin [27]. The transfer of value can be conditioned on arbitrary predicates called smart contracts such as, for example, in Ethereum [11,31]. The conditions used to validate transactions depend on local blockchain events according to the view of each node and they typically cannot be dependent on other blockchain sessions. Being able to perform operations across blockchains, for instance from a main blockchain such as Bitcoin to a “sidechain” that has some enhanced functionality, has been frequently considered a fundamental technology enabler in the blockchain space.4 4 See e.g., https://blockstream.com/technology/ and [1].

Slide 94

Slide 94 text

Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol Aggelos Kiayias Alexander Russell† Bernardo David‡ Roman Oliynykov§ August 21, 2017 Abstract We present “Ouroboros”, the first blockchain protocol based on proof of stake with rig- orous security guarantees. We establish security properties for the protocol comparable to those achieved by the bitcoin blockchain protocol. As the protocol provides a “proof of stake” blockchain discipline, it o ers qualitative e ciency advantages over blockchains based on proof of physical resources (e.g., proof of work). We also present a novel reward mechanism for in- centivizing Proof of Stake protocols and we prove that, given this mechanism, honest behavior is an approximate Nash equilibrium, thus neutralizing attacks such as selfish mining. We also present initial evidence of the practicality of our protocol in real world settings by providing experimental results on transaction confirmation and processing. 1 Introduction A primary consideration regarding the operation of blockchain protocols based on proof of work (PoW)—such as bitcoin [30]—is the energy required for their execution. At the time of this writ- ing, generating a single block on the bitcoin blockchain requires a number of hashing operations exceeding 260, which results in striking energy demands. Indeed, early calculations indicated that the energy requirements of the protocol were comparable to that of a small country [32]. This state of a airs has motivated the investigation of alternative blockchain protocols that would obviate the need for proof of work by substituting it with another, more energy e cient, mechanism that can provide similar guarantees. It is important to point out that the proof of work mechanism of bitcoin facilitates a type of randomized “leader election” process that elects one of the miners to issue the next block. Furthermore, provided that all miners follow the protocol, this selection is performed in a randomized fashion proportionally to the computational power of each miner. (Deviations from the protocol may distort this proportionality as exemplified by “selfish mining” strategies [21, 38].) A natural alternative mechanism relies on the notion of “proof of stake” (PoS). Rather than miners investing computational resources in order to participate in the leader election process, they instead run a process that randomly selects one of them proportionally to the stake that each possesses according to the current blockchain ledger. University of Edinburgh and IOHK. [email protected]. Work partly performed while at the National and Kapodistrian University of Athens, supported by ERC project CODAMODA #259152. Work partly supported by H2020 Project #653497, PANORAMIX. † University of Connecticut. [email protected]. ‡ Aarhus University and IOHK, [email protected]. Work partly supported by European Research Council Starting Grant 279447. § IOHK, [email protected]. 1 Proof-of-Stake Sidechains Peter Gaˇ zi1, Aggelos Kiayias1,2, and Dionysis Zindros1,3 1 IOHK 2 University of Edinburgh 3 National and Kapodistrian University of Athens December 18, 2018 Abstract. Sidechains have long been heralded as the key enabler of blockchain scalability and inter- operability. However, no modeling of the concept or a provably secure construction has so far been attempted. We provide the first formal definition of what a sidechain system is and how assets can be moved between sidechains securely. We put forth a security definition that augments the known transaction ledger properties of persistence and liveness to hold across multiple ledgers and enhance them with a new “firewall” security property which safeguards each blockchain from its sidechains, limiting the impact of an otherwise catastrophic sidechain failure. We then provide a sidechain construction that is suitable for proof-of-stake (PoS) sidechain systems. As an exemplary concrete instantiation we present our construction for an epoch-based PoS system consistent with Ouroboros (Crypto 2017), the PoS blockchain protocol used in Cardano which is one of the largest pure PoS systems by market capitalisation, and we also comment how the construction can be adapted for other protocols such as Ouroboros Praos (Eurocrypt 2018), Ouroboros Genesis (CCS 2018), Snow White and Algorand. An important feature of our construction is merged-staking that prevents “goldfinger” attacks against a sidechain that is only carrying a small amount of stake. An important technique for pegging chains that we use in our construction is cross-chain certification which is facilitated by a novel cryptographic primitive we introduce called ad-hoc threshold multisignatures (ATMS) which may be of independent interest. We show how ATMS can be securely instantiated by regular and aggregate digital signatures as well as succinct arguments of knowledge such as STARKs and bulletproofs with varying degrees of storage e ciency. 1 Introduction Blockchain protocols and their most prominent application so far, cryptocurrencies like Bitcoin [27], have been gaining increasing popularity and acceptance by a wider community. While enjoying wide adoption, there are several fundamental open questions remaining to be resolved that include (i) Interoperability: How can di↵erent blockchains interoperate and exchange assets or other data? (ii) Scalability: How can blockchain protocols scale, especially proportionally to the number of participating nodes? (iii) Upgradability: How can a deployed blockchain protocol codebase evolve to support a new functionality, or correct an implementation problem? The main function of a blockchain protocol is to organise application data into blocks so that a set of nodes that evolves over time can arrive eventually to consensus about the sequence of events that took place. The consensus component can be achieved in a number of ways, the most popular is using proof-of-work [16] (cf. [27,17]), while a promising alternative is to use proof-of-stake (cf. [26,20,5,13]). Application data typically consists of transactions indicating some transfer of value as in the case of Bitcoin [27]. The transfer of value can be conditioned on arbitrary predicates called smart contracts such as, for example, in Ethereum [11,31]. The conditions used to validate transactions depend on local blockchain events according to the view of each node and they typically cannot be dependent on other blockchain sessions. Being able to perform operations across blockchains, for instance from a main blockchain such as Bitcoin to a “sidechain” that has some enhanced functionality, has been frequently considered a fundamental technology enabler in the blockchain space.4 4 See e.g., https://blockstream.com/technology/ and [1]. Marlowe: financial contracts on blockchain? Pablo Lamela Seijas[0000 0002 1730 1219] and Simon Thompson[0000 0002 2350 301X] School of Computing, University of Kent, Canterbury, UK 1 Introduction This paper explores the design of a domain specific language, Marlowe,12 targeted at the execution of financial contracts in the style of Peyton Jones, Eber and Seward [16] on blockchains. In doing this, we are required to refine the model of contracts in a number of ways in order to fit with a radically di↵erent context. Consider the following example of an “escrow” contract so that we can explain the motivation more concretely. The aim of this contract, written in functional pseudocode in the style of [16] involves three participants: alice, bob and carol. alice is to pay an amount of money to bob on receipt of goods from her. alice pays the money into escrow controlled by carol. There are two options for the money: if two out of the three participants agree to pay it to bob, that goes ahead; if, on the other hand, two of the participants opt to refund the money to alice, that is done instead. The outer primitive When waits until the condition – its first argument – becomes true; in this case, the condition is that either two participants choose refund or two participants choose pay. The second argument of the When is itself another Contract, which is performed after the condition of the When has been met, and it makes the payment if two participants chose pay, otherwise it redeems previous money commitments. (When (Or (two_chose alice bob carol refund) (two_chose alice bob carol pay)) (Choice (two_chose alice bob carol pay) (Pay alice bob AvailableMoney) redeem_original)) We discuss this particular example in more detail in Marlowe in Section 3 below; but it already gives us an example of how traditional contracts are fundamentally di↵erent from contracts that are meant to be run on top of the blockchain. In the traditional model, enforcement of the contract is the responsibility of the legal system. If alice does not pay the money into escrow, or carol chooses to keep it for herself, then they can be sued for the money ? This work is part of the Cardano project and is supported by IOHK, https://iohk.io 1 Named after Christopher Marlowe, the Elizabethan poet, dramatist and spy, who was born and educated in Canterbury, en.wikipedia.org/wiki/Christopher_Marlowe 2 Marlowe is available from https://github.com/input-output-hk/scdsl l IOHK Research Papers https://iohk.io/research/library/

Slide 95

Slide 95 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 96

Slide 96 text

∀∃⊢

Slide 97

Slide 97 text

∀∃⊢

Slide 98

Slide 98 text

∀∃⊢

Slide 99

Slide 99 text

∀∃⊢

Slide 100

Slide 100 text

∀∃⊢

Slide 101

Slide 101 text

∀∃⊢

Slide 102

Slide 102 text

∀∃⊢

Slide 103

Slide 103 text

∀∃⊢

Slide 104

Slide 104 text

∀∃⊢

Slide 105

Slide 105 text

∀∃⊢

Slide 106

Slide 106 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 107

Slide 107 text

λ τ

Slide 108

Slide 108 text

λ τ

Slide 109

Slide 109 text

λ τ Series of refinements (incremental, rollback, etc)

Slide 110

Slide 110 text

λ τ Series of refinements (incremental, rollback, etc) Persistence, networking, frontend interaction

Slide 111

Slide 111 text

λ τ Series of refinements (incremental, rollback, etc) Persistence, networking, frontend interaction Test against executable spec using property-based testing

Slide 112

Slide 112 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 113

Slide 113 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ Duncan Coutts @ PlutusFest 2018 https://youtu.be/wW1CI9zt1tg

Slide 114

Slide 114 text

Plutus Functional contracts

Slide 115

Slide 115 text

(Ledger)

Slide 116

Slide 116 text

Alice ₳100 Bob ₳10 Charlie ₳52 (Ledger)

Slide 117

Slide 117 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 (Ledger)

Slide 118

Slide 118 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 (Ledger)

Slide 119

Slide 119 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳2 Charlie ₳102 Accounts (Ledger)

Slide 120

Slide 120 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳2 Charlie ₳102 Accounts ₳100 Alice ₳10 Bob ₳52 Charlie (Ledger)

Slide 121

Slide 121 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳2 Charlie ₳102 Accounts ₳58 ₳42 ₳100 Alice ₳10 Bob ₳52 Charlie (Ledger)

Slide 122

Slide 122 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳2 Charlie ₳102 Accounts ₳58 ₳42 ₳10 ₳50 ₳2 ₳100 Alice ₳10 Bob ₳52 Charlie (Ledger)

Slide 123

Slide 123 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳2 Charlie ₳102 Accounts ₳58 ₳42 ₳10 ₳50 ₳2 ₳100 Alice ₳10 Bob ₳52 Charlie Dataflow Graph Charlie Charlie Bob Alice (Ledger)

Slide 124

Slide 124 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳2 Charlie ₳102 Accounts ₳58 ₳42 ₳10 ₳50 ₳2 ₳100 Alice ₳10 Bob ₳52 Charlie Dataflow Graph Charlie Charlie Bob Alice ₳52 (Ledger)

Slide 125

Slide 125 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳2 Charlie ₳102 Accounts ₳58 ₳42 ₳10 ₳50 ₳2 ₳100 Alice ₳10 Bob ₳52 Charlie Dataflow Graph Unspent Transaction Output (UTxO) Charlie Charlie Bob Alice ₳52 (Ledger)

Slide 126

Slide 126 text

Accounts Unspent Transaction Output (UTxO) Ledger Representation

Slide 127

Slide 127 text

Accounts Unspent Transaction Output (UTxO) Ledger Representation https://eprint.iacr.org/2018/262.pdf

Slide 128

Slide 128 text

Accounts UTxO Ledger

Slide 129

Slide 129 text

Accounts UTxO Ledger (computational)

Slide 130

Slide 130 text

Accounts UTxO functional imperative Ledger (computational)

Slide 131

Slide 131 text

Accounts UTxO functional imperative mutable shared state dataflow Ledger (computational)

Slide 132

Slide 132 text

What about the expressiveness of smart contracts?

Slide 133

Slide 133 text

What about the expressiveness of smart contracts? Bitcoin

Slide 134

Slide 134 text

What about the expressiveness of smart contracts? Bitcoin Ethereum

Slide 135

Slide 135 text

What about the expressiveness of smart contracts? Bitcoin Ethereum minimal

Slide 136

Slide 136 text

What about the expressiveness of smart contracts? Bitcoin Ethereum minimal enough rope

Slide 137

Slide 137 text

What about the expressiveness of smart contracts? Bitcoin Ethereum minimal enough rope actor model

Slide 138

Slide 138 text

What about the expressiveness of smart contracts? Bitcoin Ethereum minimal enough rope

Slide 139

Slide 139 text

What about the expressiveness of smart contracts? Bitcoin Ethereum minimal enough rope richer dataflow graph

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

No content

Slide 142

Slide 142 text

Input Output

Slide 143

Slide 143 text

Input Output

Slide 144

Slide 144 text

Input Output ν: Validator x: Value core

Slide 145

Slide 145 text

Input Output ν: Validator x: Value ρ: Redeemer core core

Slide 146

Slide 146 text

Input Output ν: Validator x: Value ρ: Redeemer ν(ρ) ≟ True core core

Slide 147

Slide 147 text

Input Output ν: Validator x: Value ρ: Redeemer ν(ρ) ≟ True ν: Validator x: Value ρ: Redeemer core core core core

Slide 148

Slide 148 text

Input Output ν: Validator x: Value ρ: Redeemer ν(ρ) ≟ True ν: Validator x: Value ρ: Redeemer δ: Data core core core core core

Slide 149

Slide 149 text

Input Output ν: Validator x: Value ρ: Redeemer ν(ρ) ≟ True ν: Validator x: Value ρ: Redeemer δ: Data σ: Tx core core core core core

Slide 150

Slide 150 text

Input Output ν: Validator x: Value ρ: Redeemer ν(ρ) ≟ True ν: Validator x: Value ρ: Redeemer ν(ρ, δ, σ, x) ≟ True δ: Data σ: Tx core core core core core

Slide 151

Slide 151 text

ν: Validator x: Value ρ: Redeemer ν(ρ, δ, σ, x) ≟ True δ: Data σ: Tx Extended UTxO core core core

Slide 152

Slide 152 text

ν: Validator x: Value ρ: Redeemer ν(ρ, δ, σ, x) ≟ True δ: Data σ: Tx Extended UTxO Greatly increases the expressive power of scripts core core core

Slide 153

Slide 153 text

ν: Validator x: Value ρ: Redeemer ν(ρ, δ, σ, x) ≟ True δ: Data σ: Tx Extended UTxO Greatly increases the expressive power of scripts Pure script execution core core core

Slide 154

Slide 154 text

ν: Validator x: Value ρ: Redeemer ν(ρ, δ, σ, x) ≟ True δ: Data σ: Tx Extended UTxO Greatly increases the expressive power of scripts Pure script execution core core core Agda formalisation ”Formal Investigation of the Extended UTxO Model”, TyDe19 [Melkonian/Swierstra/Chakravarty]

Slide 155

Slide 155 text

ν: Validator x: Value ρ: Redeemer ν(ρ , δ , σ, x) ≟ True δ: Data σ: Tx Pure script execution core core core

Slide 156

Slide 156 text

ν: Validator x: Value ρ: Redeemer ν(ρ , δ , σ, x) ≟ True δ: Data σ: Tx Pure script execution core core core

Slide 157

Slide 157 text

ν: Validator x: Value ρ: Redeemer ν(ρ , δ , σ, x) ≟ True δ: Data σ: Tx Pure script execution core core core } Purely functional expression

Slide 158

Slide 158 text

ν(ρ , δ , σ, x) ≟ True Pure script execution core core core } Purely functional expression For the same σ (transaction) and same x (value),

Slide 159

Slide 159 text

ν(ρ , δ , σ, x) ≟ True Pure script execution core core core } Purely functional expression For the same σ (transaction) and same x (value), We always get the same result

Slide 160

Slide 160 text

ν(ρ , δ , σ, x) ≟ True Pure script execution core core core } Purely functional expression For the same σ (transaction) and same x (value), We always get the same result For the same execution fee

Slide 161

Slide 161 text

ν(ρ , δ , σ, x) ≟ True Pure script execution core core core } Purely functional expression We can perfectly predict on-chain costs by off-chain profiling

Slide 162

Slide 162 text

ν(ρ , δ , σ, x) ≟ True Pure script execution core core core } Purely functional expression We can perfectly predict on-chain costs by off-chain profiling https://ethereum.stackexchange.com/

Slide 163

Slide 163 text

ν(ρ , δ , σ, x) ≟ True Pure script execution core core core } Purely functional expression We can perfectly predict on-chain costs by off-chain profiling https://ethereum.stackexchange.com/

Slide 164

Slide 164 text

core

Slide 165

Slide 165 text

core Everything on the chain is immutable — also code.

Slide 166

Slide 166 text

core Everything on the chain is immutable — also code. Validators may protect millions — literally!

Slide 167

Slide 167 text

core Everything on the chain is immutable — also code. Validators may protect millions — literally! Move fast and break things!

Slide 168

Slide 168 text

Plutus Core core

Slide 169

Slide 169 text

Plutus Core core not a bytecode typed FP calculus

Slide 170

Slide 170 text

Plutus Core core not a bytecode not a classic virtual machine typed FP calculus abstract machine interpreter

Slide 171

Slide 171 text

Plutus Core core small, powerful & old = well understood not a bytecode not a classic virtual machine typed FP calculus abstract machine interpreter System F⍵ μ

Slide 172

Slide 172 text

Plutus Core core

Slide 173

Slide 173 text

Plutus Core core Closely mirrored in the implementation

Slide 174

Slide 174 text

Plutus Core core Agda formalisation

Slide 175

Slide 175 text

Plutus Core core In progress: testing against Agda Agda formalisation

Slide 176

Slide 176 text

Plutus Core core In progress: testing against Agda Agda formalisation ”System F in Agda, for Fun and Profit”, MPC19 [Chapman/Kireev/Nester/Wadler]

Slide 177

Slide 177 text

Plutus Core core How do we generate it? In progress: testing against Agda Agda formalisation ”System F in Agda, for Fun and Profit”, MPC19 [Chapman/Kireev/Nester/Wadler]

Slide 178

Slide 178 text

λ functional programming

Slide 179

Slide 179 text

λ functional programming So, we can’t really use Solidity…

Slide 180

Slide 180 text

Let’s invent a new programming language!

Slide 181

Slide 181 text

Very resource and time consuming Let’s invent a new programming language!

Slide 182

Slide 182 text

Haskell

Slide 183

Slide 183 text

Haskell Expressive Vibrant community Powerful Mature libraries and tools Support material

Slide 184

Slide 184 text

No content

Slide 185

Slide 185 text

What does it take to write a smart contract application?

Slide 186

Slide 186 text

Simple crowdfunding

Slide 187

Slide 187 text

Simple crowdfunding 1. Payment into campaign until a payment deadline

Slide 188

Slide 188 text

Simple crowdfunding 1. Payment into campaign until a payment deadline 2. If funding goal reached, campaign owner can collect funds

Slide 189

Slide 189 text

Simple crowdfunding 1. Payment into campaign until a payment deadline 2. If funding goal reached, campaign owner can collect funds 3. If funding goal not reached, refunds can be obtained by contributors

Slide 190

Slide 190 text

Simple crowdfunding 1. Payment into campaign until a payment deadline 2. If funding goal reached, campaign owner can collect funds 3. If funding goal not reached, refunds can be obtained by contributors 4. If campaign owner does not collect by collection deadline, contributors can also obtain refunds

Slide 191

Slide 191 text

1. Payment into campaign until a payment deadline 2. If funding goal reached, campaign owner can collect funds 3. If funding goal not reached, refunds can be obtained by contributors 4. If campaign owner does not collect by collection deadline, contributors can also obtain refunds

Slide 192

Slide 192 text

pragma solidity ^0.4.6; contract WinnerTakesAll { uint minimumEntryFee; uint public deadlineProjects; uint public deadlineCampaign; uint public winningFunds; address public winningAddress; struct Project { address addr; string name; string url; uint funds; bool initialized; } … Solidity (on-chain) 1. Payment into campaign until a payment deadline 2. If funding goal reached, campaign owner can collect funds 3. If funding goal not reached, refunds can be obtained by contributors 4. If campaign owner does not collect by collection deadline, contributors can also obtain refunds

Slide 193

Slide 193 text

pragma solidity ^0.4.6; contract WinnerTakesAll { uint minimumEntryFee; uint public deadlineProjects; uint public deadlineCampaign; uint public winningFunds; address public winningAddress; struct Project { address addr; string name; string url; uint funds; bool initialized; } … Solidity (on-chain) var Web3 = require('web3'); var web3 = new Web3(); web3.setProvider(new web3.providers.HttpProvider(”http:… var accounts = web3.eth.accounts; accounts.forEach(function(v) { $(”#supportFrom”).append(”

Slide 194

Slide 194 text

pragma solidity ^0.4.6; contract WinnerTakesAll { uint minimumEntryFee; uint public deadlineProjects; uint public deadlineCampaign; uint public winningFunds; address public winningAddress; struct Project { address addr; string name; string url; uint funds; bool initialized; } … Solidity var Web3 = require('web3'); var web3 = new Web3(); web3.setProvider(new web3.providers.HttpProvider(”http:… var accounts = web3.eth.accounts; accounts.forEach(function(v) { $(”#supportFrom”).append(”

Slide 195

Slide 195 text

pragma solidity ^0.4.6; contract WinnerTakesAll { uint minimumEntryFee; uint public deadlineProjects; uint public deadlineCampaign; uint public winningFunds; address public winningAddress; struct Project { address addr; string name; string url; uint funds; bool initialized; } … Solidity var Web3 = require('web3'); var web3 = new Web3(); web3.setProvider(new web3.providers.HttpProvider(”http:… var accounts = web3.eth.accounts; accounts.forEach(function(v) { $(”#supportFrom”).append(”

Slide 196

Slide 196 text

pragma solidity ^0.4.6; contract WinnerTakesAll { uint minimumEntryFee; uint public deadlineProjects; uint public deadlineCampaign; uint public winningFunds; address public winningAddress; struct Project { address addr; string name; string url; uint funds; bool initialized; } … Solidity var Web3 = require('web3'); var web3 = new Web3(); web3.setProvider(new web3.providers.HttpProvider(”http:… var accounts = web3.eth.accounts; accounts.forEach(function(v) { $(”#supportFrom”).append(”

Slide 197

Slide 197 text

Solidity JavaScript off-chain (wallet) on-chain (transaction) two-level (staged) programming model ad hoc Legacy Edition

Slide 198

Slide 198 text

Solidity JavaScript off-chain (wallet) on-chain (transaction) two-level (staged) programming model ad hoc inconvenient Legacy Edition

Slide 199

Slide 199 text

Solidity JavaScript off-chain (wallet) on-chain (transaction) two-level (staged) programming model ad hoc inconvenient complex Legacy Edition

Slide 200

Slide 200 text

Solidity JavaScript off-chain (wallet) on-chain (transaction) two-level (staged) programming model ad hoc inconvenient complex fragile Legacy Edition

Slide 201

Slide 201 text

off-chain (wallet) on-chain (transaction) two-level (staged) programming model Legacy Edition

Slide 202

Slide 202 text

off-chain (wallet) on-chain (transaction) two-level (staged) programming model Plutus

Slide 203

Slide 203 text

Haskell off-chain (wallet) on-chain (transaction) two-level (staged) programming model Plutus

Slide 204

Slide 204 text

Haskell (Plutus Tx) Haskell off-chain (wallet) on-chain (transaction) two-level (staged) programming model Plutus

Slide 205

Slide 205 text

Haskell (Plutus Tx) Haskell off-chain (wallet) on-chain (transaction) two-level (staged) programming model meta programming Plutus

Slide 206

Slide 206 text

Haskell (Plutus Tx) Haskell off-chain (wallet) on-chain (transaction) two-level (staged) programming model meta programming integrated Plutus

Slide 207

Slide 207 text

Haskell (Plutus Tx) Haskell off-chain (wallet) on-chain (transaction) two-level (staged) programming model meta programming integrated compact Plutus

Slide 208

Slide 208 text

Haskell (Plutus Tx) Haskell off-chain (wallet) on-chain (transaction) two-level (staged) programming model meta programming integrated compact robust Plutus

Slide 209

Slide 209 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do Haskell

Slide 210

Slide 210 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" Haskell

Slide 211

Slide 211 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey Haskell

Slide 212

Slide 212 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript Haskell

Slide 213

Slide 213 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) Haskell

Slide 214

Slide 214 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) value Haskell

Slide 215

Slide 215 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) value DataScript (Ledger.lifted ownPK) Haskell

Slide 216

Slide 216 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) value DataScript (Ledger.lifted ownPK) register (refundTrigger campaign) (refundHandler (Ledger.hashTx tx) campaign) contributionScript :: Campaign -> ValidatorScript Haskell

Slide 217

Slide 217 text

Haskell contributionScript :: Campaign -> ValidatorScript

Slide 218

Slide 218 text

Haskell contributionScript :: Campaign -> ValidatorScript

Slide 219

Slide 219 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = Haskell

Slide 220

Slide 220 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Haskell

Slide 221

Slide 221 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> Plutus Tx Haskell

Slide 222

Slide 222 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx Plutus Tx Haskell

Slide 223

Slide 223 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Plutus Tx Haskell

Slide 224

Slide 224 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && Plutus Tx Haskell

Slide 225

Slide 225 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && Plutus Tx Haskell

Slide 226

Slide 226 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Plutus Tx Haskell

Slide 227

Slide 227 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && Plutus Tx Haskell

Slide 228

Slide 228 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && Plutus Tx Haskell

Slide 229

Slide 229 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && totalInputs >= target && Plutus Tx Haskell

Slide 230

Slide 230 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && totalInputs >= target && txSignedBy p campaignOwner Plutus Tx Haskell

Slide 231

Slide 231 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && totalInputs >= target && txSignedBy p campaignOwner in P.errorIfNot isValid ||]) Plutus Tx Haskell

Slide 232

Slide 232 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) value DataScript (Ledger.lifted ownPK) register (refundTrigger campaign) (refundHandler (Ledger.hashTx tx) campaign) contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && totalInputs >= target && txSignedBy p campaignOwner in P.errorIfNot isValid ||]) off-chain on-chain Haskell Plutus Tx

Slide 233

Slide 233 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) value DataScript (Ledger.lifted ownPK) register (refundTrigger campaign) (refundHandler (Ledger.hashTx tx) campaign) contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && totalInputs >= target && txSignedBy p campaignOwner in P.errorIfNot isValid ||]) core off-chain on-chain Haskell Plutus Tx

Slide 234

Slide 234 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) value DataScript (Ledger.lifted ownPK) register (refundTrigger campaign) (refundHandler (Ledger.hashTx tx) campaign) contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && totalInputs >= target && txSignedBy p campaignOwner in P.errorIfNot isValid ||]) core core off-chain on-chain Haskell Plutus Tx

Slide 235

Slide 235 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) value DataScript (Ledger.lifted ownPK) register (refundTrigger campaign) (refundHandler (Ledger.hashTx tx) campaign) contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && totalInputs >= target && txSignedBy p campaignOwner in P.errorIfNot isValid ||]) core core off-chain on-chain Haskell Plutus Tx

Slide 236

Slide 236 text

contribute :: Campaign -> Value -> MockWallet () contribute campaign value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript (Ledger.scriptAddress (contributionScript campaign)) value DataScript (Ledger.lifted ownPK) register (refundTrigger campaign) (refundHandler (Ledger.hashTx tx) campaign) contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> let PendingTx ps outs _ _ (Height h) _ _ = tx isValid = case action of Refund -> h > collectionDeadline && contributorOnly outs && txSignedBy tx contrib Collect -> h > deadline && h <= collectionDeadline && totalInputs >= target && txSignedBy p campaignOwner in P.errorIfNot isValid ||]) core core off-chain on-chain Haskell Plutus Tx Compiler Execution Environment

Slide 237

Slide 237 text

Plutus Compiler Execution Environment = GHC + Plutus core plugin on-chain

Slide 238

Slide 238 text

Plutus Compiler Execution Environment = GHC + Plutus core plugin Plutus Tx (Haskell subset) on-chain

Slide 239

Slide 239 text

Plutus Compiler Execution Environment = GHC + Plutus core plugin Plutus Tx (Haskell subset) GHC Core on-chain

Slide 240

Slide 240 text

Plutus Compiler Execution Environment = GHC + Plutus core plugin Plutus Tx (Haskell subset) GHC Core Plutus IR on-chain

Slide 241

Slide 241 text

Plutus Compiler Execution Environment = GHC + Plutus core plugin Plutus Tx (Haskell subset) GHC Core Plutus IR Plutus Core core on-chain

Slide 242

Slide 242 text

Plutus Compiler Execution Environment = GHC + Plutus core plugin Plutus Tx (Haskell subset) GHC Core Plutus IR Plutus Core core on-chain ”Unraveling Recursion: Compiling an IR with Recursion to System F”, MPC19 [Kireev/Nester/Peyton Jones/Wadler/ Gkoumas/MacKennzie]

Slide 243

Slide 243 text

Plutus Compiler Execution Environment = GHC + Plutus core plugin Plutus Tx (Haskell subset) GHC Core Plutus IR Plutus Core core on-chain ”Unraveling Recursion: Compiling an IR with Recursion to System F”, MPC19 [Kireev/Nester/Peyton Jones/Wadler/ Gkoumas/MacKennzie] not yet in mainnet mockchain (functional emulator)

Slide 244

Slide 244 text

Plutus Compiler Execution Environment = GHC + Plutus core plugin not yet in mainnet mockchain (functional emulator) playgrounds not yet in mainnet https://testnet.iohkdev.io/plutus/

Slide 245

Slide 245 text

mchakravarty TacticalGrace justtesting.org

Slide 246

Slide 246 text

λ mchakravarty TacticalGrace justtesting.org λ λ Distribution and concurrency ⇒ effect control High assurance ⇒ semi-formal & formal methods

Slide 247

Slide 247 text

λ mchakravarty TacticalGrace justtesting.org λ λ Distribution and concurrency ⇒ effect control High assurance ⇒ semi-formal & formal methods Plutus functional ledger System F⍵ μ on-chain & off-chain

Slide 248

Slide 248 text

λ mchakravarty TacticalGrace justtesting.org λ λ Distribution and concurrency ⇒ effect control High assurance ⇒ semi-formal & formal methods Plutus functional ledger System F⍵ μ on-chain & off-chain

Slide 249

Slide 249 text

Thank you!

Slide 250

Slide 250 text

Image Attribution https://pixabay.com/images/id-1825276/ https://pixabay.com/images/id-2070977/ https://pixabay.com/photo-3990826/ Icons licensed from Noun Project https://pixabay.com/images/id-2834506/ Wikimedia https://de.wikipedia.org/wiki/Datei:Libra_(Kryptow%C3%A4hrung)_logo.svg https://commons.wikimedia.org/wiki/File:Vertrag_Hermann_Gruhl_und_Eisenbahndirektion_Cöln_1891.jpg