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):

But 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 Hoogle, HLint, 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