Modern society depends on the secure transfer of value in nearly every aspect of life — from transfers of stock, bonds, or cash on the books of financial markets to the consumption of digital content for a fee. Despite the pervasiveness of financial transactions and decades of operational experience executing them, two major problems remain unsolved:
- Executing transactions is still complex, opaque, expensive, and full of operational risk.
- Despite blazingly fast innovation in other areas of software development, innovation in the world of cross-enterprise workflows is painfully slow.
Why?
Part of the reason is that financial innovation is by nature business-driven, and, despite a lot of talk to the contrary, the IT systems driving this innovation are often an afterthought. This means whenever someone innovates with a new financial product — a better way to insure, a collateralization scheme which reduces risk, a better way to reduce exposure to interest rate fluctuations of a foreign currency — each party interacting with this new financial product builds new systems to handle the new flows, integrates with the rest of its existing systems (which touch the same accounts and assets), and builds reconciliation processes with its counterparties.
Furthermore, many financial flows are inherently complex and can include many parties and many workflow stages. Although each piece of this complexity is introduced for good, inherent, business reasons, specifications are often incomplete, systems are implemented incorrectly, or they simply evolve over time. As ecosystems and complexity grow, it becomes exceedingly difficult to drive, build, test, and rollout new ideas and innovation grinds to a halt.
Digital Asset’s vision is for value transfer to be simple, efficient and secure, driven by a new distributed ledger paradigm that unleashes web-pace innovation unrestrained by data silos.
Distributed Ledger Technology (DLT) can enable this by combining a ledger synchronized among market participants with the deployment and automation of complex, multi-party workflows acting upon that ledger. Consider, for example, how some of the DLT use cases being worked on in financial markets can radically improve the transfer of value: eliminating the need for reconciliation in cash equities clearing and settlement; reducing counterparty risk throughout the lifecycle of credit instruments; lowering capital costs for repurchase agreement clearing and netting; providing real-time visibility to regulators; to name just a few.
Of course, as with any new technology, successful application requires carefully matching the available options against the specific business needs. When comparing the many options flooding today’s market, most of the industry’s attention so far has been focused on the synchronized ledger — how architectural decisions made by various DLT vendors and consortia impact on-chain data integrity and confidentiality. The ledger architecture is certainly a key decision point, as it is responsible for permanently preserving and protecting the state of business processes as agreements are executed.
But what about that other aspect of DLT, the automation of multi-party workflows?
The executable code segments that define workflows on the ledger are typically referred to as smart contracts. Many DLT vendors choose to pair their ledgers with programming languages that are general-purpose and familiar in an effort to appeal to the most widespread developer skills.
As a result, in some cases, smart contracts are not really all that smart at all.
DLT is not just a fancy database architecture, and smart contracts are not normal applications. Smart contracts are an entirely new class of applications that span multiple untrusted actors — simultaneously being deployed to and executed among these entities in a distributed environment. In practice, coding complex contracts is incredibly difficult and error-prone in most smart contract language implementations.
This is a vitally important issue because the accuracy of the state of a distributed ledger is largely determined by the accuracy of the smart contracts that drive ledger updates, and the integrity of the ledger will be brought into question if there is no faith in the veracity of the contracts stored on it. Consider that, in every DLT implementation, multiple parties are sharing the exact same code to automate their workflows through the shared ledger — that is, after all, the nature of a DLT. But because all code is shared, any errors in the code are greatly amplified across all parties.
This can be a serious risk. Especially in financial markets, where workflow automation can only be trusted if the contracts driving the workflows can be guaranteed to execute precisely as intended. Without such a guarantee, automation is simply not possible — and the value of moving to a distributed ledger architecture is greatly diminished.
The distributed ledger is often referred to as the “single source of truth”, the storehouse of correct data, but in reality, workflow automation pushes the burden of correctness up from the distributed ledger to the smart contract. Blockchains and distributed ledgers are immutable once the data is on the ledger, but they make no guarantees on the quality or veracity of the data inputted. It is the contract that defines how truthful the ledger really is. And this demands a different way of thinking about ledger architecture as a whole.
“A good architecture is not created in a vacuum. All design decisions at the architectural level should be made within the context of the functional, behavioral, and social requirements of the system being designed… we can identify the properties induced by the Web’s constraints… to form a new architectural style that better reflects the desired properties of a modern Web architecture.”
Roy Fielding
Roy Fielding wrote these words in his 2000 doctoral dissertation introducing the REST (REpresentational State Transfer) architectural style for the Web. Although taken for granted today, it was not obvious at the time that REST — something quite different from the traditional styles of the time — would play such an important role in the emergence of the Web as a platform. The situation with DLT is quite similar. DLT is a completely new paradigm, and smart contract languages are the abstraction layer of distributed ledgers. The requirements and constraints of this new platform should form a new architectural style that better reflects the desired properties of a distributed ledger.
Digital Asset are committed to developing a suitable architectural style for DLT smart contracts, and believe that the very design of smart contract languages themselves plays a foundational role. It is our position that — in order to minimize the risk of errors in shared contract code, increase security, and accelerate innovation — languages selected to build smart contracts must be designed specifically for a DLT environment and imbued with support for writing error-free contracts. Taking this even a step further for financial markets, contracts driving the transfer of value require additional domain-specific precautions.
There hasn’t been enough discussion around the pursuit of correct smart contracts in languages and architectural design patterns. In the spirit of sparking more dialog, this blog is the first of a multi-part series in which our language engineers will explore smart contract languages from a number of angles, with a focus on DLT implementations targeting systemically consequential, inherently complex, highly regulated markets — in particular, financial markets, as they represent an extremely difficult set of requirements that once fulfilled can be applied to less demanding industries. If you can satisfy the needs of financial markets, you can satisfy the needs of most other industries where value is transferred.
Despite highly public failings, most DLT platform providers, eager to capture the largest developer community, still focus on general purpose languages with wide usage — even though these languages were designed for a very different problem domain. The next post in the series will explore these failings in more detail and propose a set of requirements that any language used to write smart contracts must satisfy.
Read Part 2: What properties must an enterprise smart contract language have?
Join the community and download the Daml SDK.
This story was originally published 18 April 2018 on Medium
About the author
Shaul Kfir, CTO Architecture & Strategy, Digital Asset
Shaul is a software engineer with a background in research cryptography, implementing Zero Knowledge Proof protocols for Secure Computational Integrity and Privacy (SCIP). He served as CTO for two previous startups in Tel Aviv. Shaul served as a Lieutenant Commander in the Israeli Navy, was a software engineer at Intel, a team member of the SCIPR cryptography lab, and a visiting scientist at MIT’s Computer Science and Artificial Intelligence Laboratory.
by Shaul Kfir
April 18, 2018
