By Natalie Lord
Digital Asset Modeling Language (DAML) is more important than ever before with the increasing adoption of blockchain technology and is leading the way in distributed-ledger technology.
At its most simplistic, DAML is the contract language of distributed ledgers. It’s an open-source programming language for writing distributed applications quickly, concisely, and correctly. It runs on the leading blockchain platforms which means that you can build your application now and pick which platform works best for you later.
Distributed applications are an emerging paradigm to improve on existing traditional languages and toolchains which are being challenged by the new digital environment. There are complexities such as cryptography and distributed state synchronization which required a ground-up redesign. DAML may not look like anything in the space but that’s because it is ahead of the curve and forward thinking with its intention.
DAML abstracts the underlying implementation details so you can just focus on getting to market faster. Built in simulation tools and a strong type system mean that you can be sure that the application is doing exactly what you expect it to. Code written in DAML is also easier to maintain, so you can rapidly iterate on your application once it’s running.
So where and how did DAML start? In 2014, Shaul Kfir co-founded Digital Asset with the intention of proving something to the financial services industry. He felt it provided an inefficient system for transaction reconciliation as well as being in danger of missing what blockchain technology could do to address its shortcomings.
As a consequence of this thinking, Digital Asset went to market with its own distributed-ledger technology – DAML, which takes advantage of blockchain, although not in quite the way Kfir had anticipated. To get from Digital Asset to where DAML is today took a feat of engineering.
As things currently stand, Kfir points out, large institutions hold the ledgers of record for many different markets. He says there are at least two problems with that. One is that the systems used by many of these infrastructure providers are old, which is to say you can’t use an API to go in and get a realtime view, but instead are forced to wait for that night’s batch to be run. Distributed ledgers don’t address this problem directly but have been designed explicitly to take advantage of modern technology.
Then there’s a second issue that’s more fundamental. A large financial institution can’t be in the position of needing to trust an API call into someone else’s infrastructure to learn that something has just shifted on one of its trades by a few million dollars. Each financial institution holds its own ledger of record that it can make reference to whenever needed. But then, with at least one entity on either side of a trade, this means there will be at least two ledgers in play, both of which are going to require reconciliation around each event since they both touch the same data. A distributed ledger synchronizes these separate ledgers as if they were part of the same database, whilst the reality is that each is controlled by one of the institutions that’s party to the trade.
But it’s not just a problem of outdated technology. There’s the issue of verification and then there’s also the issue of trust. Theoretically, a centralized reconciliation provider ought to be able to take advantage of newer hardware to become faster, more API driven, and less batch driven. But it would seem that the counterparties don’t really trust the centralized third party to hold all this information on their behalf. What they really want is to have their own copy of that data, no matter what.
Next week we look at how DAML can resolve this issue and examine the differences between a distributed ledger and a centralized reconciliation system.