Slide 1

Slide 1 text

mchakravarty TacticalGrace justtesting.org iohk.io tweag.io Manuel M T Chakravarty Tweag I/O & IOHK Rethinking Blockchain Contract Development

Slide 2

Slide 2 text

Blockchain: Concurrency & Distribution

Slide 3

Slide 3 text

Blockchain: Concurrency & Distribution Alice Bob Charlie

Slide 4

Slide 4 text

Blockchain: Concurrency & Distribution Alice Bob Charlie ₳100 ₳10 ₳52

Slide 5

Slide 5 text

Blockchain: Concurrency & Distribution Alice Bob Charlie ₳100 ₳10 ₳52 ₳42

Slide 6

Slide 6 text

Blockchain: Concurrency & Distribution Alice Bob Charlie ₳58 ₳52 ₳52

Slide 7

Slide 7 text

Blockchain: Concurrency & Distribution Alice Bob Charlie ₳58 ₳52 ₳52 ₳20

Slide 8

Slide 8 text

Blockchain: Concurrency & Distribution Alice Bob Charlie ₳58 ₳32 ₳72

Slide 9

Slide 9 text

Blockchain: Concurrency & Distribution Alice Bob Charlie ₳58 ₳32 ₳72 Cheating?

Slide 10

Slide 10 text

Blockchain: Concurrency & Distribution Alice Bob Charlie ₳100 ₳10 ₳52

Slide 11

Slide 11 text

Blockchain: Concurrency & Distribution Alice Bob Charlie ₳100 ₳10 ₳52 Alice Bob Charlie Central Authority (Ledger)

Slide 12

Slide 12 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger)

Slide 13

Slide 13 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) ₳42 to Bob

Slide 14

Slide 14 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳58 Bob ₳52 Charlie ₳52 Central Authority (Ledger)

Slide 15

Slide 15 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳58 Bob ₳52 Charlie ₳52 Central Authority (Ledger) ₳20 to Charlie

Slide 16

Slide 16 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳58 Bob ₳32 Charlie ₳72 Central Authority (Ledger)

Slide 17

Slide 17 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳58 Bob ₳32 Charlie ₳72 Central Authority (Ledger) Ordering?

Slide 18

Slide 18 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger)

Slide 19

Slide 19 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) ₳20 to Charlie

Slide 20

Slide 20 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central Authority (Ledger) ₳20 to Charlie Invalid!

Slide 21

Slide 21 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Authority (Ledger) Trust in ledger?

Slide 22

Slide 22 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳0 Bob ₳0 Charlie ₳162 Authority (Ledger) Trust in ledger?

Slide 23

Slide 23 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Cryptographic Ledger (Consensus)

Slide 24

Slide 24 text

Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Cryptographic Ledger (Consensus) ₳42 to Bob

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳20 Cryptographic Ledger (Consensus) Blockchain: Distributed Data Store Alice Bob Charlie

Slide 32

Slide 32 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 Meal B㱺C ₳20 Drinks Cryptographic Ledger (Consensus) Blockchain: Distributed Data Store Alice Bob Charlie

Slide 33

Slide 33 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) Blockchain: Distributed Data Store Alice Bob Charlie

Slide 34

Slide 34 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) Blockchain: Consistent Distributed Store

Slide 35

Slide 35 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) Blockchain: Consistent Distributed Store Timber Shipment; Source: …; DNA Fingerprint: …; Volume: …

Slide 36

Slide 36 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) Blockchain: Consistent Distributed Store Timber Shipment; Source: …; DNA Fingerprint: …; Volume: … Door Frame; Timber Supply: ; Type: ecologically sourced

Slide 37

Slide 37 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) Blockchain: Consistent Distributed Store Timber Shipment; Source: …; DNA Fingerprint: …; Volume: … Door Frame; Timber Supply: ; Type: ecologically sourced On-chain: validation

Slide 38

Slide 38 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) Blockchain: Consistent Distributed Store Timber Shipment; Source: …; DNA Fingerprint: …; Volume: … Door Frame; Timber Supply: ; Type: ecologically sourced On-chain: validation Off-chain: coordination, processing & validation

Slide 39

Slide 39 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) Blockchain: Consistent Distributed Store Timber Shipment; Source: …; DNA Fingerprint: …; Volume: … Door Frame; Timber Supply: ; Type: ecologically sourced On-chain: validation Off-chain: coordination, processing & validation Now we need a programming language!

Slide 40

Slide 40 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) On-chain: validation scripts Off-chain: coordination code Data Structure Programming Language Distribution

Slide 41

Slide 41 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) On-chain: validation scripts Off-chain: coordination code Data Structure Programming Language Distribution Server Client

Slide 42

Slide 42 text

Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus) On-chain: validation scripts Off-chain: coordination code Data Structure Programming Language Distribution Server Client Server

Slide 43

Slide 43 text

Distribution Server Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus)

Slide 44

Slide 44 text

Distribution Server Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus)

Slide 45

Slide 45 text

Distribution Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus)

Slide 46

Slide 46 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger How do we prevent cheating?

Slide 47

Slide 47 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof

Slide 48

Slide 48 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof

Slide 49

Slide 49 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof Two Forms of Proof of Work (PoW) Proof of Stake (PoS)

Slide 50

Slide 50 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof Two Forms of Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle

Slide 51

Slide 51 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof Two Forms of Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Investment in the system

Slide 52

Slide 52 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof Is it all secure?

Slide 53

Slide 53 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof Is it all secure? Cryptography?

Slide 54

Slide 54 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof Is it all secure? Cryptography? Protocols?

Slide 55

Slide 55 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof Is it all secure? Cryptography? Protocols? Implementation?

Slide 56

Slide 56 text

Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof Formal methods, high-assurance methods, … Cryptography? Protocols? Implementation?

Slide 57

Slide 57 text

Cryptographic ledger Distributed, immutable, verifiable log data structure

Slide 58

Slide 58 text

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

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 Proof of Stake (PoS) Environmentally friendly, low-energy cryptographic proofs

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 High assurance development Formal methods, types, validation

Slide 61

Slide 61 text

Cardano Third Generation Blockchain

Slide 62

Slide 62 text

Cardano https://cardano.org/

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

Cardano Proof of Stake (PoS) Scalability Interoperability Governance Sustainability https://cardano.org/

Slide 68

Slide 68 text

Cardano Proof of Stake (PoS) Scalability Interoperability Governance Sustainability https://cardano.org/ Research Driven

Slide 69

Slide 69 text

Cardano Proof of Stake (PoS) Scalability Interoperability Governance Sustainability https://cardano.org/ Research Driven Programming Functional

Slide 70

Slide 70 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 71

Slide 71 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 72

Slide 72 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 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 75

Slide 75 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 76

Slide 76 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 77

Slide 77 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 78

Slide 78 text

∀∃⊢

Slide 79

Slide 79 text

∀∃⊢

Slide 80

Slide 80 text

∀∃⊢

Slide 81

Slide 81 text

∀∃⊢

Slide 82

Slide 82 text

∀∃⊢

Slide 83

Slide 83 text

∀∃⊢

Slide 84

Slide 84 text

∀∃⊢

Slide 85

Slide 85 text

∀∃⊢

Slide 86

Slide 86 text

∀∃⊢

Slide 87

Slide 87 text

∀∃⊢

Slide 88

Slide 88 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 89

Slide 89 text

λ τ

Slide 90

Slide 90 text

λ τ

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

How can we make the Ledger Representation more functional?

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

Ledger Representation Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳30 Charlie ₳72 Accounts

Slide 99

Slide 99 text

Ledger Representation Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳30 Charlie ₳72 Accounts ₳100 Alice ₳10 Bob ₳52 Charlie

Slide 100

Slide 100 text

Ledger Representation Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳30 Charlie ₳72 Accounts ₳58 ₳42 ₳100 Alice ₳10 Bob ₳52 Charlie

Slide 101

Slide 101 text

Ledger Representation Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳30 Charlie ₳72 Accounts ₳58 ₳42 ₳10 ₳50 ₳2 ₳100 Alice ₳10 Bob ₳52 Charlie

Slide 102

Slide 102 text

Ledger Representation Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳30 Charlie ₳72 Accounts ₳58 ₳42 ₳10 ₳50 ₳2 ₳100 Alice ₳10 Bob ₳52 Charlie Dataflow Graph Charlie Charlie Bob Alice

Slide 103

Slide 103 text

Ledger Representation Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50 Alice ₳58 Bob ₳30 Charlie ₳72 Accounts ₳58 ₳42 ₳10 ₳50 ₳2 ₳100 Alice ₳10 Bob ₳52 Charlie Dataflow Graph Charlie Charlie Bob Alice ₳52

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

Accounts Unspent Transaction Output (UTxO) Ledger Representation

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

Plutus Functional Contracts

Slide 108

Slide 108 text

Philip Wadler Vanessa McHale Kenneth MacKenzie Roman Kireev Jann Müller Michael Peyton Jones James Chapman Yours Truly The Plutus Team Rebecca Valentine (Former Member)

Slide 109

Slide 109 text

The Three Pillars of Plutus

Slide 110

Slide 110 text

No content

Slide 111

Slide 111 text

Safety & Security

Slide 112

Slide 112 text

Safety & Security Functional Ledger

Slide 113

Slide 113 text

Safety & Security Functional Ledger Full Stack

Slide 114

Slide 114 text

Safety & Security Functional Ledger Full Stack

Slide 115

Slide 115 text

No content

Slide 116

Slide 116 text

functional programming λ

Slide 117

Slide 117 text

functional programming with modern type systems λτ

Slide 118

Slide 118 text

functional programming modern type systems PLUTUS

Slide 119

Slide 119 text

functional programming modern type systems PLUTUS input output

Slide 120

Slide 120 text

functional programming modern type systems PLUTUS input output pure function side effects

Slide 121

Slide 121 text

functional programming modern type systems PLUTUS input output typed function safe usage :: ⍺ :: β

Slide 122

Slide 122 text

input output typed function safe usage :: ⍺ :: β

Slide 123

Slide 123 text

input output typed function safe usage :: ⍺ :: β local reasoning

Slide 124

Slide 124 text

input output typed function safe usage :: ⍺ :: β local reasoning type-directed design

Slide 125

Slide 125 text

input output typed function safe usage :: ⍺ :: β local reasoning type-directed design advanced testing & verification

Slide 126

Slide 126 text

local reasoning type-directed design advanced testing & verification }

Slide 127

Slide 127 text

local reasoning type-directed design advanced testing & verification } understand code behaviour

Slide 128

Slide 128 text

local reasoning type-directed design advanced testing & verification } understand code behaviour find exploits

Slide 129

Slide 129 text

core Plutus Core

Slide 130

Slide 130 text

core Plutus Core not a bytecode typed FP calculus

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

core Plutus Core small, powerful & based on peer-reviewed science not a bytecode not a classic virtual machine typed FP calculus abstract machine interpreter System F⍵ μ

Slide 133

Slide 133 text

core Plutus Core

Slide 134

Slide 134 text

core Plutus Core Closely mirrored in the implementation

Slide 135

Slide 135 text

core Plutus Core Agda formalisation

Slide 136

Slide 136 text

core Plutus Core Future work: testing against Agda Agda formalisation

Slide 137

Slide 137 text

core Plutus Core Where is it used? Future work: testing against Agda Agda formalisation

Slide 138

Slide 138 text

Safety & Security Functional Ledger Full Stack

Slide 139

Slide 139 text

No content

Slide 140

Slide 140 text

Account-based Ledger UTxO-based Ledger

Slide 141

Slide 141 text

Account-based Ledger UTxO-based Ledger functional imperative

Slide 142

Slide 142 text

Account-based Ledger UTxO-based Ledger functional imperative mutable shared state dataflow

Slide 143

Slide 143 text

Account-based Ledger UTxO-based Ledger functional imperative mutable shared state dataflow compositional entangled

Slide 144

Slide 144 text

What about the expressiveness of smart contracts?

Slide 145

Slide 145 text

What about the expressiveness of smart contracts? Bitcoin

Slide 146

Slide 146 text

What about the expressiveness of smart contracts? Bitcoin Ethereum

Slide 147

Slide 147 text

What about the expressiveness of smart contracts? Bitcoin Ethereum minimal

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

No content

Slide 150

Slide 150 text

No content

Slide 151

Slide 151 text

Input Output

Slide 152

Slide 152 text

Input Output

Slide 153

Slide 153 text

Input Output ν: Validator x: Value core

Slide 154

Slide 154 text

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

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

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

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

ν: Validator x: Value ρ: Redeemer ν(ρ, δ, σ, x) ≟ True δ: Data σ: State Extended UTxO Preserves the functional structure of UTxO ledgers core core core

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

Extended UTxO Preserves the functional structure of UTxO ledgers Greatly increases the expressive power of scripts

Slide 164

Slide 164 text

Extended UTxO Preserves the functional structure of UTxO ledgers Greatly increases the expressive power of scripts data flows with value

Slide 165

Slide 165 text

Extended UTxO Preserves the functional structure of UTxO ledgers Greatly increases the expressive power of scripts data flows with value scripts have an identity

Slide 166

Slide 166 text

Extended UTxO Preserves the functional structure of UTxO ledgers Greatly increases the expressive power of scripts data flows with value scripts have an identity invariants across transaction chains

Slide 167

Slide 167 text

Safety & Security Functional Ledger Full Stack

Slide 168

Slide 168 text

No content

Slide 169

Slide 169 text

What does it take to write a smart contract application?

Slide 170

Slide 170 text

Simple crowdfunding

Slide 171

Slide 171 text

Simple crowdfunding 1. Payment into campaign until a payment deadline

Slide 172

Slide 172 text

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

Slide 173

Slide 173 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 174

Slide 174 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 175

Slide 175 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 176

Slide 176 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 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)

Slide 177

Slide 177 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 178

Slide 178 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 179

Slide 179 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 180

Slide 180 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 181

Slide 181 text

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

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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

Slide 184

Slide 184 text

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

Slide 185

Slide 185 text

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

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

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

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

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

Slide 193

Slide 193 text

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

Slide 194

Slide 194 text

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

Slide 195

Slide 195 text

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

Slide 196

Slide 196 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 197

Slide 197 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 198

Slide 198 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 199

Slide 199 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 200

Slide 200 text

Haskell contributionScript :: Campaign -> ValidatorScript

Slide 201

Slide 201 text

contributionScript :: Campaign -> ValidatorScript contributionScript campaign = Haskell

Slide 202

Slide 202 text

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

Slide 203

Slide 203 text

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

Slide 204

Slide 204 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 205

Slide 205 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 206

Slide 206 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 207

Slide 207 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 208

Slide 208 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 209

Slide 209 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 210

Slide 210 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 211

Slide 211 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 212

Slide 212 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 213

Slide 213 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 214

Slide 214 text

Safety & Security Superior Ledger Full Stack

Slide 215

Slide 215 text

Safety & Security Superior Ledger Full Stack

Slide 216

Slide 216 text

Safety & Security Superior Ledger Full Stack

Slide 217

Slide 217 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

Slide 218

Slide 218 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

Slide 219

Slide 219 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

Slide 220

Slide 220 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

Slide 221

Slide 221 text

Playgrounds Exploring Plutus

Slide 222

Slide 222 text

Mockchain

Slide 223

Slide 223 text

Mockchain Functional blockchain emulator Event trace applying ledger rules and running Plutus on- and off-chain code

Slide 224

Slide 224 text

Mockchain Functional blockchain emulator Event trace applying ledger rules and running Plutus on- and off-chain code Semantics-driven development Greatly simplified by having mathematical models of the components

Slide 225

Slide 225 text

Mockchain Functional blockchain emulator Event trace applying ledger rules and running Plutus on- and off-chain code Semantics-driven development Greatly simplified by having mathematical models of the components From learning to continuous integration Lightweight, detailed introspection, but this is just the start

Slide 226

Slide 226 text

No content

Slide 227

Slide 227 text

mchakravarty TacticalGrace justtesting.org iohk.io Functional Blockchain Platform

Slide 228

Slide 228 text

mchakravarty TacticalGrace justtesting.org iohk.io Functional Blockchain Platform ∀∃⊢ λτ

Slide 229

Slide 229 text

mchakravarty TacticalGrace justtesting.org iohk.io Functional Blockchain Platform ∀∃⊢ λτ Extended functional UTxO ledger Integrated on- & off-chain code in Haskell

Slide 230

Slide 230 text

mchakravarty TacticalGrace justtesting.org iohk.io Functional Blockchain Platform https://testnet.iohkdev.io/plutus/ ∀∃⊢ λτ Extended functional UTxO ledger Integrated on- & off-chain code in Haskell

Slide 231

Slide 231 text

mchakravarty TacticalGrace justtesting.org iohk.io Functional Blockchain Platform https://testnet.iohkdev.io/plutus/ ∀∃⊢ λτ Extended functional UTxO ledger Integrated on- & off-chain code in Haskell

Slide 232

Slide 232 text

mchakravarty TacticalGrace justtesting.org iohk.io Functional Blockchain Platform https://testnet.iohkdev.io/plutus/ ∀∃⊢ λτ Extended functional UTxO ledger Integrated on- & off-chain code in Haskell https://plutusfest.io

Slide 233

Slide 233 text

Thank you!

Slide 234

Slide 234 text

Image Attribution https://pixabay.com/photo-1428230/ https://pixabay.com/photo-3830337/ https://pixabay.com/photo-3990826/ Icons licensed from Noun Project