Functional Modelling of Contractual Workflows in DAML

location_city Melbourne schedule May 14th 03:45 - 04:15 PM place Red Room people 81 Interested

The Australian Security Exchange (ASX)'s CHESS[1] replacement[2] will be one of the most institutionally significant deployments of pure FP in the world. The CHESS settlement and registry system tracks the ownership of $1.5 trillion of the Australian economy on a daily basis. Its replacement is being developed by Digital Asset in DAML[3], and is due for completion in 2021.

Running on a distributed ledger technology (DLT), DAML is a smart contract language inspired by Haskell. It shares much of Haskell's pure core; however, it removes the infamous IO type, and instead provides a dedicated and restricted ledger-interaction type. This type, and the underlying ledger model it encapsulates, captures DAML's first-class control of authorisation and privacy.

This presentation introduces the DLT architecture style. It will explain the strengths and weaknesses of DLT, especially when modelling contractual workflows. It will demonstrate the use of DAML language to implement multi-party workflows that include authorisation and privacy requirements on the DLT platform developed by Digital Asset.

An attendee will come away with an understanding of how DLT is a distinct architectural style, a taste of DAML as a programming language, and an insight into the platform and language behind the highest profile functional programming project in Australia.

[1] CHESS: Clearing House Electronic Subregister System (https://www.asx.com.au/research/chess_brochure.pdf)

[2] https://www.asx.com.au/services/chess-replacement.htm

[3] Digital Asset Modelling Language (https://daml.com)

 
 

Outline/Structure of the Talk

Introduction to Digital Ledger Technology as an Architectural Style (5-min)

Introduction to DAML as a Contractual Workflow Language & DAML Modeling (5-min)

DAML Coding Examples (15-min)

Questions (5-min)

Learning Outcome

  • How DLT is a distinct architectural style
  • A taste of DAML as a programming language
  • An understanding of the nature of multi-party authorization and privacy challenges imposed by contractual workflows, and how DLT and DAML assists in solving them

Target Audience

Anyone interested in the technology behind a world-first, large-scale, Australian FP project

Prerequisites for Attendees

The introduction to the DLT Architectural Style will try not to assume any specific background.

The DAML and contractual workflow discussions will assume a basic familiarity with the concept of legal contracts and basic contract formation.

Coding examples will assume a basic familiarity with Haskell syntax and introductory concepts (Monad, Functor, Monoid).

schedule Submitted 10 months ago

  • Liked Andrae Muys
    keyboard_arrow_down

    Andrae Muys - Where were the Functors? (the software engineering practices behind FP abstractions—without mentioning category theory)

    Andrae Muys
    Andrae Muys
    Engineer
    Digital Asset
    schedule 10 months ago
    Sold Out!
    30 Mins
    Talk
    Beginner

    There is a small set of basic abstractions every beginner functional programmer needs to learn, generally sooner rather than later. For various—if unhelpful to beginner functional programmers—reasons, these have been given names drawn from mathematics (in particular, category theory). Monad, Applicative, Monoid, Functor, the list doesn't stop. Yet despite the relative obscurity of the names, it doesn't take long for a budding functional programmer to discover that practically everything is a Functor, and almost anything she wants to do requires a Monad. If our new functional programmer has been programming for a decade or two, this suggests an obvious question:

    If practically everything is a Functor, and doing almost anything requires a Monad,
    where were they hiding all this time?

    This talk will answer that question. Starting with some basic imperative Java/C/C# code, it will:

    • show how the basic software engineering practices we have been using for decades, turn up in FP as these obscurely named types
    • demonstrate how, by making these concepts concrete as types, FP gets to take fuller advantage of these practices than we ever could in imperative languages
    • and impart some understanding (and possibly compassion) for the FP forebears who had to choose these names, and why we ended up with the names we have.