Release of DAML SDK v0.12.12

DAML Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

DAML Compiler

  • Support reading of DAML-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API

Documentation

Releases

Release of DAML SDK v0.12.11

DAML Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

DAML Compiler

  • Support reading of DAML-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API

Documentation

Releases

Removing the limits on signatories

A peek behind the curtain at how DAML has evolved

DAML—the open source smart contract development language—is the result of many years’ effort on the part of the Digital Asset language engineering team and the customers and partners who worked closely with us in our early access program. Lessons learned during those early years have been turned into language features that you are able to utilize in the current version of the code. It can be instructive, or at the least interesting, to look back at how some of these features evolved over time. This is especially true for one of DAML’s distinguishing features, the ability to cleanly abstract what would otherwise be a daunting task of expressing which parties are authorized to take actions and see data.

In the days of old, DAML examined your code and inferred who could be put in an obligable position. A cool feature, no doubt—but one that was also somewhat limiting. In particular, we wanted to usher in a world where managing authorization via delegation, signatories, controllers, and obligable parties was more powerful, more secure, and simpler. This blog post is the first of three that explains the improvements we made in this area.

Example of agreeing to a proposal

Imagine you have something big to celebrate and want everybody to agree to the date before the celebration is scheduled. A fairly natural encoding in DAML is as follows (the full code of the example can be found in this GitHub Gist):

1_MOdnLM87P1OBhMR6AjWIxABut earlier versions of DAML didn’t allow this code because you couldn’t build a contract with a variable number of signatories. There were creative workarounds to define a contract with at-most some fixed number of signatories by setting multiple signatories to the same value, but the code was ugly. None of these workarounds let you flexibly express the underlying concept of requiring multiple parties to agree on something—a fundamental building block in the types of applications that are likely to be coded in DAML.

This post introduces two of the features that we added to DAML to fix this shortcoming; details on each will follow in subsequent posts.

More powerful signatories

In DAML SDK 0.6.3, explicitly declaring all signatories became strongly recommended on all contracts (they help the analysis tools and the human readers), and in SDK 0.7 explicit signatories became mandatory (with a nice, polite warning to fill in any missing signatories). These changes were in response to customer feedback that perceived the implicit obligables system we had before as being rather opaque and overly complex. Once we made the leap to explicit signatories, several natural extensions emerged.

First, we were able to introduce dynamic lists of signatories, where signatories can be an expression returning a list instead of just an expression returning a single party. This change was entirely backward compatible but opened the door to massively more powerful contracts—particularly around proposal contracts such as the example given above.

Second, we were able to make controllers more flexible, requiring either all-of or one-of a set of parties (also known as conjunctive and disjunctive choice controllers, which will be described in an upcoming post) to exercise the choice. This flexibility makes it possible to define contracts that are only called in the context of other on-ledger contracts, allowing us to securely express multi-party workflows governed by on-ledger master contracts.

More security, better checks

DAML is a secure language—and the management of obligations is an important part of that story. Originally DAML code was checked statically for obligation violations, and should none be found it emitted a core language that ran on the ledger. The ledger blindly trusted the declared signatories. If you manually edited the DAML output or disabled the obligables inference using an older version of DAML, the ledger could put parties into an obligable position without authorization—in violation of one of the core principles of DAML design. Furthermore, if there was a bug in the obligables inference, the security guarantees of DAML were lost.

There was a simple solution to these security problems—runtime checks. We now check for well-authorization of transactions at runtime as defined in the DA Ledger Model. These checks were easy to implement and gave strong safety guarantees. As a result, the security of our ledger with respect to voluntary contract formation is based on a trusted code base which is significantly smaller than it was before.

Conclusions

DAML is all about managing authorization via delegation, signatories, controllers, and obligable parties. We wanted to make DAML better by strengthening this key feature. In future blog posts, we will look at the two specific changes we made to signatories and controllers, and how to use them effectively.

Read the next story in this series

Join the community and download the DAML SDK at daml.com

This story was originally published 25 April 2019 on Medium

About the authors

Martin Huschenbett, Ph.D. – Senior Software Engineer – DAML Language Team, Digital Asset

Martin joined Digital Asset’s language engineering team in 2017, where he works on the DAML compiler and authorization checker. Previously, as a member of the trading systems team for the proprietary trading firm Jane Street Capital in London, he contributed to the research infrastructure used by the quantitative analysts, and the monitoring systems for the compliance team.

Martin holds a Ph.D. from Technische Universität Ilmenau in Germany, where he worked as a research associate at the Department of Theoretical Computer Science. His academic work included research and teaching primarily in the fields of computational logic, automata theory and formal verification. He held a postdoctoral position at the Ludwig-Maximilians-Universität München prior to joining Jane Street Capital.

Neil Mitchell, Ph.D. – DAML Language Team Lead, Digital Asset

Neil leads the team responsible for the DAML Language. Neil has a Ph.D. in Computer Science from York University, where he worked on making functional programs shorter, faster and safer. Since 2008 he spent 8 years as a quant at Credit Suisse and Standard Chartered, before building a cross-asset risk engine as a Director at Barclays. Throughout, Neil has been taking the programming language techniques from his Ph.D. and applying them to get the same benefits in a commercial setting.

Neil is the author of popular Haskell tools such as HoogleHLint, and Ghcid – all designed to help developers write good code quickly. More recently Neil has been researching build systems with publications at ICFP and the Haskell Symposium, and a practical system based on those ideas named Shake. Neil’s home page@ndm_haskell

DAML smart contracts coming to Hyperledger Sawtooth

It has been a busy two weeks at Digital Asset… first, we announced that we have open-sourced DAML under the Apache 2.0 license and that the DAML SDK is available to all. Five days later, ISDA (the standards body for the derivatives market) announced that DAML is the exclusive smart contract language for their Common Domain Model, and we open-sourced a reference library and application. Next up, we announced that we’ve been working with the team at VMware to integrate DAML with their enterprise blockchain platform, VMware Blockchain.

Today, we’re delighted to share that we have been working with fellow Hyperledger members, Blockchain Technology Partners (BTP), to integrate the DAML runtime with Hyperledger Sawtooth! In this blog post, I’ll describe why we believe it’s important to architect a DLT application independently of the platform, why a new language is needed for smart contracts, and why we are working with BTP to integrate it with Hyperledger Sawtooth.

Read the full blog post on hyperledger.org

Join the community and download the DAML SDK at daml.com

Release of DAML SDK v0.12.3

DAML Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

DAML Compiler

  • Support reading of DAML-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API

Documentation

Releases

DAML + VMware

It’s been a busy 7 days for all things DAML. First we announced that we open-sourced DAML, then that it is the exclusive smart contract language for the ISDA Common Domain Module (complete with open source library and reference app), now we are delighted to announce that Digital Asset have collaborated with VMware to provide support for DAML as a combined offering with VMware Blockchain!

Today we announced that we’ve been working with the team at VMware to integrate our smart contract language, DAML, with their enterprise blockchain platform, VMware Blockchain, and its community cousin, Concord. You can read the formal announcement here.

This is especially notable as it is the first third-party blockchain that DAML will be compatible with, giving you the ability to write your distributed applications in the best in class smart contract language and then deploy it to a choice of platforms depending on your requirements. Why would you write ledger specific applications and get locked into betting on one technology?

What is DAML?

If you’re already familiar with DAML you can skip past this section. But if DAML is new to you, it’s probably best described as a domain-specific programming language for modeling, automating, and enforcing multi-party agreements. You can learn all the details of what it means to develop smart contracts in DAML from this extensive blog series written by our engineers.

To summarize the key value proposition for DAML, think about productivity and future-proofing.

Be Productive. DAML has language-level constructs to deal with boilerplate concerns like signatures, data schemas, and privacy. These constructs allow you to focus only on the business logic of your project and leave lower-level issues to the platform. For example, do you find it hard to define fine-grained data permissions once your contracts involve many parties and data types? DAML allows you to define explicitly in code who is able to see which parts of your model, and who is allowed to perform which updates to it. And the runtime enforces the rules that you set out.

Be Future-Proof. The contracts that you develop will need to be upgraded, extended, and probably composed with other workflows over time. It’s inevitable. With DAML, upgrades are defined in code and can be executed in a non-disruptive, zero-downtime fashion; adding new roles and workflows to an existing solution is a trivial exercise; and integrating systems across domains is as simple as defining shared contracts. The code that you write today will not be broken by the requirements of the future.

Why DAML on other platforms?

Who wants to write applications for a single blockchain? While it may seem like there are dominant platforms starting to emerge within the DLT industry, in our opinion the ledger wars are only really getting started. We’ve heard from several of you, as well as many of our clients, that there are concerns about investing in capabilities that are specific to one platform when it’s unclear what the long term winner or winners will be. As more platforms from technology multinationals enter the market, this concern is only going to increase and those dominant platforms may not look so dominant anymore… Developers need choice.

DAML code is designed to run on more than just the DA Platform. This allows you to write your code and pick the deployment platform that best meets the needs of the organization. This allows you to write and test contracts on your own machine, using the Sandbox environment that ships with the open source DAML SDK, and know that target platforms can be switched seamlessly to meet needs without requiring changes to the application.

Why VMware Blockchain first?

VMware has deep technical expertise developing virtualization and distributed systems at scale. They share our vision for a world of interconnected networks with effective permissioning, high-throughput, and taking security, privacy, and uptime seriously. VMware’s customers deeply care about these properties, each of which aligns very closely to the benefits of using DAML over other smart contract languages.

“VMware is delighted to be working together on customer deployments to layer VMware Blockchain alongside DAML.”

Michael DiPetrillo, Senior Director of Blockchain at VMware


Some blockchain ecosystems have hundreds of customers and partners, VMware has hundreds of thousands and soon they will all have access to VMware Blockchain and DAML! So what better time to download the DAML SDK and start writing secure, distributed applications for multiple platforms.

Next Steps:

Join the community and download the DAML SDK at daml.com 

This story was originally published 11 April 2019 on Medium

The ISDA CDM: much more than just a standard for the derivatives lifecycle

How DAML helps ISDA’s CDM deliver an unparalleled level of precision

The financial world relies on computing standards to meet the almost insatiable demands of today’s global, always-on world for financial products. Without standards, processing the lifecycle of trades would be a very manual, error-prone, and slow process indeed.

The trading and managing of derivatives is one area of finance that has not enjoyed the full benefits of standardization. Responding to regulatory changes, high costs associated with current manual processes, and a demand for greater automation across the industry, ISDA developed the Common Domain Model (CDM)—the first industry solution to tackle this lack of standard conventions. The ISDA CDM for the first time creates a common blueprint for how derivatives trade events and processes are represented—paving the way for greater automation and efficiency at scale.

Download the DAML SDK and implementation of the ISDA CDM Event Specification Module.

The problem at hand is that standards must be implemented by all market participants—and if those implementations vary even slightly, the very benefits intended by the standard may not be fully realized. The CDM tackles this problem by introducing data rules that valid CDM instances need to fulfill and some calculation artifacts for, e.g., calculating a day count fraction. This is definitely a step in the right direction as it reduces ambiguities that might occur.

The cost and implementation risk of this new standard can be reduced even further though. To this end, ISDA teamed up with Digital Asset to create a CDM reference model in DAML, the open source smart contract language that Digital Asset created. Complementing the CDM with a reference library of DAML code allows developers to unambiguously construct lifecycle events with a machine executable specification. This degree of precision is unparalleled in financial markets and is expected to accelerate the standardization of processes across the derivatives industry.

In this blog post, we examine both the value and implementation risk associated with standards in general, how the CDM brings much sought-after efficiency and risk control to derivatives trading and lifecycle management, why having a CDM reference implementation reduces implementation risk, and why DAML was chosen for building that reference library.

Standards are necessary—but not always sufficient

Industry standards, such as FpML, have proven extremely helpful in the past with streamlining the communication between financial institutions by specifying an agreed-upon common schema for transmitted data. Having standards that deliver a common data representation is absolutely essential in financial markets, but standards typically do not address how those data structures are actually implemented and interpreted. Each market participant must, on their own, develop applications that understand and operate on the standardized data.

When the meaning of individual fields is typically only explained in a natural language and a common interpretation of all fields is not enforced, it’s quite possible that different implementations of a standard will lead to different results—likely resulting in reconciliation breaks across organizations. Consider, for example, that even in the highly standardized and highly automated equities markets, such implementation variations lead to costly reconciliation breaks daily that must be addressed manually.

To better illustrate the issue, first consider how the CDM brings much-needed clarity to how a valid interest rate swap and corresponding cash transfer event are represented: ISDA-1A CDM interest rate swap (left) together with a CDM cash transfer event (right) that is derived from the swap.

What’s not fully specified is how this event should be derived from the terms of the interest rate swap. For example, holiday calendars are required to roll out schedules and apply date adjustments. Once done, the relevant interest rate observation can be used to calculate the final payment amount by applying the specified day count fraction. This process is not easy on its own, and agreeing on it in the absence of a standard implementation is even more challenging.

The traditional solution to managing the inevitable disputes arising from this lack of standardization in the process of generating valid messages is to manually resend a corrected message. Fortunately, a better way has emerged.

CDM and DAML: a perfect combination for standardizing the market

In September 2018, the Barclays DerivHack was held to get feedback on the then-emerging CDM standard, as well as to explore the application of CDM to emerging technologies such as distributed ledger technology (DLT). Using DAML, the Digital Asset team won the London event because DAML—a language built to describe multi-party workflows and automate transactions between participants—proved particularly useful for describing derivatives contracts in terms of the rights, obligations, and market conditions that govern these contracts.

What came out of that event was the happy convergence of a coincidence of the desire to reduce CDM implementation risk on the one hand, and on the other availability of new technology—DAML—with uniquely differentiated characteristics for precisely specifying the sort of events described by the CDM. Since that event, we have been working closely with ISDA to discuss how to use DAML to standardize the business logic alongside the data representation.

The result of this work is the joint ISDA and Digital Asset announcement that we are collaborating to complement the CDM common data representation with a machine-readable specification, written in DAML, for how to implement the required business logic. We expect that the result of this collaboration—an open source library called the CDM Event Specification Module—will hasten the adoption of CDM and remove implementation risk.

Download the DAML implementation of the ISDA CDM Event Specification Module here.

The CDM Event Specification Module in action

As a first step, ISDA and REGnosys included DAML in the ISDA CDM Portal and exposed the CDM schema in DAML as a downloadable artifact.

The ISDA CDM specification, coded in DAML, is available now via the ISDA CDM Portal.

The CDM Event Specification Module further enriches the CDM by providing a library of pure functions—i.e. deterministic, side-effect free with no IO—that serve as a precise specification of the required business logic. Expanding the CDM standard with such a machine executable specification unambiguously specifies how events operate, e.g., how an upcoming CDM payment event can be derived from a CDM interest rate swap.

The Event Specification Module is written in DAML, whose pure part is very similar to Haskell—a long-established program language with a clean separation of pure and non-pure code. More importantly, it is a well-defined language—which simplifies the translation to other languages. The specification can, therefore, be automatically translated into executable code in other languages, guaranteeing that the business logic can be shared across various technologies. The module is currently available in DAML and Haskell, but the specification will also be compiled to executable libraries in other languages, like Java or C#.

For the interest rate swap example above, the Event Specification Module, for example, exposes a function that builds derived events—i.e., reset and cash transfer—for a given CDM contract:

The first line defines the function signature: It takes a set of reference data and a spec type—including the CDM contract—as input and returns the list of derived events. The second line binds the input variables used during the function execution. The entire logic of rolling out the schedule by applying date adjustments, applying interest rate observations, and calculating the final amount by applying the day count fraction is hidden behind it. This makes it very easy to use and, more importantly, defines a standard for the required business logic.

In addition to the CDM Event Specification Module, we have also open sourced a reference application written in DAML that illustrates how the library can be used to build a simple app for life-cycling interest rate and credit default swaps. Not surprisingly, it deals mainly with ledger-specific details given that the entire business logic is already provided by the Event Specification Module. This clearly demonstrates the value of standardizing the business logic as it avoids re-implementing and agreeing on complex workflows.

CDM and the Event Specification Module future-proofs your applications

In summary—standards have been extremely helpful in the past with streamlining the communication between financial institutions. The CDM makes a valuable and important contribution to the body of standards by providing a common data schema for events that occur throughout the derivatives lifecycle. But as we’ve seen with past use of standards, simply agreeing on a common data presentation can lead to reconciliation issues due to the inconsistency in the way in which transactions are implemented. The CDM Event Specification Module closes this gap by adding a machine-readable specification of the required business logic to the CDM—providing a library of pure functions that unambiguously define how events operate. Written in DAML, it is possible to translate the specification into runnable code in other languages, making sure that institutions can agree on the business logic even across different technology stacks.

But there is an additional benefit to the use of DAML in the Event Specification Module. There is work going on right now to determine whether or not DLT could add value to derivatives markets. In a DLT network, participants not only share a common data representation but also the business logic that operates on that data via smart contracts—which makes the need for precision all the more imperative should these markets begin a shift to DLT. The good news here is that DAML was designed to enable integration with other platforms, and abstracts away all platform-specific logic—which means that any applications written using the CDM Event Specification Module today, running on current infrastructure, will be portable to any current or future DLT platform that supports DAML!

Using the CDM Event Specification Module, you can gain the benefits of a common data and implementation standard now, with the comfort of knowing that your work is future-proof no matter which direction the industry heads.

Get started with the ISDA CDM Event Specification Module by downloading the DAML SDK and cloning the open source repo.

Join the community and download the DAML SDK at daml.com

This story was originally published 10 April 2019 on Medium

About the author

Thomas Weber – DAML Modeler, Digital Asset

Thomas Weber is part of the DAML Modeler team in EMEA contributing to the evolution of DAML. Prior to joining DA, he was a Senior Risk Modeler at Credit Suisse where he worked for several years. He was part of the management team responsible for pricing services and worked with equity derivatives and structured products including their pricing and lifecycle management.

Thomas holds a master’s degree in Quantitative Finance from ETH Zurich with specializations in risk management and derivatives pricing.