Daml provides an immutable evidentiary audit trail of DLT contract execution

In this blog series, the value of evidentiary, or audit ‘trails’ that record the results of contract execution has been voiced a couple of times: first from Simon and Neil in their blog entry What properties must an Enterprise smart contract language have? (“For a contract to be enforceable … a tamper-proof trail of evidence showing that agreements were entered into voluntarily by all of the contract’s stakeholders [must be preserved]”), then Ben and Edward in A new language for a new paradigm: smart contracts (“the very execution of a Daml program also creates a structured, human understandable audit trail that explains exactly why each action was performed”).

Why does Digital Asset place so much emphasis on this, and why exactly can a system based on our smart contract language, Daml, deliver a rich evidentiary trail while others cannot?

Should — or even can — the legal system be replaced by code?

Answering that question requires a bit of background first. Contract law is as old as civilization itself; Encyclopaedia Britannica calls out the example of an early 20th century BCE Sumerian record that “deals with such matters as the rights of persons, marriages, successions, penalties, and property and contracts.” In a very real sense, today’s legal systems governing contractual rights and obligations are the result of millennia of trial (no pun intended), error and continuous improvement.

And now, in the 21st century CE — at the dawn of blockchain technology — some proponents of smart contracts are arguing that “the code is the agreement”; that contract code is immutable, and any outcome of the code itself is necessarily what the parties intended. Despite the fact that even in the legal system, contracts are always subject to interpretation. See, for example, the 1998 paper Crystals and Mud in Property Law by Yale Law School’s Carol Rose, which points out cases in which an immutable record may be overruled by law, e.g., a court may revert a registered land title after the fact because “Government liens, fraudulent transactions, and, according to some courts, even simple errors or neglect in registration can produce unregistered claims that count.”

The paper above makes the argument that there have been attempts to ‘crystalize’ laws for centuries, yet they always get ‘muddied’ by after-the-fact interpretation — and we dare to think that smart contracts will resolve this problem?

The importance of building an effective ‘dispute resolution mechanism’

In a ‘code is the agreement’ model there is no recourse to dispute resolution through existing legal systems or centuries of modern common law precedent — even when an outcome results from a clear bug in the smart contract code. And many contracts today are plagued by bugs; see for example the attack on the DAO and others pointed out by Simon and Neil. Despite such incidents, many in the blockchain community believe it is only a matter of time until smart contract code becomes the final, legal arbiter of truth.

Today, there is simply no way to incontrovertibly reconcile the relationship between the intent of the parties to an agreement and the code implemented to automate that agreement. Legal contracts are very multifaceted instruments, and in many ways are written on purpose to invite interpretation. In a recent Technology Review article on how U.S. state legislatures are reacting to smart contracts, Mike Orcutt credits Angela Walch, an associate professor at St. Mary’s School of Law in Texas, with the observation that there are many deliberately imprecise standards of behavior in contract law, such as “reasonable” or “in good faith,” that can’t be encoded in software.

A day may very well come when AI-infused computer systems are trusted to render judgment on whether or not the terms of a smart contract were executed “in good faith”, but that day is not today — nor is it likely to be in the near-term horizon. Nevertheless, we continue to see curious legal language emerge, such as that from the State of Tennessee which recently enacted legislation stating, in part, that “no contract relating to a transaction shall be denied legal effect, validity, or enforceability solely because that contract is executed through a smart contract.” It will be very interesting to see what happens when this law is tested for the first time as the result of a buggy smart contract.

For a contract — smart or otherwise — to be enforceable, it has to be understood and agreed to by all parties, and a detailed record kept in the event that a dispute must be resolved.

Digital Asset’s ‘ledger maximalist’ strategy

At Digital Asset, we do not believe that legal systems should be replaced by code. Rather, we take the view that code used for contract automation must remain subservient to legal systems and dispute resolution, market rules, and commonly understood legal prose. Consequently, we explicitly designed Daml to enable the implementation of this hierarchy — delivering the benefit of automated workflows while ensuring parties continue to have the certainty afforded to them today by the common legal foundation they all share.

So what makes Daml different?

First, to be clear, every DLT system maintains an immutable log of events. But because of the complexities involved in programming most DLT systems, many DLT contract developers today fall into the familiar trap of bringing a traditional, single-party programming approach to the multi-party DLT environment. This results in treating the shared ledger as no more than a database acting as a shared state repository, and it can have a seriously negative impact on the quality and usefulness of those ledgers.

The problem is most apparent when working with entities that are governed by Master Service Agreements (MSAs). Alex and Ratko introduced the concept of MSAs in their blog entry “Trust but verify” is a valuable DLT model — does your language support it?, showing how the ability to directly encode MSAs and delegated rights enables Daml-based systems to reduce the possibility of ‘liveness’ issues. This ability also has a direct effect on the value of data on the ledger.

Very little, if any, of an MSA is actually coded into today’s systems; market members simply abide by the rules of the agreement because it is enforced by the legal system, which compels all players to abide by the rules. Because of this, most entities governed by MSAs are actually quite simple today and hide a great deal of complexity that is implicit in the MSA and similar legal documents. Not surprisingly, it’s the delegation of implicit rights through the MSA that allows these systems to work.

When a DLT system does not support rights delegation, every party affected by a transaction must authorize the transaction. The problem is that in such a design, the coordination of signatures is done ‘off-ledger’, which complicates state management as large portions of the system state end up being captured in off-ledger coordination channels or document sharing channels. As logic inevitably creeps higher and higher in the stack into bespoke layers developed, managed and maintained by each party, the amount of data that actually finds its way to the ledger becomes limited. Furthermore, some of the more difficult to implement security guarantees of the systems being built — data integrity and confidentiality — now become the concern of the application developer.

At Digital Asset, we believe very strongly that all state for business processes should be captured and managed by the ledger, and consider ourselves ‘ledger maximalists’ — using the ledger as the single storehouse for state management, data management, and distributed logic. In a Daml-based system, the semantics of the MSAs are captured directly on the ledger, and the platform is able to capture delegation rights on the ledger as well (this is also known as transferable capabilities in the object-capability model).

In the financial world, using Daml to model the behavior of a central counterparty (CCP), for example, means storing everything on the ledger, from the initial trade message (e.g., FIX message), through all intermediate reference data (such as details of securities and accounts at time of execution) and multiparty authorization workflows, right through to the final confirmation message. Ironically, a lot of effort is being expended today to create off-chain networks to speed up processing of the Bitcoin and Ethereum public networks. While off-chain networks can be great for scaling public networks when the business logic is simple, the strategy may not fit in with a legal system which requires an auditable trail and where workflows aren’t fully collateralized.

Daml delivers immutable contracts on the ledger

When parties choose to enter into an agreement on a Daml-based system, they authorize the rights and obligations associated with the MSA and contracts are created from contract templates that define their structure (state and choices). As Martin and Jost explained in The only valid smart contract is a voluntary one — easier said than done, whenever a party exercises a choice to instantiate, progress, or complete a business process, the result is the creation or archival of one or more contracts on the ledger.

This is because Daml is based on the principles of functional programming and contracts created in Daml represent a specific business process state. Once a Daml contract is recorded to the ledger and made active, it cannot be altered; when a choice is exercised on an active contract, that contract is archived, becomes inactive, and potentially one or more new contracts are written to the ledger reflecting the new process state resulting from the choice that was executed. The same principle applies when a parameter of an existing contract needs to be changed — an update choice results in the archival of the contract and creation of a new contract with the updated parameter.

In their blog, Martin and Jost illustrated the Daml business flow for a simplified OTC call option, and expressed the visualization of this transaction as follows:

The parameters of the contracts in this example, such as the strike price or the logic of the contract, cannot be changed after the contract has been created. The contracts in the workflow are ‘linked’ through the choices that are exercised by the respective stakeholders, providing the history and provenance of contracts.

Daml templates, which capture the contract logic and functionality from which contracts are instantiated, are immutable as well. This is crucial — as otherwise the behavior of a contract could be changed after the fact. However, in the case that the functionality of an existing contract must be changed or amended, all the stakeholders of the existing contract need to agree or are forced by court order to agree to that change or amendment. Such a change is yet another multi-party workflow, which can be expressed in Daml in the form of a workflow, where each stakeholder accepts the proposed change or amendment. Once all stakeholders have accepted, the existing contract is archived and a new contract instantiated from the new Daml template.

Daml ensures that the ledger delivers a rich, immutable, evidentiary audit trail

All of this activity — the reasons for the creation and archival of contracts, the corresponding flow of authorization, and the contracts themselves representing each change of business process state — is written to the ledger in the form of a transaction graph. Any reference data required for validation exists or is also evidenced on the ledger, delivering a rich and detailed immutable audit-trail containing the full history and provenance of contract events, including all state that affected the workflow at the time of execution.

In a Daml-based system, every intermediate step is carefully recorded on the ledger, which now provides a rich history of how the transaction proceeded through a set of intermediate agreements. Returning to the OTC call option example, the transaction graph can be visualized as follows:

The OTC workflow consists of four transactions submitted and authorized by the different parties in the workflow: the bank, Alice, and Bob. Each Exercise transaction consumes the contracts created in previous transactions — thereby establishing the provenance and links between transactions and contracts — and leads to further contract creations or exercises.

We call the creation and archival of contracts on the ledger ‘events’, which are tied together as part of the transaction graph. If you examine the ledger flow of a trade registration on an ‘everyone signs’ platform, you would likely find just a single ledger update to record the trade after all of the off-ledger work was done coordinating signers. In most real-world enterprise scenarios we’ve come across, this signature coordination is in itself quite complex, and it is critical to capture data about this workflow. On a Daml-based system, each trade registration can result in scores of ledger events, as all state changes occur on-ledger — leaving a rich and immutable evidentiary audit trail with full history and provenance that is accessible to all parties to the transaction. Although this may seem like a lot of data flows, the fact is that the same amount of processing is being done — it’s just all being done on-ledger as opposed to some combination of on-ledger and off-ledger, and recording all this data in one place is very valuable.

If Alice, Bob, or the other parties involved in this transaction (the bank or securities depository) were to later dispute a transaction, what data would be available to help settle the dispute? The Daml transaction graph provides details on who exercised which choices that led to the archival and creation of further contracts, with all intermediate steps recorded on the ledger as part of a transaction, and the relationship between transactions through references to contracts.

In contrast, if much of the processing were done off-ledger, the ledger may very well only hold the final state of the transaction — providing little data to help in the dispute. In the OTC call option example, the final state only consists of Alice holding the money and a contract where Alice must deliver the shares to Bob, but contains no representation of the multiple stages of the workflow and how this final state was reached.

Additional benefits of a consolidated and robust audit trail

Being a ‘ledger maximalist’ has the extremely important added benefit of fixing much of the data hygiene problem prevalent in the industry today.When all data relative to a trade is contained in a single, shared repository with a robust audit trail in a recoverable state, that data can be effectively modeled and used to further improve business results. For example:

• Real-time availability of actionable data allows businesses to focus on critical areas of improvement
• Direct access to particular views of ledger data can simplify reporting requirements for market operators, participants, and regulators by eliminating the need to establish data warehouses
• The availability of uniformly clean and structured data can open the door for machine learning to continuously scan for trends

Our decision to design Daml as a functional programming language also contributes to the ability to more easily use formal verification techniques on Daml contracts. This will be the topic of the next entry in this blog series.

Read Part 8: How difficult is it to write correct smart contracts? Depends on your tools!

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 31 July 2018 on Medium

About the author

Sören Bleikertz, Ph.D, Senior Software Engineer — Platform Engineering, Digital Asset.

Sören leads the engineering team responsible for the DA Platform architecture. Previously, he was a security researcher and software engineer at the IBM Research Lab in Zurich, working on virtualization and cloud security for IBM’s products and services, and served as a security consultant on large telecom cloud projects for IBM.

Sören holds a Ph.D in engineering from the Technical University of Darmstadt in Germany for his thesis on the automated security analysis of virtualized infrastructures.