To DLT, or not to DLT? That is not the question
Daml allows developers to build distributed applications to meet multiple market structures
Some have argued whether or not distributed ledger technology, or DLT, delivers on its promise of a generational leap over existing technology. The arguments tend to center around the DLT value proposition only being valid in a context involving a group of mutually distrusting peers, when individually-held data silos are replaced with shared, mutualized infrastructure.
At Digital Asset, we feel that is too limiting of a context—and have engaged in many DLT opportunities that are not inherently peer-to-peer. In this blog post, I’ll demonstrate that writing many applications in Daml—an open source language designed specifically to encode multi-party business processes, often referred to as smart contracts—offers benefits far beyond those typically associated with DLT technology.
I’ll begin by discussing why peer-to-peer use cases are a lot harder to realize than commonly thought, and then shift focus to the near-term gains that can be achieved in scenarios that involve a central trusted entity. I’ll walk through a use case completely modeled in Daml—the lifecycle of a cash-settled option—to point out some of the benefits that Daml uniquely brings to business workflows. I’ll also draw comparisons between Daml-driven ledgers and traditional technologies typically used to solve such problems. Finally, I’ll show how easy it is to adapt this application to a decentralized trust model. No other language environment offers such features out of the box and it would require non-trivial engineering work to achieve a similar outcome using more traditional tools.
I’m using a financial business process as an example here, but my points are equally applicable to similarly structured processes in any industry.
Download the Daml SDK now and try out the example as we go along
Symmetric scenarios
Many peer-to-peer transactions flow between mutually distrusting organizations in environments where no trusted central counterparty exists. As each organization is on an equal footing with the others, no single entity can be agreed on to be in full control of transactions. We refer to these as symmetric scenarios—where the trust relationship is uniformly distributed among all parties. In finance, consider the global collateral/DvP use case described in this blog post—there is no trusted legal entity above the central banks or central security depositories (CSD) that could mediate transactions.
Solutions for such situations are hard to build due to many factors. Chief among them are the politics involved in coming to an arrangement between distrusting parties, the logistics of coordinating any technology project across what can be a widely disparate set of entities, and the limited capabilities of traditional technology. For example, the T2S project had to be approved by 24 CSDs, took roughly 10 years to build, and covers only Europe and two currencies—while it has cost around $250M USD to develop and has an annual running cost close to $100M USD. Even with all this time, effort, and cost, it is not truly a symmetric solution as it runs on centralized systems and is operated by a consortium of four central banks!
A blockchain-based DLT can remove most of the limitations of traditional technology, allowing infrastructure to be truly mutualized across the trading parties with integrity and security, but the political and logistical factors remain. Many DLT consortium-oriented projects—announced with great fanfare and promise—never get out of the prototype or PoC phase, from which one can reasonably conclude that technology is not the only, and maybe not even the largest, hurdle to overcome in symmetric scenarios.
Asymmetric scenarios
In contrast, many peer-to-peer business transactions are facilitated by a trusted third party that—either by legal or industry mandate—has been established to unilaterally and impartially deliver a set of services to a group of peers. This sort of trust relationship is very common in market infrastructures, for example. Although some DLT proponents call for the disintermediation of all ‘middlemen’, such infrastructure serves a real and important purpose. Incumbent market infrastructures—exchanges, clearing houses, CSDs—and their major customers—custodians, investment banks, broker-dealers—have significant existing connectivity to a broad network of customers. They join the dots in the financial ecosystem, and are often sanctioned by regulation that allows the rule of law to govern their activities.
We refer to these as asymmetric scenarios—where the trust relationship is delegated by all parties to some central entity. Applications in such a context are much easier to realize because the political, infrastructure and logistical issues inherent in symmetric scenarios are reduced—putting technology risk into the spotlight. Daml solutions can be constructed such that services flow through a central party, but each participating organization still maintains full control over how they use the services and the data that they generate, making them suitable for use cases where centralized market infrastructure is involved. Such a solution can be conceptualized as a Software as a Service (SaaS) offering with the added benefits typically associated with DLT technology: a shared immutable data store with strong integrity, privacy, and authorization guarantees. The major difference to a fully mutualized solution is that the above guarantees are not provided by mutual verification, or proof of work or stake mechanisms, but by the central counterparty, which verifies all transactions. And even in such an asymmetric setup, participants can still validate the consistency of their view of the ledger, and detect data manipulation that does not conform to the agreed workflows.
Daml supports both symmetric and asymmetric scenarios. This post will build up the code for an asymmetric scenario and then show how easy it is with Daml to adjust to a symmetric scenario should business needs change.
Using Daml in asymmetric scenarios
Daml is a precise, deterministic, and verifiable language with inbuilt privacy and authorization mechanisms, designed specifically for the expression of business processes. Last year our team delivered a nine-part blog post series detailing the Daml value proposition in-depth (this post is the start of that series if you missed it).
When applying Daml to asymmetric workflows where users of a solution trust the solution provider, all Daml contracts specify the provider of the solution as the sole signatory, delegating the right to see or transform the contracts to the other participants. For example, an online shop might implement an offer as a Daml contract with the shop as the signatory and a purchase choice offered to potential customers. Similarly, an order might be implemented as a Daml contract with the shop as the signatory, a choice to be exercised when the package is ready for dispatch, and the customer as an observer for tracking the progress of their order. Customers accept that they are not signatories on the transactions because they trust the shop, and they have the rule of law to call on if the shop breaches that trust.
From an infrastructure perspective, users of a Daml-based solution can engage with the solution provider either through traditional means (standard messaging protocols, for example) or by operating their own participant node in a DLT network. Operating a node allows a participant to maintain a local copy of all contracts that they are entitled to see, and gives them the option to compose their own internal Daml workflows with the workflows of the external solution. For example, a procurement department may want to enforce a four-eye policy to place orders.
Operator-centric solutions are also easier and far more efficient to maintain, as the solution provider can drive contract upgrades and rollbacks whenever required because they retain full control over the solution.
The cash-settled option example
Cash-settled options are useful tools for speculating on the price of just about anything—a stock, an index, a commodity—without worrying about taking on physical ownership. The basic lifecycle is straightforward, shown here by the example of a European Option:
- The option issuer (service provider) quotes a price for the option
- A client (service consumer) accepts the offer and pays the quoted premium
- At option expiry, the issuer closes out the contract and settles payment due to the client, if any
Our team at Digital Asset developed the Daml code for this use case in a series of three iterations to illustrate how easy it is to use Daml to take a project from prototype (minimum viable product) through to production readiness (with all the bells and whistles). You can find the completed Daml project in the DA Repository on GitHub; for the purposes of this post, I’ll pull in snippets of the code that illustrate some of the key points that I want to make about Daml in relation to this use case.
First—model the basic options contracts
The core concept in Daml is the contract template—a construct that specifies the rights, responsibilities, and actions available to the parties that choose to extend or enter into a contract of that form. As is the case with most ledgers, data written to a Daml-driven ledger is immutable and, as a Daml workflow progresses, completed contracts are archived rather than deleted so that a full audit trail is preserved.
To get started with the cash-settled option example, we needed to develop three primary contract templates that correspond to the basic steps in the option lifecycle:
Quote - allows the issuer to quote a price for the option and extend this as an offer to its clients.
Option - when a client accepts the Quote, that contract is archived and an Option contract takes over the next steps of the workflow, including payment of the premium from the client to the offer issuer.
Fixing - when the expiration date is reached, the Option contract is archived and a Fixing contract manages the portion of the workflow that calculates and executes payment to the client, if any.
Let’s look at the Quote contract to illustrates a few key points:
Declare data schemas on-the-fly
Daml templates contain a with block that allows the developer to specify the schema of a data table on-the-fly and embedded with the business logic. We can think of the with block in a template as analogous to the definition of a table in a relational database, with fields corresponding to columns. The with block after template Quote, for example, will allow us to store contracts with fields quoteId of type Text, price of type Decimal, etc. in the underlying Daml-driven ledger.
The same code-first on-the-fly schema generation can be achieved with a relational database and suitable abstraction layers (indeed, Daml can run on SQL). However, putting that into practice on multi-tenant deployments requires very careful segregation of database schemas and fine-grained access controls for schema manipulation. Often, operational barriers lead to databases that capture data in serialized form, e.g. as an XML or JSON blob, or to CouchDB servers running under someone’s desk. A Daml-Driven ledger, on the other hand, offers any user the possibility of defining strongly typed data tables on-the-fly in a production-grade database.
Specify precise, row-wise authorization rules
Daml has fine-grained read- and write authorization built in. By default, a contract, corresponding to a row in a database table, can only be written, read, or archived jointly by all of its signatories. Any additional party that should be able to read or change the data needs to be given those rights explicitly.
In this template, the observer client :: observers expression specifies that the client of a specific Quote instance has the right to read the contract. If the issuer were to quote a different price for another client, the two clients wouldn’t know about each others’ Quotes unless they were specifically included as an observer.
Further, the controller client expression specifies that the client has the right to write transactions to the ledger that were built according to the logic specified in the body of the Fill choice. Here the issuer is giving the client the right to simultaneously archive a Firm Quote contract and create corresponding Option and CashEntry contracts on the ledger.
Some such operations could be encapsulated in stored procedures on relational databases, but their language is not amenable to encoding business workflows, they are not easily composable, are notoriously hard to debug, and tie an application to a single persistence technology. In practice, such concerns are typically handled in a layer above persistence, adding complexity to the technology stack and separating key aspects of the application logic from data definitions and business workflows.
Daml allows the developer to define very precise read and write authorization rules without fragmenting the code or blowing up the tech stack.
As mentioned previously, when a client accepts the Quote offer, that contract is replaced by an Option contract. The Option code reveals more features of Daml that are of interest to the contract developer.
Express complex state transition logic next to the data
The Expire choice of an Option contract implements the calculation of the option payoff from its terms and the fixing at expiry. This calculation is rather straightforward but can become arbitrarily complex in practice. For example, an interest rate swap needs to account for holiday calendars to determine payment dates, and employ non-trivial computations to determine the day-count-fraction between two calculation dates. Such business logic tends to form yet another layer in application stacks, far removed from persistence and authorization concerns. This makes it hard to reason about the possible states and state-transitions. With Daml, types of data and all the rules governing it are encapsulated in a single place, in one language, making applications easy to reason about and dramatically reducing the state-space developers have to handle.
Define workflow automation
We can also interpret the Expire choice of the Option template as a rule that should fire as soon as the option expiry passes and the corresponding fixing entry is available, thus automating parts of the business process.
Daml ledgers cleanly separate the rules and their execution. The ledger never changes without a party proactively submitting a transaction that they are authorized to perform. This separation of possible behaviors, encoded in the rules, from actual behavior, driven by automation, makes it easy to adapt to changing circumstances. This is in stark contrast to many other smart contract systems, where certain state changes are guaranteed to happen—thus requiring application developers to prepare their contract models for all eventualities.
In addition, thanks to the clear rules and small state-space resulting from processes modeled in Daml, such trigger-like automation tends to be near-trivial to implement using the uniform APIs offered by all Daml-Driven ledgers.
Next—strengthen data integrity
The core workflow already provides basic integrity guarantees by restricting the rights of the client. However, the issuer can still do everything. In particular, the issuer could create Option or CashEntry contracts out of the blue without proposing a Quote first. Therefore, the issuer party is a bit like an omnipotent admin—running the risk of creating a ledger with integrity problems.
One way to resolve this problem is to enrich the example by dividing the overall authority of the issuer into roles within the organization that have specific (and limited) rights. For example, defining an agent role that can only create indicative quotes and a trader role that can declare them as final—but neither role can create Option or CashEntry contracts directly. The workflow for this new staged pricing process is roughly as follows:
- The issuer delegates agent rights and trader rights to the new roles
- The agent provides an indicative quote on behalf of the issuer
- The trader converts this into a firm quote on behalf of the issuer
Achieving this next iteration of the workflow required me to add new Agent, Trader, and Pricing templates to my solution. Let’s see what we can learn from the Trader and Agent templates.
Compose subtransactions to atomic transactions
One of the most convincing features of Daml is that you don’t need to worry about being left in an inconsistent state when a transaction fails halfway through. For example, the Trader_Quote choice atomically
- Exercises the Archive choice on the quoteCid contract
- Creates a new Quote contract with a modified status and price
The do block ensures that both activities happen together or not at all. With RDBs, this requires careful management of database contexts and transactions. In Daml, state changes compose atomically—by default—by just writing do!
Subtransaction privacy
- The creation of a Pricing contract
- The creation of the indicative Quote contract
The Pricing contract contains sensitive information only relevant to the trader, whereas the Quote contract is additionally intended for the client. This is controlled exclusively through the signatory and observer keywords in the respective contract templates. Daml ledgers understand these privacy constraints and make sure that subtransactions only get shared on a need-to-know basis.
No additional lines of code are required to get this behavior—it simply works.
Finally—synchronize processes across organizations
Just as it became necessary to split the rights of the issuer, it can similarly be necessary to split the rights of the client. Internal processes can be very tedious and complex in large organizations; it may be the case that checks and balances are in place that require supervisory approval before a quote offer can be accepted.
We can divvy up the overall authority of the client as we did with the issuer in the previous iteration. Here we have decided to split the issuer's rights into a clerk role, which receives and requests approval to fill a quote offer from the issuer, and a supervisor role, which fills or rejects the request.
Finishing up the Daml for this project, then, required new Clerk, Supervisor, and Request templates. The atomic transaction within the Supervisor template is worth a closer look.
Composing transactions across participants
In an asymmetric Daml-based system, the only party that has to maintain a node is the operator—but should the participating parties choose to, they can operate their own nodes, too. Daml does not require the developer to be concerned about this; with Daml, it’s (almost) as fast to implement a composition of transactions across participant nodes as it is to do so for transactions within one node.
For example, the Supervisor_Accept choice above atomically
- Exercises the Archive choice of the Request contract that resides in the participant domain of the client
- Exercises the Fill choice of the Quote contract which is part of the shared workflow between issuer and client
A Daml-Driven ledger commits all of these changes atomically and preserves privacy despite the fact that different nodes are involved. Such behavior is prohibitively expensive to achieve with other technology solutions. This example is particularly compelling because it allows an external asset manager to have a local copy of its data and to compose its internal workflows with the ones of the issuer.
Go from asymmetric to symmetric trust models
To give the client full control over the data they have a stake in, and turn the asymmetric cash-settled option model into a symmetric one, one simply has to change the client from being an observer on Option and CashSettled contracts to a signatory. The workflows don’t change, but the client now has to verify all transactions that create or archive contracts of those types, preventing the issuer from breaking out of the agreed workflows.
Summary
Cross-organizational projects tend to be huge and suffer from long negotiation, implementation and testing phases. Daml can effectively remove many of the technical challenges, but technology does not solve hurdles grounded in the politics of organizational relationships. However, many of the technological challenges encountered in multi-entity projects are also present in operator-centric or organization-internal multi-participant applications. In this blog post I have tried to highlight the value Daml brings to such projects and how it paves the road to truly distributed solutions.
In either case, asymmetric or symmetric, Daml delivers a number of constructs that make coding so much easier than using distributed database technologies natively.
Join the community and download the Daml SDK at daml.com
This story was originally published 6 May 2019 on Medium
About the author
Bernhard Elsner, Ph.D. - Product Architect at Digital Asset
Bernhard Elsner works as Product Manager for the core Daml technology, with a focus on refining the product vision and design to bring the power of Daml to ever more use cases. Prior to joining Digital Asset he was a Pricing Actuary at Swiss Re, spending a lot of his time working on central underwriting and pricing systems as well as exploring ways to improve End-user development within the organization.
Bernhard holds a D.Phil (Ph.D.) in Mathematics from the University of Oxford with a specialization in Mathematical Logic.