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

Blockchains are functional

Blockchains are functional

VIDEO: https://www.youtube.com/watch?v=zXy4kxUlUmY

Presentation: opening keynote at ICFP 2019.

Abstract
Functional programming and blockchains are a match made in heaven! The immutable and reproducible nature of distributed ledgers is mirrored in the semantic foundation of functional programming. Moreover, the concurrent and distributed operation calls for a programming model that carefully controls shared mutable state and side effects. Finally, the high financial stakes often associated with blockchains suggest the need for high assurance software and formal methods.

Nevertheless, most existing blockchains favour an object-oriented, imperative approach in both their implementation as well as in the contract programming layer that provides user-defined custom functionality on top of the basic ledger. On the one hand, this might appear surprising, given that it is widely understood that this style of programming is particularly risky in concurrent and distributed systems. On the other hand, blockchains are still in their infancy and little research has been conducted into associated programming language technology.

In this talk, I explain the connection between blockchains and functional programming as well as highlight several areas where functional programming, type systems, and formal methods have the potential to advance the state of the art. Overall, I argue that blockchains are not just a well-suited application area for functional programming techniques, but that they also provide fertile ground for future research. I illustrate this with evidence from the research-driven development of the Cardano blockchain and its contract programming platform, Plutus. Cardano and Plutus are implemented in Haskell and Rust, and the development process includes semi-formal specifications together with the use of Agda, Coq, and Isabelle to formalise key components.

2296a6bdc7779fe4017a23d268c8a79d?s=128

Manuel Chakravarty
PRO

August 19, 2019
Tweet

More Decks by Manuel Chakravarty

Other Decks in Science

Transcript

  1. mchakravarty TacticalGrace justtesting.org Manuel M T Chakravarty Tweag I/O &

    IOHK Blockchains Are Functional
  2. Blockchains Distributed immutable ledger

  3. Wallets

  4. Alice Bob Charlie Wallets

  5. Alice Bob Charlie ₳100 ₳10 ₳52 Wallets

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

  7. Alice Bob Charlie ₳58 ₳52 ₳52 Wallets

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

  9. Alice Bob Charlie ₳58 ₳32 ₳72 Wallets

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

  11. Alice Bob Charlie ₳100 ₳10 ₳52

  12. Alice Bob Charlie ₳100 ₳10 ₳52 Alice Bob Charlie Central

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

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

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

    Authority (Ledger) ₳42 to Bob Bank
  16. Alice Bob Charlie Alice ₳58 Bob ₳52 Charlie ₳52 Central

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

    Authority (Ledger) ₳20 to Charlie Bank
  18. Alice Bob Charlie Alice ₳58 Bob ₳32 Charlie ₳72 Central

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

    Authority (Ledger) Ordering? Bank
  20. Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 Central

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ₳20 Drinks Cryptographic Ledger (Consensus) Alice Bob Charlie Distributed Tamper-Resistant Store
  36. Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳0,1 Unlock Fancy

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

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

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

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

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

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

    ₳0,1 Unlock Fancy Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) In-Game Achievement; Type: …; Witness: …; Reward: … Trade Record; Item: ; Conditions: … On-chain: validation Off-chain: coordination, processing & validation We need a “smart contract” language!
  43. None
  44. secure and share important records, such as records of identity

    asset registries (land title, patient health records, educational certifications) monitoring and regulating markets combat tax fraud; streamline tax calculation & collection
  45. Distributed Tamper-Resistant Store Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B

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

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

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

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

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

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

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

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

    Hat B㱺C ₳0,1 Trade Fancy Hat Cryptographic Ledger (Consensus) Data Structure Consensus l Proof of Work (PoW) Proof of Stake (PoS) Cryptographic puzzle Investment in the system Permissioned Ledger public public walled Authorization required
  54. public blockchains Proof of Work (PoW) Proof of Stake (PoS)

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

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

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

    Cryptographic puzzle Investment in the system active and highly sophisticated research area financial incentive for attacks is very high cryptocurrencies are a conceptually necessity
  58. Cryptographic ledger Distributed, immutable, verifiable log data structure

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

    off-chain contract code On-chain transaction validation & off-chain coordination
  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
  61. 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
  62. Blockchain Layers

  63. Blockchain Layers Network Layer transaction & block transport

  64. Blockchain Layers Network Layer transaction & block transport conventional networking

  65. Blockchain Layers Network Layer Consensus Layer transaction & block transport

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

    PoW, PoS, etc protocol conventional networking sophisticated cryptographic protocols
  67. Blockchain Layers Network Layer Consensus Layer Ledger Layer transaction &

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

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

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

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

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

    conventional networking sophisticated cryptographic protocols accounting & transaction validation domain-specific }protocol formalisation (semi-)formal reasoning type systems property-based testing functional contract languages contract formalisation certified compilation DSLs
  73. Projects Principled approaches

  74. æternity Cardano Concordium Libra Tezos Zilliqa

  75. Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml

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

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

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

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

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

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

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

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

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

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

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

    other universities Research driven
  87. Development From research to production

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

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

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

  91. None
  92. 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
  93. 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].
  94. 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/
  95. Research Driven Formal Methods Programming Functional ∀∃⊢ λτ

  96. ∀∃⊢

  97. ∀∃⊢

  98. ∀∃⊢

  99. ∀∃⊢

  100. ∀∃⊢

  101. ∀∃⊢

  102. ∀∃⊢

  103. ∀∃⊢

  104. ∀∃⊢

  105. ∀∃⊢

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

  107. λ τ

  108. λ τ

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

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

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

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

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

    @ PlutusFest 2018 https://youtu.be/wW1CI9zt1tg
  114. Plutus Functional contracts

  115. (Ledger)

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

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

  118. Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50

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

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

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

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

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

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

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

    Alice ₳58 Bob ₳2 Charlie ₳102 Accounts ₳58 ₳42 ₳10 ₳50 ₳2 ₳100 Alice ₳10 Bob ₳52 Charlie Dataflow Graph Unspent Transaction Output (UTxO) Charlie Charlie Bob Alice ₳52 (Ledger)
  126. Accounts Unspent Transaction Output (UTxO) Ledger Representation

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

  128. Accounts UTxO Ledger

  129. Accounts UTxO Ledger (computational)

  130. Accounts UTxO functional imperative Ledger (computational)

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

  132. What about the expressiveness of smart contracts?

  133. What about the expressiveness of smart contracts? Bitcoin

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

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

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

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

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

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

    enough rope richer dataflow graph
  140. None
  141. None
  142. Input Output

  143. Input Output

  144. Input Output ν: Validator x: Value core

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    execution core core core } Purely functional expression We can perfectly predict on-chain costs by off-chain profiling https://ethereum.stackexchange.com/
  164. core

  165. core Everything on the chain is immutable — also code.

  166. core Everything on the chain is immutable — also code.

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

    Validators may protect millions — literally! Move fast and break things!
  168. Plutus Core core

  169. Plutus Core core not a bytecode typed FP calculus

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

    machine typed FP calculus abstract machine interpreter
  171. Plutus Core core small, powerful & old = well understood

    not a bytecode not a classic virtual machine typed FP calculus abstract machine interpreter System F⍵ μ
  172. Plutus Core core

  173. Plutus Core core Closely mirrored in the implementation

  174. Plutus Core core Agda formalisation

  175. Plutus Core core In progress: testing against Agda Agda formalisation

  176. Plutus Core core In progress: testing against Agda Agda formalisation

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

    testing against Agda Agda formalisation ”System F in Agda, for Fun and Profit”, MPC19 [Chapman/Kireev/Nester/Wadler]
  178. λ functional programming

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

  180. Let’s invent a new programming language!

  181. Very resource and time consuming Let’s invent a new programming

    language!
  182. Haskell

  183. Haskell Expressive Vibrant community Powerful Mature libraries and tools Support

    material
  184. None
  185. What does it take to write a smart contract application?

  186. Simple crowdfunding

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

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

    2. If funding goal reached, campaign owner can collect funds
  189. 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
  190. 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
  191. 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
  192. pragma solidity ^0.4.6; contract WinnerTakesAll { uint minimumEntryFee; uint public

    deadlineProjects; uint public deadlineCampaign; uint public winningFunds; address public winningAddress; struct Project { address addr; string name; string url; uint funds; bool initialized; } … Solidity (on-chain) 1. Payment into campaign until a payment deadline 2. If funding goal reached, campaign owner can collect funds 3. If funding goal not reached, refunds can be obtained by contributors 4. If campaign owner does not collect by collection deadline, contributors can also obtain refunds
  193. 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) +
  194. 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 Legacy Edition
  195. 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) Legacy Edition
  196. 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 Legacy Edition
  197. Solidity JavaScript off-chain (wallet) on-chain (transaction) two-level (staged) programming model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript Haskell
  213. 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
  214. 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
  215. 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
  216. 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
  217. Haskell contributionScript :: Campaign -> ValidatorScript

  218. Haskell contributionScript :: Campaign -> ValidatorScript

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

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

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

    `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> Plutus Tx Haskell
  222. 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
  223. 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
  224. 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
  225. 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
  226. 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
  227. 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
  228. 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
  229. 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
  230. 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
  231. 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
  232. contribute :: Campaign -> Value -> MockWallet () contribute campaign

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

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

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

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

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

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

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

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

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

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

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

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

    not yet in mainnet mockchain (functional emulator) playgrounds not yet in mainnet https://testnet.iohkdev.io/plutus/
  245. mchakravarty TacticalGrace justtesting.org

  246. λ mchakravarty TacticalGrace justtesting.org λ λ Distribution and concurrency ⇒

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

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

    effect control High assurance ⇒ semi-formal & formal methods Plutus functional ledger System F⍵ μ on-chain & off-chain
  249. Thank you!

  250. Image Attribution https://pixabay.com/images/id-1825276/ https://pixabay.com/images/id-2070977/ https://pixabay.com/photo-3990826/ Icons licensed from Noun Project

    https://pixabay.com/images/id-2834506/ Wikimedia https://de.wikipedia.org/wiki/Datei:Libra_(Kryptow%C3%A4hrung)_logo.svg https://commons.wikimedia.org/wiki/File:Vertrag_Hermann_Gruhl_und_Eisenbahndirektion_Cöln_1891.jpg