The Grand Myopia
Finance and the broader idea of commerce is ultimately a human endeavor. There exist elegant languages, extremely precise tools to capture intent, and endless mazes of techniques to achieve recourse in the event of bad outcomes as well as thousands of years of laws seeking equity in trade. In fact some of the earliest forms of writing were commercial contracts.
Yet the human element cannot be eschewed regardless of the disintermediation to logic, machines or governmental sentinels entrusted with terrible powers. Therein lies the grand myopia of cryptocurrencies. They are mostly divorced from human reality.
People make mistakes. People change their minds. People do not always fully understand the business relationships they are agreeing to enter. People get misled and defrauded. Circumstances change on an individual and state level that require unique solutions. Belaboring this point, most contracts contain force majeure clauses.
However, cryptocurrencies seek to toss out human understanding, compassion and judgement in exchange for an uncaring digital judge perfectly bound to a constitution without consideration to fairness or outcome. Given that humans have always tried and will continue to attempt to change rules to selfish ends, it is refreshing to actually have a system that cannot be corrupted.
But what happens when a user needs to blend these new systems with traditional financial systems? What happens when one needs to live in the human world? For example, property rights such as land registration live entirely in the physical world. Even tokenizing the land still requires some acknowledgement of the incumbent jurisdiction.
To provide another point, a bar of gold cannot move itself. The digital judge can command its movement, but cannot force it without humans to accommodate. Hence a digital ledger can drift from reality.
Thus a protocol designer needs to decide how much human reality should be permitted in his cryptocurrency. The more flexibility, the less fidelity to the absolute one should expect. The more consumer protection, the more mechanisms have to exist to provide rollbacks, refunds and editing of history.
This section and the next on regulation covers Cardano’s pragmatic approach to the topic. In terms of interoperability, there are two broad groups to discuss. First, interoperability with legacy financial systems (the non-cryptocurrency world). Second, interoperability with other cryptocurrencies.
Fintech is not composed of a single standard or even a common language. There is tremendous diversity in approaches, the entities responsible for settlement and clearing, business processes, and other domains involved in the accounting, transformation and movement of value.
It is unreasonable to suggest that, simply because one technology is superior, the rest of the ecosystem will somehow admit defeat and upgrade. For example, many people still use Windows XP 16 years after the initial release. This sad state of affairs is equivalent to someone using the original Macintosh released in 1984 in the year 2000.
Consumer behavior aside, businesses are generally even slower in their upgrade cycle. Many banks still use back ends written in Cobol. Once infrastructure is known to work and meets business requirements, there is usually little incentive to upgrade or refine software and protocols for a consumer’s benefit outside of compliance or security concerns.
For Cardano, we first have to establish what would a legacy bridge even entail? What systems, standards, entities and protocols should we target to ensure there is a reasonable certainty of interoperability? Can these bridges be federated or decentralized? Or like exchanges will they become central points of failure for hackers, malicious owners or overzealous regulators?
There are three concerns that have to be addressed. First, the representation of information and belief in its accuracy. Second, representation of value and its associated ownership. Third, representation of entities and, a particular user’s alongside the aggregate level of trust in such entities.
To be useful, information and value need to freely flow between the legacy financial world and Cardano. Then outcomes need to be established and recorded to build reputation and grounds for recourse. Yet such things are mostly scoped in nature to the actors involved. To encode them on a blockchain would make them global and permanent.
Furthermore, value cannot always freely flow in the legacy world. Embargos, sanctions, capital controls and judicial action could freeze assets. To be interoperable, one cannot create an always open escape valve for value to leak.
Finally, the brand and reputation of entities is one of the cornerstones of commercial relationships. Billions of dollars are spent yearly on marketing campaigns to establish, maintain and repair brands. If libelous, false or misleading claims are made about a person or entity, then they have the right to seek legal recourse. Yet blockchains attempt to permanently preserve history.
Like our choice of programming language, there is no ideal solution for Cardano to resolve these concerns in a ubiquitously correct way. Rather, we have to yield to supported opinion again.
With respect to the flow of information, this flow is known as a trusted data feed. It has a source and content. Sources have some notion of credibility and incentive to deceive or maintain honesty. Content can be arbitrarily encoded.
Given that we intend on supporting trusted hardware in our protocol stack, we have chosen to explore adding support for Professor Ari Juel et al.’s Town Crier Protocol. Assuming the existence of a credible set of data sources, Town Crier permits the secure scraping of web content for use in smart contracts and other applications.
A bootstrap list of sources will be provided by Emurgo, IOHK and the Cardano Foundation. Later this list will be replaced by a community curated list using mechanics derived from Cardano’s treasury system. Our hope is that a reputation system can materialize around good data feeds, thereby creating a positive feedback loop to gradually improve reliability and fidelity.
The representation of value is a more complex topic. Unlike information — where once the veracity, timeliness and completeness are established, protocols can behave in a reliable and deterministic way — value is more delicate.
Once tokenized, value should behave like a unique object. Information can be copied and passed around, but a token representing ownership of something (say a vehicle title) cannot be cloned and traded on two different ledgers. This act would effectively destroy the integrity of the system.
The challenge in legacy interoperability when dealing with tokenized value is that trust assumptions, reliability and auditability change as tokens flow between ledgers. For example, if Bob owns some Bitcoin and then deposits them on an exchange, then Bob now has the exchange’s representation of his Bitcoin on their ledger. In the case of MtGOX, their ledger did not conform to reality, causing the users to lose everything.
The problem is further complicated by the need for legacy systems to recognize tokens living in a cryptocurrency. As mentioned previously, businesses are historically resistant to upgrading their software and supporting new protocols. This situation makes it difficult to see a clear solution.
For Cardano, our best hope is to provide an option for users to attach a rich supply of metadata to their transactions and then wait for industry standards to emerge to hook into. Some progress has been made with the Interledger workgroup, efforts like R3Cev and international mandates to upgrade old financial protocols.
However, the larger challenge remains of quantifying and qualifying value sent from a legacy system to a cryptocurrency ledger. For example if Bob is a bank owner and issues a dollar backed token, then he can always build a bridge to send his tokens to a ledger like Cardano as a user issued asset.
While Cardano would track ownership precisely and provide all the features we have come to love such as timestamping and auditability, no cryptocurrency can make Bob an honest banker. He always has the option of running a fractional reserve bank by not backing all of his dollar tokens with real dollars. This fraud cannot be detected by a cryptocurrency unless the dollar itself was a token accounted by a digital ledger25.
Finally, the representation of entities online is a classical network problem dating back to early days of the internet. Universities, businesses, government departments and any arbitrary users need to establish their identity at some point.
To this end, pragmatic yet centralized solutions like the web’s Public Key Infrastructure and ICANN’s DNS system have been implemented. Given that we enjoy the modern web, these solutions are both scalable and practical. But they do not answer a more commercially oriented question of reliability, trustworthiness and other meta characteristics necessary for determining if one wants to do business with the entity.
Multi-sided marketplace hosts like eBay have constructed a business model on providing some of this metadata alongside a framework to complete transactions. Judgements about the quality of content, events and businesses are often deeply influenced solely by online ratings from trusted sources26.
The part of this point relevant to Cardano is a question of centralization of reputation. One of our goals for Cardano is to provide a financial stack for the developing world. A key to this effort is the ability to establish trust with actors one has never met.
If a single entity or a consortium of entities control who is labeled good or bad, not an organic process derived from actual interactions in the community as a whole, then these entities could arbitrarily blacklist anyone for any perceived sin. This power is against our values as a project and defeats the broader point of using a cryptocurrency.
Fortunately, the same mechanisms used in voting for treasury ballots, adding sources to a list of trusted data feeds and forking a protocol can be reused to establish a reputation space. It is an open area of research and our hope is to provide an overlay protocol for a decentralized reputation web of trust in 2018-2019 after more foundational elements have been settled.
Moving from the legacy world to distributed digital ledgers, interoperability becomes far simpler. Each ledger has a network protocol, standards of communication and security assumptions about its respective consensus algorithm. These in turn can be easily quantified.
Movement of information is established by connecting to the foreign network and translating its messages. Movement of value can be done through a relay system, atomic cross chain trading or through a clever sidechains scheme. As there is not a centralized operator, one representation of entities restricts more to a metadiscussion of trust in developers, miners or some other powerbroker.
For Cardano, we are integrating a new sidechain protocol developed by Kiayias, Miller and Zindros. It provides a non-interactive way of safely moving value between two chains that support the protocol. This mechanism will be the primary way value will flow between CSL and a CCL layer.
For other cryptocurrencies, federated bridges should form as Cardano grows in value and user base. To help accelerate this growth, Cardano SL supports a restricted version of Plutus for interoperability scripts. New transactions will be added in the Shelley and later releases of CSL specifically to address these needs.
The Maze of Daedalus
The points on interoperability come from a global perspective. Specialized protocols, new transaction types, systems to assess credibility and the flow of information cannot be scoped to just a single gatekeeper or user. Rather they must be readily available to anyone without censorship or tolls.
Yet what happens when Cardano does not support a protocol, transaction or application that a user cannot live without? Should we just be out of scope? The web faced a similar concern during the 1990s.
Ethereum adopted the former approach by allowing users to embed subprotocols on the Ethereum blockchain as smart contracts. Cardano supports this feature through the CCL paradigm. But what about custom extensions?
An elucidating example would be a cryptocurrency trader. Imagine a decentralized marketplace, called DM, that supports a set of different cryptocurrencies. A trader wants to automate his strategies acting on DM.
In a fragmented ecosystem, the trader would have to install dozens of clients for each cryptocurrency and then write custom software to talk to each client in order to coordinate automated trades. If one client updates, then it could break the bespoke software. Furthermore, what if the trader wants to sell the software?
Inspired from the web model of extensions, if the interface to various cryptocurrencies can be pulled into a web stack, then the trader’s task becomes dramatically easier. A universal interface can be established. Installation is one click. Distribution of software can be modeled after the Chrome web store.
For Cardano, we have decided to experiment with this paradigm by deploying our reference wallet’s front end on Electron. It is an open source project maintained by Github that combines both Node and Chrome together. Cardano’s build of Electron is called Daedalus.
The first generation of Daedalus27 will act as an HD wallet with support for many of the expected accounting and security features that are industry standards, such as spending passwords and BIP39. In later generations Daedalus will develop into an application framework with a store, universal integration APIs and an SDK.
As Daedalus is intended to be a universal framework, its roadmap and evolution is somewhat independent of Cardano’s. During 2017 they are tightly coupled, but later Cardano will be just another application for a Daedalus user. We also intend on exploring extremely unique features such as a universal key management service running solely in Intel SGX.
Ultimately, as protocol designers, we cannot support all needs. Our hope is that the flexibility that Daedalus will provide combined with stateful smart contracts running on CCL will satisfy those left out by our design decisions. We also hope that better standards can emerge to encourage all cryptocurrencies to enjoy better interoperability and security.