Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Rethinking Blockchain Contract Development

Rethinking Blockchain Contract Development

VIDEO: https://www.youtube.com/watch?v=RGJ4FvsUQzo (Lambda Days 2019)

Presented at
* Lambda Days 2019: http://www.lambdadays.org/lambdadays2019
* Amsterdam Cardano Meetup (March 2019): https://www.meetup.com/Cardano-Blockchain-Netherlands/events/257986674/

With the proliferation of blockchain designs, we see a proliferation of proposals for languages and systems to script the rules governing transactions on these blockchains, generally known as smart contract languages. Despite the name, these languages are usually fairly conventional programming languages used to impose constraints on the transactions permitted to transfer assets and manipulate data stored on the blockchain.

Given the high financial stakes and widely publicised exploits on first generation (Bitcoin) and second generation (Ethereum) blockchains, the third-generation Cardano blockchain places a strong emphasis on functional programming and formal methods. This includes a new approach to contract languages based on state-of-the art research in programming languages and the increased safety provided by functional programming. The benefits of functional programming go even further: instead of having to invent yet another custom language, we simply use Haskell for the job, we design a superior blockchain architecture, and we seamlessly combine on-chain and off-chain computations.

In this talk, I will outline how IOHK’s Plutus team combines programming language theory, functional programming in Haskell, and theorem-proving in Agda to develop a radically new approach to blockchain contract development. This work has resulted in the Plutus Platform, which uses meta-programming in Haskell for distributed contract applications operating on the Cardano blockchain.

2296a6bdc7779fe4017a23d268c8a79d?s=128

Manuel Chakravarty

February 22, 2019
Tweet

Transcript

  1. mchakravarty TacticalGrace justtesting.org iohk.io tweag.io Manuel M T Chakravarty Tweag

    I/O & IOHK Rethinking Blockchain Contract Development
  2. Blockchain: Concurrency & Distribution

  3. Blockchain: Concurrency & Distribution Alice Bob Charlie

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

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

    ₳42
  6. Blockchain: Concurrency & Distribution Alice Bob Charlie ₳58 ₳52 ₳52

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

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

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

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

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

    Alice Bob Charlie Central Authority (Ledger)
  12. Blockchain: Concurrency & Distribution Alice Bob Charlie Alice ₳100 Bob

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Cryptographic Ledger (Consensus) Blockchain: Concurrency & Distribution Alice Bob Charlie Transaction
  29. 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
  30. 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
  31. Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳20

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

    ₳20 Drinks Cryptographic Ledger (Consensus) Blockchain: Distributed Data Store Alice Bob Charlie
  33. 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
  34. 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
  35. 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: …
  36. 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
  37. 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
  38. 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
  39. 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!
  40. 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
  41. 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
  42. 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
  43. Distribution Server Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1

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

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

    Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger (Consensus)
  46. 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?
  47. Consensus & Trust Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B

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

    ₳0,1 Timber Shipment B㱺C ₳0,1 Door Frame Cryptographic Ledger Cryptographic Proof
  49. 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)
  50. 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
  51. 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
  52. 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?
  53. 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?
  54. 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?
  55. 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?
  56. 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?
  57. Cryptographic ledger Distributed, immutable, verifiable log data structure

  58. Cryptographic ledger Distributed, immutable, verifiable log data structure On-chain &

    off-chain contract code On-chain transaction validation & off-chain coordination
  59. 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
  60. 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
  61. Cardano Third Generation Blockchain

  62. Cardano https://cardano.org/

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

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

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

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

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

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

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

    Research Driven Programming Functional
  70. Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

  71. Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

  72. Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

  73. None
  74. 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. akiayias@inf.ed.ac.uk. 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. acr@cse.uconn.edu. ‡ Aarhus University and IOHK, bernardo.david@iohk.io. Work partly supported by European Research Council Starting Grant 279447. § IOHK, roman.oliynykov@iohk.io. 1
  75. 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. akiayias@inf.ed.ac.uk. 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. acr@cse.uconn.edu. ‡ Aarhus University and IOHK, bernardo.david@iohk.io. Work partly supported by European Research Council Starting Grant 279447. § IOHK, roman.oliynykov@iohk.io. 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].
  76. 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. akiayias@inf.ed.ac.uk. 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. acr@cse.uconn.edu. ‡ Aarhus University and IOHK, bernardo.david@iohk.io. Work partly supported by European Research Council Starting Grant 279447. § IOHK, roman.oliynykov@iohk.io. 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/
  77. Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

  78. ∀∃⊢

  79. ∀∃⊢

  80. ∀∃⊢

  81. ∀∃⊢

  82. ∀∃⊢

  83. ∀∃⊢

  84. ∀∃⊢

  85. ∀∃⊢

  86. ∀∃⊢

  87. ∀∃⊢

  88. Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

  89. λ τ

  90. λ τ

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

  92. λ τ Series of refinements (incremental, rollback, etc) Persistence, networking,

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

    frontend interaction Test against executable spec using property-based testing
  94. Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

  95. Research Driven Formal Methods Programming Functional ∀∃⊢ λτ Duncan Coutts

    @ PlutusFest 2018 https://youtu.be/wW1CI9zt1tg
  96. How can we make the Ledger Representation more functional?

  97. Ledger Representation Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42

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

    B㱺C ₳50 Alice ₳58 Bob ₳30 Charlie ₳72 Accounts
  99. 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
  100. 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
  101. 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
  102. 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
  103. 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
  104. 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
  105. Accounts Unspent Transaction Output (UTxO) Ledger Representation

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

  107. Plutus Functional Contracts

  108. 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)
  109. The Three Pillars of Plutus

  110. None
  111. Safety & Security

  112. Safety & Security Functional Ledger

  113. Safety & Security Functional Ledger Full Stack

  114. Safety & Security Functional Ledger Full Stack

  115. None
  116. functional programming λ

  117. functional programming with modern type systems λτ

  118. functional programming modern type systems PLUTUS

  119. functional programming modern type systems PLUTUS input output

  120. functional programming modern type systems PLUTUS input output pure function

    side effects
  121. functional programming modern type systems PLUTUS input output typed function

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

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

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

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

    local reasoning type-directed design advanced testing & verification
  126. local reasoning type-directed design advanced testing & verification }

  127. local reasoning type-directed design advanced testing & verification } understand

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

    code behaviour find exploits
  129. core Plutus Core

  130. core Plutus Core not a bytecode typed FP calculus

  131. core Plutus Core not a bytecode not a classic virtual

    machine typed FP calculus abstract machine interpreter
  132. 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⍵ μ
  133. core Plutus Core

  134. core Plutus Core Closely mirrored in the implementation

  135. core Plutus Core Agda formalisation

  136. core Plutus Core Future work: testing against Agda Agda formalisation

  137. core Plutus Core Where is it used? Future work: testing

    against Agda Agda formalisation
  138. Safety & Security Functional Ledger Full Stack

  139. None
  140. Account-based Ledger UTxO-based Ledger

  141. Account-based Ledger UTxO-based Ledger functional imperative

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

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

    compositional entangled
  144. What about the expressiveness of smart contracts?

  145. What about the expressiveness of smart contracts? Bitcoin

  146. What about the expressiveness of smart contracts? Bitcoin Ethereum

  147. What about the expressiveness of smart contracts? Bitcoin Ethereum minimal

  148. What about the expressiveness of smart contracts? Bitcoin Ethereum minimal

    enough rope
  149. None
  150. None
  151. Input Output

  152. Input Output

  153. Input Output ν: Validator x: Value core

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

  155. Input Output ν: Validator x: Value ρ: Redeemer ν(ρ) ≟

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

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

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

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

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

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

    ≟ True δ: Data σ: State Extended UTxO Preserves the functional structure of UTxO ledgers core core core
  162. ν: 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
  163. Extended UTxO Preserves the functional structure of UTxO ledgers Greatly

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

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

    increases the expressive power of scripts data flows with value scripts have an identity
  166. 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
  167. Safety & Security Functional Ledger Full Stack

  168. None
  169. What does it take to write a smart contract application?

  170. Simple crowdfunding

  171. Simple crowdfunding 1. Payment into campaign until a payment deadline

  172. Simple crowdfunding 1. Payment into campaign until a payment deadline

    2. If funding goal reached, campaign owner can collect funds
  173. 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
  174. 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
  175. 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
  176. 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)
  177. 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(”<opt… $(”#projectAddr”).append(”<opt… }); var compiled = web3.eth.compile.so… var code = compiled.code; var abi = compiled.info.abiDefinit… var contract = web3.eth.contract(a… … JavaScript (off-chain) +
  178. 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(”<opt… $(”#projectAddr”).append(”<opt… }); var compiled = web3.eth.compile.so… var code = compiled.code; var abi = compiled.info.abiDefinit… var contract = web3.eth.contract(a… … JavaScript
  179. 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(”<opt… $(”#projectAddr”).append(”<opt… }); var compiled = web3.eth.compile.so… var code = compiled.code; var abi = compiled.info.abiDefinit… var contract = web3.eth.contract(a… … JavaScript off-chain (wallet) on-chain (transaction)
  180. 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(”<opt… $(”#projectAddr”).append(”<opt… }); var compiled = web3.eth.compile.so… var code = compiled.code; var abi = compiled.info.abiDefinit… var contract = web3.eth.contract(a… … JavaScript off-chain (wallet) on-chain (transaction) two-level (staged) programming model JavaScript Solidity
  181. Solidity JavaScript off-chain (wallet) on-chain (transaction) two-level (staged) programming model

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

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

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

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

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

  187. Haskell (Plutus Tx) Haskell off-chain (wallet) on-chain (transaction) two-level (staged)

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

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

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

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

    programming model meta programming integrated compact robust
  192. contribute :: Campaign -> Value -> MockWallet () contribute campaign

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

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

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

    value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript Haskell
  196. 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
  197. 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
  198. 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
  199. 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
  200. Haskell contributionScript :: Campaign -> ValidatorScript

  201. contributionScript :: Campaign -> ValidatorScript contributionScript campaign = Haskell

  202. contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator

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

    `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> Plutus Tx Haskell
  204. 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
  205. 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
  206. 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
  207. 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
  208. 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
  209. 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
  210. 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
  211. 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
  212. 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
  213. 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
  214. Safety & Security Superior Ledger Full Stack

  215. Safety & Security Superior Ledger Full Stack

  216. Safety & Security Superior Ledger Full Stack

  217. 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
  218. 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
  219. 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
  220. 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
  221. Playgrounds Exploring Plutus

  222. Mockchain

  223. Mockchain Functional blockchain emulator Event trace applying ledger rules and

    running Plutus on- and off-chain code
  224. 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
  225. 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
  226. None
  227. mchakravarty TacticalGrace justtesting.org iohk.io Functional Blockchain Platform

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

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

    functional UTxO ledger Integrated on- & off-chain code in Haskell
  230. 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
  231. 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
  232. 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
  233. Thank you!

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