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.

Manuel Chakravarty

August 19, 2019
Tweet

More Decks by Manuel Chakravarty

Other Decks in Science

Transcript

  1. Alice Bob Charlie Alice ₳58 Bob ₳52 Charlie ₳52 Central

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

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

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

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

    (Ledger) Trust in central authority? Bank
  6. Alice Bob Charlie Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B

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

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

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

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

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

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

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

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

    ₳20 Drinks Cryptographic Ledger (Consensus) Alice Bob Charlie Distributed Tamper-Resistant Store
  15. 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
  16. 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)
  17. 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: …
  18. 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: …
  19. 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
  20. 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
  21. 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!
  22. 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
  23. 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!
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. public blockchains Proof of Work (PoW) Proof of Stake (PoS)

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

    Cryptographic puzzle Investment in the system active and highly sophisticated research area
  34. 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
  35. 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
  36. Cryptographic ledger Distributed, immutable, verifiable log data structure On-chain &

    off-chain contract code On-chain transaction validation & off-chain coordination
  37. 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
  38. 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
  39. Blockchain Layers Network Layer Consensus Layer transaction & block transport

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

    block transport PoW, PoS, etc protocol ledger rules conventional networking sophisticated cryptographic protocols
  41. 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
  42. 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
  43. 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
  44. 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
  45. 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
  46. Erlang Haskell & Rust Haskell, Rust & OCaml Rust OCaml

    C++ & OCaml æternity Cardano Concordium Libra Tezos Zilliqa Implementation and Reasoning Languages
  47. 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
  48. 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
  49. 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)
  50. 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)
  51. 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)
  52. 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)
  53. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol Aggelos Kiayias Alexander

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

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

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

    frontend interaction Test against executable spec using property-based testing
  57. Alice ₳100 Bob ₳10 Charlie ₳52 A㱺B ₳42 B㱺C ₳50

    Alice ₳58 Bob ₳2 Charlie ₳102 Accounts (Ledger)
  58. 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)
  59. 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)
  60. 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)
  61. 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)
  62. 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)
  63. 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)
  64. Input Output ν: Validator x: Value ρ: Redeemer ν(ρ) ≟

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

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

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

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

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

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

    ≟ True δ: Data σ: Tx Extended UTxO Greatly increases the expressive power of scripts Pure script execution core core core
  71. ν: 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]
  72. ν: Validator x: Value ρ: Redeemer ν(ρ , δ ,

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

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

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

    execution core core core } Purely functional expression For the same σ (transaction) and same x (value),
  76. ν(ρ , δ , σ, 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
  77. ν(ρ , δ , σ, 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
  78. ν(ρ , δ , σ, x) ≟ True Pure script

    execution core core core } Purely functional expression We can perfectly predict on-chain costs by off-chain profiling
  79. ν(ρ , δ , σ, 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/
  80. ν(ρ , δ , σ, 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/
  81. core Everything on the chain is immutable — also code.

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

    Validators may protect millions — literally! Move fast and break things!
  83. Plutus Core core not a bytecode not a classic virtual

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

    not a bytecode not a classic virtual machine typed FP calculus abstract machine interpreter System F⍵ μ
  85. Plutus Core core In progress: testing against Agda Agda formalisation

    ”System F in Agda, for Fun and Profit”, MPC19 [Chapman/Kireev/Nester/Wadler]
  86. 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]
  87. Simple crowdfunding 1. Payment into campaign until a payment deadline

    2. If funding goal reached, campaign owner can collect funds
  88. 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
  89. 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
  90. 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
  91. 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
  92. 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) +
  93. 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
  94. 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
  95. 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
  96. Haskell (Plutus Tx) Haskell off-chain (wallet) on-chain (transaction) two-level (staged)

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

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

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

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

    value = do when (value <= 0) $ throwOtherError "Must contribute a positive value" ownPK <- ownPubKey tx <- payToScript Haskell
  101. 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
  102. 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
  103. 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
  104. 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
  105. contributionScript :: Campaign -> ValidatorScript contributionScript campaign = ValidatorScript (validator

    `apply` campaign) where validator = Ledger.fromCompiledCode $$(PlutusTx.compile [|| (\Campaign{..} action contrib tx -> Plutus Tx Haskell
  106. 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
  107. 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
  108. 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
  109. 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
  110. 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
  111. 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
  112. 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
  113. 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
  114. 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
  115. 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
  116. 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
  117. 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
  118. 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
  119. 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
  120. 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
  121. Plutus Compiler Execution Environment = GHC + Plutus core plugin

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

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

    Plutus Tx (Haskell subset) GHC Core Plutus IR Plutus Core core on-chain
  124. 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]
  125. 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)
  126. 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/
  127. λ mchakravarty TacticalGrace justtesting.org λ λ Distribution and concurrency ⇒

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

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

    effect control High assurance ⇒ semi-formal & formal methods Plutus functional ledger System F⍵ μ on-chain & off-chain
  130. 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