Daml enables reconciliation-free, post-commit DLT verification

In The only valid DLT contract is a voluntary one — easier said than done, Martin and Jost delivered a very thorough explanation of how Digital Asset’s contract modeling language, Daml, provides native support for modeling the rights and obligations of parties to an agreement. But they left a bit of a cliffhanger, stating that “this exclusive Daml feature can also help streamline business workflows — which has huge ramifications on the way these workflows are automated through the ledger for certain DLT architectures.” In this blog entry, we’ll pick up this thread and explain how Daml allows for architectures that would not otherwise be possible (if you haven’t read Martin and Jost’s blog post yet, go ahead and read that first — we’ll wait).

Let’s first step back and remember the primary appeal of DLT platforms: they provide a mechanism whereby multiple mutually distrusting participants can share a common ledger. The ledger provides a “single source of the truth”,and every participant can easily detect and prevent any non-conformant changes to this common ledger, be they by mistake or by malice.

The first implementation of a distributed ledger, Bitcoin, is essentially a decentralized network “operated” by independent entities called miners, and designed to manage cryptocurrencies. The goal was to replace trust in government-backed fiat currencies with a value-exchange system that did not rely on trust, but rather expected participants maintaining full nodes to verify the validity of every block of transactions before acceptance. If, for example, a miner attempts to create an invalid block, the validating participants simply ignore the block and any further blocks building upon it.

This model works very well for cryptocurrencies, ensuring that the integrity of the shared ledger remains provable in an environment where there is, by design, no legal or regulatory control over the network. But many complex markets, such as those in finance, are heavily regulated, and the emergence of DLT will not change that. Any use of DLT in these markets must conform to the rules and regulations that bind that market. As Simon and Neil first expressed in What properties must an enterprise smart contract language have?, a primary requirement of any highly regulated market is data privacy, meaning that “for a contract to be confidential, only the parties affected by the contract can have the right to view contract details by default.” How a DLT is architected to maintain the integrity of the shared ledger while also preserving this requirement for privacy is a fundamental indicator of how well that architecture will succeed in these markets.

Regulation isn’t the only consideration, however. At Digital Asset, we realized very early on that DLT architectures built to support cryptocurrencies could not model financial markets very well because they were tuned to the concept of owner-controlled, anonymous and fungible tokens — a simple scenario that is fairly easy to express. Financial markets, on the other hand, are almost exclusively built around managing debt — which requires the ability to express a wide variety of forms of debt and their conditions, a far more complex problem. In addition, the two-sided pseudonymity of cryptocurrencies is not desirable as the value of debt is ultimately connected to the credibility of the obligor.

It should come as no surprise then that the “don’t trust, verify” model that works for cryptocurrency transaction validation won’t efficiently serve financial markets. This is most evident when considering one of the key reasons for adopting DLT in the first place — automation of complex processes across businesses — and it mainly comes down to the inability of most smart contract languages to manage the delegation of rights.

Most readers are probably aware of the Power of Attorney, a very common and simple agreement that delegates legal authority to another party to act on one’s behalf in a specified range of matters. The agreement can give total authority, or contain controls that restrict parameters such as the scope of powers delegated and conditions under which the agreement is automatically revoked. Once this power is delegated voluntarily, the designee is free to take any actions covered under the agreement without asking further consent while the Power of Attorney is in effect. It would rather defeat the purpose of the arrangement if every subsequent decision had to be explicitly authorized!

Today’s financial markets have a similar delegation mechanism. Joining a market typically requires entry into a Master Service Agreement, or MSA (the exact term may vary from market to market but they are similar in their objectives). These agreements very clearly state up-front the rights given to each party, and under what circumstances authorization is required of the participant or — importantly — is delegated to the designee as defined by the agreement. Once the MSA is voluntarily agreed to, the market operator does not need further authorizations for actions covered under the MSA while it is in effect. An MSA is typically designed to create an efficient market — just as a Power of Attorney allows for the efficient disposition of personal and business affairs.

Faithful action of rights holders and market operators is guaranteed by courts of law, with stiff penalties and probable prison time for abuse of fiduciary powers. How, then, can we apply this real-world model to the world of DLT, where the automation of contractual workflows is a necessary objective?

As a quick point of review, remember that every contractual agreement explicitly or implicitly defines two types of rights: the right to authorize changes, and the right to validate (verify) that all changes made are in compliance with the terms of the contracted agreement. In a DLT environment, parties with the right to authorize changes to a contract would be assigned a corresponding right to authorize changes to the ledger. All parties to the contract hold the right to confirm the validity of changes to the ledger, just as they would have the right to confirm validity of changes made to a traditional contract.

A natural and efficient DLT topology for markets operating under an MSA, then, assigns unilateral, well-defined privileges for maintaining the ledger to the operator (or operators — there may be several), but also guarantees that all parties are notified of any transactions that pertain to them — and preserves their right to independently verify those transactions. To use a phrase made popular during the U.S.-Soviet Union nuclear disarmament talks of the 1980s, one could call this a “trust, but verify” approach — where market participants place a wary trust in the market operators that control that agreement, but retain full power as “verifiers” to keep the operators honest.

Here’s the problem: most contract languages cannot distinguish between authorizing and validating rights. This makes perfect sense for public blockchains in which all participants of a market can validate all transactions. But when applying the same languages to distributed ledgers with data confidentiality, where participants only validate those transactions in which they participate, this can put a serious strain on the contract developer, the underlying DLT architecture, or — more likely — both. Let’s discuss the implications by walking through a few examples.

In their blog, Martin and Jost illustrated the workflow for a simple OTC call option, where ‘Alice’ made an offer and ‘Bob’ accepted. They showed that, because rights and obligations are native constructs of the language, Daml is able to model the fact that once Bob accepted the offer, Alice’s authorization was not required for Bob’s subsequent choices on that contract (to exercise or allow the option to expire) even though those choices put Alice into an obligable position. Daml allowed Alice to delegate her authorization to Bob.

Now let’s expand the scope of that illustration to exchange-traded call options. To participate in the exchange at all, Alice and Bob must first agree to the exchange’s MSA — which almost certainly includes the term that once a bid and ask are matched, both parties “pre-authorize” the exchange to create a matched call option, putting the seller of the call option into an obligation position (and the buyer as well, should they later choose to exercise the option — the obligation to settle the cash leg of the transaction) without requiring additional consent.

Without assistance in determining which parties have authorizer rights, either the contract developer must manually code each of these rights and authorizations explicitly, or the underlying ledger architecture must require every party to every contract to authorize every action taken on those contracts pre-commit in order to maintain provable integrity of the ledger.

Yet, most DLT architectures do require such a pre-commit round of approvals because they receive no knowledge of delegated rights from the contract itself. This is in direct opposition to the terms specified in the MSA, but perhaps more troubling is that they rely on pre-commit consensus mechanisms based on shared state machines run off-ledger to ensure the integrity of the ledger, which can create serious bottlenecks.

Returning to the OTC call option example put forth by Martin and Jost, consider that Alice places an ask order into the exchange and then her IT system goes down, perhaps for days. The exchange matches Alice’s ask with Bob’s bid, but the option cannot be committed to the ledger because Alice’s system is not available to provide the (unnecessary) authorization.

Multiply this by several hundred market participants, generating thousands or potentially millions of bids and asks that must be matched throughout a trading day, and you have a DLT system with a serious liveness problem and applications (or wallets) with very complex state management (the negative impact of off-chain state management is discussed in greater depth in this blog post). Such interdependency of one institution’s service on another’s availability can have an adverse impact on scale. It may be possible to work around these issues by trying to code-in breach error handling, but this is extremely difficult, error-prone, and not possible in many situations.

A DLT architecture based on Daml contracts does not suffer this problem, as Daml was specifically designed for modeling the rights of parties and is built around a certain concept of trust, which defines sufficiently strong identities and infuses trust directly into the contracts. This gives the workflow modeler the tools and flexibility required to clearly express who decides how to proceed (has authorizer rights), when those rights are delegated to the market operator per an on-ledger master agreement, and who is responsible for validating contract compliance (has validator rights). This helps to improve efficiency and reduce interdependency risk by limiting the number of parties involved in transactions in a way compatible with the business processes being modeled — avoiding the operational dependencies and inefficiencies of state-based consensus algorithms and, theoretically, improving scalability of the overall system by reducing the set of validators to only those affected parties that truly must participate.

The level of granularity in expressing rights and obligations in Daml is a distinct advantage in coding contracts for markets that operate under an MSA or any similar up-front contractual agreement. Daml provides a very natural means of accurately encoding the MSA onto the ledger, including any specification of limitations on what the exchange can do (maximum size, restriction to specific tickers, etc.). Even though market participants may delegate certain rights through the MSA, they are still always able to see the creation of their options on the ledger so they can validate them and track their obligations in real time. A Daml-based system effectively replaces pre-commit authorization with post-commit verification as specified by an MSA which has been expressed in Daml.

One parting thought. In the cryptocurrency-based contract model enabled by Ethereum, the only way to undo the damage from the DAO attack was to rollback state changes on the chain and, effectively, pretend the attack didn’t happen. In Daml, stakeholders to a contract can mutually agree to amend state in order to undo the damage of an attack or mistake, or to comply with a regulatory change, without losing history and provenance of why this amendment was made. The difference with Daml is that the chain is not altered; the amendment is added as part of the historical record. In this way we do not lose the history of the change, the justification is plain for stakeholders to see, and all participants can verify that the amendment is in fact correct. Daml’s delegation capability enables, in regulated markets, authorized market participants to make these “trusted” changes in a verifiable manner — the stakeholders don’t invoke the change but have the ability to verify it.

Choice of contract language is critical in determining how well a given DLT architecture is able to automate workflows for complex markets. Daml is the most natural language to map current market rules and regulatory structure onto a DLT architecture.

Today, markets operating under MSAs process trades post-commit but require reconciliation of all trades to keep all participants’ information in sync. Daml enables a different approach — transaction processing with post-commit validation, with stakeholder-based, on-demand, and history-preserving error correction only required on failure paths. For complex markets, it is a superior mechanism for bringing the full promise of optimized, automated workflows on a distributed ledger to life. This Daml feature will greatly facilitate automation across markets.

As this blog series progresses, our colleagues plan to focus on further topics such as Daml’s contribution to privacy preservation and the importance of using formal methods to verify contracts.

Read Part 6: Keeping smart contracts private is hard — unless you truly understand them

New to this series about Daml? Click here to read from the beginning!

Join the community and download the Daml SDK.

This story was originally published 14 June 2018 on Medium

About the authors

Ratko Veprek, Ph.D., Distinguished Engineer and Senior Product Architect, Digital Asset

Ratko leads the product team responsible for the Digital Asset Platform. He previously worked as a quant researcher, software developer and as a technology-focused manager for several proprietary trading, asset management, and software engineering firms. In 2015, he decided that he did not ever want to deal with another reconciliation problem again and started to seek out a definitive solution, a career path that led to the invention of Daml.

Ratko holds a Ph.D. from the ETH Zurich for his thesis on Computational Optoelectronics of Semiconductor Nanostructures. During his studies, he focused as interdisciplinary researcher on how to use numerical mathematics and simulations to solve natural science problems.

Alexander Bernauer, Ph.D., Distinguished Engineer and Head of Platform Engineering, Digital Asset

Alex leads the engineering team responsible for the Digital Asset Platform and the Daml SDK. He previously worked as a Site Reliability Engineer (SRE) at Google for what is today Google’s Big Query service. Before that, he has been leading the R&D team of a startup innovating in the space of telematics, tracking, navigation, mobile communication and encryption for the logistics and the insurance industry.

Alex holds a Ph.D. from the ETH Zurich for his thesis on Compiler-Assisted Thread Abstractions for Resource-Constrained Systems. During this period of interdisciplinary work between both theoretical and applied computer science — as well as distributed systems and programming abstractions — he has been studying how programming abstractions can be efficiently executed while maintaining their abstraction power.