Many industries are on the brink of the next technological revolution in record keeping. Ten years after Bitcoin made its splash, we’re seeing many inspired by some of the benefits promised by the technology outside of the money use case:
However, many are still unsure whether these benefits can be achieved, in part due to the modest speed of adoption of these technologies over the first ten years.
In this article I will lay out why we at Digital Asset believe that distributed ledgers and smart contracts are the next big step in the digitization of assets and processes. I will also offer an explanation of why adoption is taking so long to gain momentum, some of the common misconceptions around digitization of assets, and how we are addressing those obstacles within the Daml ecosystem.
“Record Keeping“ may not have the fashionable ring of “Blockchain”, “Smart Contracts”, or “Tokenization”, but it’s what all of this technology is about. Records of contracts, laws, and ownership, as well as the processes to change these records are foundational to society and industry. Consequently, the technology used for record keeping is constantly evolving, with each new innovation trying to solve problems present in the previous.
Physical ownership records, be it in the form of paper-based bearer instruments like promissory notes or cash, or centralized records like land registries, have been around for millenia. They solve the foundational problem of having an agreed and legally enforceable way to ascertain who owns what.
Unfortunately these paper-based records and processes are slow, expensive, and error-prone. Even before the advent of computers, special machines were developed to aid with the task of keeping crucial records accurate [1]. The advent of computers in the second half of the 20th century offered an enormous boost to the efficiency of keeping and updating records, leading to the broad digitalization of most asset classes including cash, stocks, bonds, treasury notes, and all manner of certificates.
Efficient distribution and communication followed soon after, first through point-to-point digital communication channels, and later the internet.
The resulting increase in the efficiency of data processing and communication, as well as the scale of the distribution of data, has brought the original problem of being unable to unequivocally ascertain ownership of an asset at a given point in time back to the forefront. Each record is now copied manyfold across a loose network of computers and record changes trickle through the network in multiple steps. Complex and expensive reconciliation is needed to keep all the copies in sync, and errors are commonplace leading to even more expense on dispute resolution and exception handling.
The computer revolution didn’t change the role of institutions in record keeping. Most records, be it bank accounts, insurance policies, health records, or land ownership, have a “master copy” controlled by a single, or small number of entities. These controlling parties are required as a matter of business, and often by law, to keep this data, which represents their clients’ legal title to those digital assets, accurate and safe.
Properly implemented distributed ledgers address these problems by granting more parties access to the master copy and codifying the rights of the trusted entities into verifiable actions. This removes the need for reconciliation and reduces the total trust required in the controlling institutions.
So why have we not not seen a rapid, wide-spread adoption of tokenization for a broad class of assets?
I believe there are several major reasons for this, but also that all of them can be overcome with a shift in mindset and recent technological development. The time is ripe for a change.
Tokens are digital bearer instruments. A token should represent a redeemable claim to a security and derives its value from that claim. Holding the token is equivalent to owning a claim to the asset and ownership of the claim should be freely transferable. In these respects, tokens mimic cash:
The said [Federal Reserve] notes shall be obligations of the United States [...] They shall be redeemed in lawful money on demand at the Treasury Department of the United States, in the city of Washington, District of Columbia, or at any Federal Reserve bank.
Many have offered multisignature as a way to add a layer of legal control on top of a token (ourselves included!) and this approach does have some appeal as a final step in the process of moving and controlling money. However legal frameworks and processes involve far more coordination and authorization than the simple final exercising of private keys. This makes multisig a worthwhile step in some processes but it falls short of fully representing the legal requirements most businesses need to operate under. Specifically multisig may work for bearer assets in some cases but does not work for ownership records.
In reality, most assets are not bearer instruments. Ownership records are kept and controlled by regulated entities recognised by law. Ownership kept on that regulated ledger is legally enforceable, and restrictions to ownership and transfers often apply. Assets derive their value from the legally enforceable set of rights they bestow upon their owner.
Real estate is a good example of an asset and a bad use-case for tokens.
Real estate is not a bearer instrument. If I lose the key to my house, I don’t lose ownership. Similarly, if I turned up to someone else’s property and demanded forfeiture while waving a paper land title, I would likely be arrested for forgery or theft.
Real estate ownership is controlled by land registries and only the land registry’s ledger is legally enforceable. In many places, there are restrictions on who may own real estate and to what degree it is fungible and transferable.
So if I lost the private key to my real estate token, I would similarly not lose ownership of my house. It seems inconceivable that a judge would evict a local homeowner in favor of a pseudo-anonymous, foreign token holder. It would be especially dubious if that token holder gained control through means outside the court’s jurisdiction (nefarious or otherwise). This begs the question - if your goal is to ‘maximally decentralize’ this type of asset, what protections did your token holder receive for the cost of implementation complexity?
The purpose of buying a plot isn’t to get an entry in the land registry, nor does land ownership bestow full control of a cone from the centre of the earth into outer space. It gives the owner a very specific set of rights: the right to build a house, the right to keep strangers off the land, the right to split the land and sell a part on. The former two of which no token will ever do for you.
Indeed, for many other types of “ownership”, like securities or media, the term is used to convey an idea of a set of rights, which are actually traded individually: lease-holds or mineral rights on land, or dividends or voting rights on securities. In some areas, this is so intricate that “ownership” has become a virtually meaningless term. Digital Rights Management is one such area and shows what “ownership” of digital assets is really all about: Rights.
To reap the benefits of open or shared records, we can’t just record ownership as opaque Tokens. Instead, we must represent the rights that make up ownership in our digital systems, be they centralized or decentralized. This is where smart contracts come in. They aim to encode the specific rights that ownership of an asset grants to the owner, and encode the rules and processes around those rights.
The rules set forth by smart contracts do not replace law and regulation. Indeed, real world law, regulation, and contracts are often open to interpretation. Their practical meaning is determined by practice and legal test cases.
Having actions take place with absolute inevitability and rules enforced by a disinterested network of nodes does not reflect the subtlety of the real world. Such rigidity also leads to enormous risk as unintended flaws in contracts are set in stone. This isn’t hypothetical risk, either. The famous DAO exploit was caused by a subtle bug in a smart contract and could only be fixed by a majority of all Ethereum users updating their nodes to agree to fork the blockchain [2] and create an alternative reality.
Such rigidity is not desirable for most business use-cases. Instead, most smart contracts must be a reflection or encoding of the contracts, laws, and regulations governing the real world. Parties bound by a contract must be able to change, supersede, or tear it up by mutual agreement, just like they would with a real contract. The rules of a contract must be enforced by parties with a stake and interest in the contract, with clear avenues for dispute resolution. While those outside the contract should have no say in it.
Asset issuers and investors have distinct privacy requirements. Investors would like their holdings and transactions to be kept secret as far as possible. Issuers have to know who holds their assets and are responsible for keeping personal information safe.
Most blockchains systems are entirely public and fully replicated between all participants. The main privacy safeguard on most chains is the use of pseudonymous addresses to create a relatively weak form of anonymization.
For investors, pseudonymity is often an ineffective form of privacy and requires a great deal of care. Since all users can see all transactions, it is possible to infer a lot [3]. The risk of confidentiality being broken and information about trades and transactions becoming public is unacceptable for many businesses.
For issuers, anonymity makes it impossible to fulfill their legal requirements on KYC, anti money laundering, or data protection. Indeed, it is not entirely clear whether such systems can comply with data-protection regulation like GDPR, which governs many types of records that could well be kept on distributed ledgers [4].
In other words, the (lack of) privacy afforded by most current platforms is inappropriate for all parties and asset types other than cryptocurrencies which make this tradeoff for the sake of other network properties. But even there, privacy is desired by many, yet hard to achieve.
Like record keeping, trust around ownership has evolved greatly throughout history. Taking banking as an example, it all started very simply. The trust relationship was fully centralized, with a client having to trust their bank entirely. Banking clients were fully exposed to their bank burning down, being robbed, or embezzling assets. Such a single point of failure is easy to understand, but highly risky.
Such risk is harmful to business and consumers alike, so today’s financial system has developed into a complex system of laws, regulations, and institutions that try to safeguard our assets. The perceived safety provided by the system is what helps our markets work smoothly and efficiently, benefiting society as a whole. However, they add complexity and opacity to a degree where many people no longer fully understand who they implicitly or explicitly trust. Some learnt this the hard way during the 2008/2009 financial crisis.
Public blockchain’s innovation here is to simplify by going to the opposite end of the trust spectrum. Trust is now transferred to a democratic majority - the 51%. It’s beautifully effective for applications like cryptocurrencies, where all rights concern only the record itself. A cryptocurrency user can have a coin record in their name, and they can transfer it.
Most rights are not like that. The right to build a house on a piece of land does not concern the record of that right. A real world party is needed to guarantee and enforce that right. Typically the guarantors of rights are the same institutions that are entrusted with the record keeping for those rights. Democratizing the record keeping for such records achieves little, which is why there are few truly decentralized applications other than cryptocurrencies.
Smart contracts do not replace trust, they make it explicit and transparent. A good system encodes the trust assumptions between all participants of a contract in such a way that all parties understand their rights, obligations, and exposures. There must be a clear understanding of who is ultimately responsible for maintaining the link between the ledger and the real world.
Developing distributed applications is largely akin to developing mainframe applications several decades ago. There is little abstraction between the surface language and the system internals. Applications are built for one infrastructure and tied to it forever.
Yet Gartner predicts that 90% of today’s platforms will need replacing by 2021 [5]. How could any serious business invest significant money to replace a critical system in the knowledge that they will be locked into a technology and an infrastructure vendor that may be superseded in two years?
The ledgers we use need to catch up with traditional application development stacks, which offer clean abstractions between different layers. Only by making applications portable between ledger infrastructures can they be future-proofed and development de-risked to a degree where it becomes viable for wide-spread adoption.
Daml is Digital Asset’s answer to all of these issues. It is a high-level smart contract language designed to bring unprecedented productivity to the development of distributed applications for enterprise and beyond.
Daml has a rich data definition language to describe records, as well as the rights parties have according to these records. For example, the below representation of ownership of a piece of land gives the owner the right to request sub-division of the plot.
The above contract is between a land owner and their commune. Should the contract be erroneous, those parties should be able to amend it. Daml has a clean concept of data control through signatories. Owner and commune can jointly make changes to an ownership record.
Using this add-on contract, the commune and land owner may decide to correct a record by mutual agreement, in a completely compositional fashion. “Upgrading” or “correcting” of contracts does not need to be planned for. A clear concept of data ownership makes it work out of the box. This is in stark contrast to public blockchains, which should contain permissionless smart contracts specifically designed to be minimally, and ideally not at all modifiable.
The Daml Ledger model specifies precisely who has the right to see data and follows a small set of principles to derive visibility rules:
These rules maximize privacy while ensuring that any party ends up with a fully valid view of the ledger, and everyone is guaranteed to be informed of the state of contracts in which they hold a stake.
The Daml Quickstart guide gives a powerful example of subtransaction privacy using a simple trade model. In Daml it is possible to atomically swap assets guaranteed by two institutions without either institution learning anything more than that the asset they back has been transferred.
The right to trigger the land subdivision process shown above cannot be enforced on-ledger. The commune or higher authorities have to be trusted that they will honor the on-ledger agreement and perform their roles in the process to decide whether the request is accepted or rejected.
Daml makes this very explicit. No party can ever become a signatory on a contract without their consent. Having the commune as a signatory on LandRecord means they may be an obligable party under the rights encoded in the contract, and have agreed to the terms. The signatories of a contract are those that have to be trusted to uphold the rights described and maintain the on- off-ledger link.
Daml and its API are to distributed applications as SQL and ODBC are to centralized ones. The clean interface between data and logic specification, the underlying storage infrastructure, and the client application consuming the data makes applications portable without re-engineering.
This abstraction makes Daml easier to learn and faster to develop than other smart contract languages and tech stacks. The developer need not concern themselves with the detailed mechanics of the infrastructure they are planning to deploy to and system-level concerns are kept out of the language completely. By learning one language and one API, app developers become able to develop applications for local deployment, clouds, and distributed ledgers.
It also de-risks and accelerates the development of distributed applications. Applications can be developed without worrying about which infrastructure is the right one to pick, both for current and future needs. They can be developed and prototyped on entirely different infrastructure than the production deployment. Daml supports a wide range of infrastructures, from local database-backed solutions, to cloud-hosted ledgers, and all the way to fully public blockchains true to the Daml Ledger Model.
[1] https://de.wikipedia.org/wiki/Grundbuch#/media/Datei:BadFredeburg-Gerichtsmuseum4-Asio.JPG
[2] https://en.wikipedia.org/wiki/The_DAO_(organization)
[3] https://cryptolux.org/images/d/d9/Zcash.pdf
[4] http://www.europarl.europa.eu/RegData/etudes/STUD/2019/634445/EPRS_STU(2019)634445_EN.pdf
