“What if … you had a portable, secure, globally available store of personal data in a blockchain? You could have all of your health records or driving history available instantly to hand on to trusted third parties. You might hand over your health record to a new doctor or to obtain a life insurance quote, or your driving history at an airport counter for a car rental insurance discount. Your personal data store might also have your biometric data, thus giving you the ability to prove at any time it is you before someone, and that data contained in the blockchain is yours.“
— Michael Mainelli and Chiara von Gunten, “Chain Of A Lifetime: How Blockchain Technology Might Transform Personal Insurance“, Long Finance (December 2014), 51 pages.
Mutual distributed ledgers could transform the way people manage identities and personal information. Individuals could own their data and no longer need to trust third parties to store or manage their information. Mutual distributed ledger identity schemes could empower people with personal data storage and management, permission frameworks for access by third parties such as banks or insurance companies, and even distributed reputation ratings. Such applications could reduce identity and fraud, increase confidence in products, and lower rates thus increasing coverage. The concept of never losing data could materially alter the way society views identity, privacy, and security.
Identity is fundamental to money. The entry in any ledger is about people – A owes B. Thus, tokens of identity are the basis of currency. Søren Kierkegaard, “doubt everything”, reminds us that without risk there is no faith; there can be no faith without doubt. There can be no faith in the community without debt, thus credit and a form of doubt about future repayment are intrinsic to monetary systems.
Identity is not just physical, a DNA or retinal match. Identity is not just about ownership of bank accounts or assets. Our identities are the ‘chains of our lifetime’, binding us past and future with the now. For example, school grades, a driving record, tax payments, are all part of a chain of behaviour entangled with a particular human body. Our identities encompass our relationships with other people and institutions. Our identities vary depending on who is identifying. The tax office probably has little interest in people’s driving records, but may care enormously about the days they spent out of the country.
Corporate identity is even more complex. The transaction ‘log’ of a company could have constant entries –
directors joining and leaving, any employee joining or leaving, purchase orders, invoices, payments, approved persons, inspections, annual reports, audit results, even continuous posting of sales and purchase ledgers, etc. If the transactions are authoritative enough, possibly co-stamped by corporate identity validators (e.g. the DueDil use case in InterChainZ), then perhaps dynamic credit or lending application might arise.
Mutual distributed ledger technology and related applications could transform the way we manage digital identity (ID), personal information and history. An ID scheme relying on a decentralised mutual distributed ledger combining a public ledger of records with an adequate level of privacy could rival state-backed identity systems. A number of digital ID schemes are emerging, including OpenID Connect, a protocol combining an identity layer and an authorisation server, which allows clients of all types (e.g. developers) to request and receive information about authenticated session and end-users across websites and apps without having to own or manage password files. Governments too are trying to set up digital ID systems and authentication processes. The UK for example unveiled Gov.UK Verify in September 2014, a proposed public services identity assurance programme which might use a network of trusted and vetted third party providers instead of relying on a centralised database. Estonia has been operating a national digital ID scheme for a decade and is extending application to foreign non-residents, which would in effect separate state-backed ID from location. Estonia claims that much of its architecture is comparable to the mutual distributed ledger approach.
The Peruvian economist, Hernando de Soto, points to the importance of widespread economic participation for prosperity and stability, and argues that inclusion starts with participation in an information framework that records ownership of property and other economic information. Once there is strong identity, then there is much stronger lending. The developing world is already a place to look for identity innovation. One such example emerges from Unique Identification Authority of India which everyone in the identity world is watching as probably the largest identity project ever.
Creating a trusted and widespread digital ID system could be technically rather straightforward but socially difficult. Public Key Infrastructure (PKI) and digital certificates were all the rage in the 1990s. Many issues, not least commercial confusion, impeded public understanding. While PKI and digital certificates are functional, widespread use has evaded them, though they have niche applications, often in financial services. Social media networks are trying to make their accounts a form of ID though these generally fail to meet basic trust requirements as most are issued without verification.
It is probably not too much to assert that establishing an efficient identity system is the core global development challenge for MDLs. For the developing world, identity is fundamental to getting onto the ledger in the first place. For the developed world, efficient identity systems are fundamental to efficient financial and trading systems.
The persistence and pervasiveness of distributed ledgers make them ideal for providing a lifetime record. There is a swarm of trial applications being discussed, putting assets onto mutual distributed ledgers - land & property, vehicles, ships, satellites, business ownership/incorporation/dissolution records, regulatory records, tax returns, building and other types of permits, court records, government/listed companies/civil society accounts and annual reports, etc. A swarm of other applications are putting data onto mutual distributed ledgers - contracts, passports and IDs, birth or death certificates, signatures, criminal records, high school/university degrees, professional qualifications, certifications, human resources records, medical records, accounting records, business transaction records, locational data, delivery records, health and safety inspections, genome and DNA, genealogy trees, etc.
An MDL identity scheme could take the form of an application hosted using identity validators (i.e. pre-determined experts authenticating documents or information submitted) and identity brokers allowed to cross-reference information securely with other data sources (including governmental ones). The application could enable additional functions including personal data storage, authorised access frameworks for external providers or even reputation ratings. Combining authentication and personal data management functionalities with secure mutual distributed ledgers could lead to new frameworks for identity management. If successful, such identity schemes could remove government monopolies in managing their citizens’ identities and data.
At a time where access and control over one’s own data is becoming increasingly sensitive, empowering individuals to store, update and manage access to their data seems rather appealing. In InterChainZ, the identity validator is a ‘co-stamper’ of data onto a personal or corporate ‘MDL’. The owner of the MDL can include what they like, but if they wish to get other people to accept the data’s validity, it needs co-stamping. An identity validator might be a government, an accounting firm, or a credit referencing agency.
A simple example might be that an accountancy firm needs to co-stamp the inclusion of an annual report on a corporate identity MDL before other parties would normally accept it. Another example might be that people go to an identity validator to encode biometrics, e.g. DNA, retinal scan, photo, facial scan, finger vein identification, thus time-stamping physical identity. Validators have no further access to the data. However, ‘the validated’ can share the key to their identity MDL with other people and organizations. Others rely upon the fact that the data has been co-stamped by a trusted third party.
Anecdote – Sharing Ledgers. In 2014 the InterChainZ team made a suggestion that MDLs might be suited to helping the sharing economy. The hypothetical situation was someone providing shared driver services in a sharing economy firm such as Uber or Lyft. In the event of an accident, their domestic motor insurance cover would be invalid. Since 2014, there has been some activity in this space with some sharing economy firms now providing cover, and new policies for sharing economies. Several of those active in this space discussed their issues with the InterChainZ project.
An MDL might be a useful way to reduce inefficiency here. If drivers record when their ‘virtual taxi meter’ is on (indicated by accepting a ride till the time of invoicing) to an MDL, co-stamped by the sharing economy firms they’re using, then both domestic and sharing economy insurers can be clear which policy applies when. For the sharing economy firm, this is perhaps simpler than answering information requests. For the insured and the insurer, having the data in a shared public area reduces the risk of not having accurate data in the event that the sharing economy firm ceases trading or starts charging excessively for data provision.In addition, the claims and payment processes should be simpler.
InterChainZ provided only a single level categorization, “Entry Type”, e.g. company accounts or health data. A robust system would need a much richer taxonomy, ideally one that could evolve. For an individual this could be many-layered, e.g.:
The complexity is obvious if MDLs are going to be used at the individual and corporate level for widespread use.
MDLs raise an interesting prospect that data may not be ‘owned’ in future. Data might be pervasive, persistent and permanent, yet inaccessible to most, or with the loss of a key inaccessible forever. An identity MDL might have a firm ‘co-stamping’ identity information, yet not having any record or future access. This has attractions for some applications and confidence that data is only accessible by the owner could be important. However, at the same time an MDL runs over traditional concepts of data ownership, such as where is the data. A strict answer to “who is taking care of my data?” on an MDL is difficult. To be fair, many Cloud applications have the same problem. An MDL could both help or hinder new Data Protection requirements such as a “right to be forgotten”. Current EU regulations might make it difficult to structure MDLs in such a way that the data is not stored outside the EU, though it may not be accessible outside the EU unless an EU individual provides their key.
Two inexorable trends increase the tensions in identity, globalisation and population. In a globalised world approaching ten billion people, transactional affordability is crucial to success. A few high-net-worth individuals may justify implementing a complex and costly identity scheme, but the promoters of expensive schemes would be pushing billions of potential customers to the side.
The increase in connectivity – seven billion phones for seven billion people, and internet-of-things devices estimated by Cisco to hit fifty billion by 2020 – will increase the number of transactions several-fold. Further, global population estimates for 2050 circle around the 10 billion mark. The identity problem increase several-fold. Visa and MasterCard already process ten transactions globally per person per annum, and they are just one type of international provider. If global payments over the decade come to resemble the USA today, with several hundred million online payments per day, we are well onto ‘tera-transactions-per-day’ measures in the next decade.
Transactional affordability will drive a ‘many uses’ approach to get the most out of an expensive process. Both high-new-worth customers and low-net-worth customers expect global identity, whether it’s credit card authorisation, payments, or health records. Their demands will get stronger as they realise what can be achieved, rather than what has historically been put upon them. They will exclude service providers with onerous identity rituals such as KYC/AML. ‘Many uses’ will in turn drive consolidation towards a few, competitive, global systems.
“IBM has unveiled its proof of concept for ADEPT, a system developed in partnership with Samsung that uses elements of bitcoin’s underlying design to build a distributed network of devices – a decentralized Internet of Things.
The ADEPT concept, or Autonomous Decentralized Peer-to-Peer Telemetry, taps blockchains to provide the backbone of the system, utilizing a mix of proof-of-work and proof-of-stake to secure transactions.
IBM and Samsung chose three protocols – BitTorrent (file sharing), Ethereum (smart contracts) and TeleHash (peer-to-peer messaging) – to underpin the ADEPT concept. ADEPT was formally unveiled at CES 2015 in Las Vegas.”
Stan Higgins, “IBM Reveals Proof of Concept for Blockchain-Powered Internet of Things”, CoinDesk (17 January 2015)
Autonomous machinery will create enormous markets humans never see. To ensure appropriate management, including liability management, MDLs might be a core technology.
Anecdote – Machine Chatter. Leaving aside some interesting by-waters such as a discussion of a Technological Singularity or Techno-Rapture, i.e. when artificial intelligence permits the machines to take charge, an interesting anecdote came up during InterChainZ. There was a discussion with a US insurer about how to insure emerging electricity company products. This insurer had been approached by US energy companies about some of their new services, in particular services that might offer lower electricity charges if consumers allowed the energy company to switch appliances off and on when needed for load reduction or load balancing. In the US, one large area for claims are the loss of freezer contents. The insurer realised that it could share data with the energy company such that, assuming two identical freezer units with different content values, a lower content value freezer would be turned off in preference to a high content value freezer.
Further, the insurer realised that someone coming home to a melted freezer might have three options:
In each case the complexity of proving the chain of commands to the freezer almost mandates an external, ‘unowned’ MDL as a reliable source of records to make claims efficient and remove fraud.
At a conference in Germany in 1997 Eric Steven Raymond described the struggle between top-down and bottom-up software design, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. He contrasted “happy networked hordes of programmer/anarchists [the bazaar] outcompeting and overwhelming the hierarchical world of conventional closed software [the cathedral]”.
So what does the future hold for ledgers? It might be the Temple of Financial Services against the Souk of the Sharing Economies. In the Temple the high priests of the Blockchain Maximalists and the Banking Traditionalists wage a schismatic war over ‘the One True Coin’. The Banking Traditionalists believe that these mutual distributed ledger fads too soon shall pass, leaving traditional banking intact. The Blockchain Maximalists, and adherents to some of the other blockchain services, believe that everything in financial services can be replaced. Each believes that only one ledger can prevail, or from the film Highlander, “there can be only one!”
Out in the Souk of Sharing Economies there is an explosion of vibrant stalls and frenzied groups of small shopkeepers engage in animated discussions with clients about a myriad of ways of trading. Shopkeepers and clients are prototyping, experimenting, and finally deploying hundreds to thousands of different distributed ledgers. These ledgers are often in the corners of wholesale finance, insurance linked securities, OTC trading, registries, or small exchanges. These small communities typically use private, permissioned, identity-authorised ledgers. Meanwhile, governments try to make taxing the church or the market less slippery, with some governments, such as the Channel Islands, exploring how to evaluate sensibly the hundreds of ledgers that may be brought to them for regulation.
While underdog supporters may root for the Souk of Sharing Economies, that there may be room for both. A sensible union would be a few, competing, ‘blockchain-type’ services encircling the globe providing end-of-day validation and recording of transactions, while thousands of mutual distributed ledgers do the busy work of serving thousands of shared economies. In order to provide additional trust, the Souks publish a hash of their MDL for additional proof of non-tampering, perhaps storing a daily or hourly hash in Bitcoin’s blockchain, Ethereum or another high-trust, permissionless, token-earned MDL. In effect, the merchants of the Souk bring their ledgers up to the Temple to be validated and timestamped by whichever priests occupy the Temple of Financial Services. It may not be orthodoxy, but it’s not heresy either.
In many ways, it is appropriate that InterChainZ is a Long Finance project. Long Finance asks, “when would we know our financial system is working?” The pervasive, persistent, and permanent nature of MDLs means trying to design data structures that might have to last centuries. There is a parallel from 1999.
The Y2K problem (or millennium bug) began in the 60’s, 70’s and early 80’s (sic - two digits) when computer programmers were chronically short of memory, disk space and processor speed. The differences between that period and today were large. The authors began programming in the mid-70’s with a luxurious 4 kilobytes of memory on isolated laboratory mini-computers and are writing this article with gigabytes on networked PCs at home. Programmers were told that systems were being built for a finite period of time and therefore used a common trick of only recording two digits for an annual date which saved significant space on large files. Computations on those files depended on two digits being interpreted as “1900+ two digits” and often resorted to further efficiency tricks such as using 98 or 99 as special triggers or adding extra months and days that don’t exist. For instance, 98 might mean end of record and 99 end of file. Clearly, problems arose when the real 1998 or 1999 comes along. The Y2K problem had an extra zing that 2000 was a leap year and that many programmers mistakenly thought it wasn’t (leap year in every year divisible by four, except when divisible by 100 UNLESS divisible by 400).
A natural human response in such situations is to ask how this could possibly come about and who’s at fault before getting on to what can be done about it. A first port of call is the programmers, clearly they built the systems using shortcuts which would not stand the test of time and now they have the audacity to charge for fixing it. However, these systems were almost always built for a finite period of time. In the 70’s this time period could be as short as two or three years or possibly as long as five or seven before “we buy a software package”, “we move to a fully-relational database”, or “we upgrade all our systems”. A next port of call is the accountants who left these systems off the books when they were key business assets or failed to fund the asset maintenance costs which should have existed. However, accountants had, and have, great trouble getting sensible lifetimes and valuations for computer-based systems. In the event, and at some expense, these systems were successfully upgraded, but the lesson is that discounting the future too rapidly led to modest medium-term gains and long-term costs.
Virtual realist Jaron Lanier applies the idea of “karmic vertigo” to computer code: “The computer code we are offhandedly writing today could become the deeply embedded standards for centuries to come. Any programmer or system designer who takes that realization on and feels the full karmic burden, gets vertigo.” Stewart Brand provides some perspective: “The karmic view of the future can be as distorting as the discounted view. Instead of the reduced responsibility of discounting, karma can impose crushing responsibility, paralyzing to contemplate.” [Stewart Brand, The Clock of the Long Now: Time and Responsibility, Basic Books (1999), page 120]
MDLs create a big tension – how to build 100 year pervasive, persistent and permanent data structures and protocols that can evolve. Similar problems have arisen with Hyper-Text-Transfer-Protocol (http), with ICANN, and with Bitcoin itself, which in a ‘sign of the tines’ is fighting an internal battle to change its protocol to handle a wider range of transactions more swiftly. This short-long, need-for-evolution tension is a big point in favour of semi-centralised solutions such as permissioned ledgers. With a trusted third party and a governance structure there is some ability to assure the permanence of records, while also being able to update and change entities.
MDLs are sorcerers’ apprentices. Once they have been set off they are hard to rein back or change. For this reason, most people involved with InterChainZ believe that dumb contracts will be the most complicated thing done for some time. While smart contracts are certainly possible, they are not probable, principally because people are unlikely to believe that such contracts can always be safely executed at some point in the future. Interestingly, a full smart contract MDL is ‘Turing-complete’, i.e. can solve any computing problem, or very close to Turing-complete. A Turing-complete MDL could be a giant petri dish to every form computer virus or malware. Proving that a Turing-complete MDL is designed to achieve only its specified objectives is non-trivial. Thus dumb likely precedes smart by some years.
Bitcoin and Ethereum’s ability to function in environments of low, zero, or even negative trust, attract attention, even envy. However, overcoming the lack of trust in those environments has a high technical performance penalty. If a ‘circle of trust’ can be established, then transactions within such an environment have a performance advantage. This line of thinking has long been economically interesting (Coase and his followers). The following diagram attempts to place various types of technical approaches on a scale ranging from ‘no trust’ to a single, central trusted third party.
Concepts of trust arise in many philosophical puzzles that range from Epimenides the Cretan’s paradox of “all Cretans are liars” through to Kurt Gödel’s Incompleteness Theorem. A paraphrase of Gödel’s Incompleteness Theorem applied to trust might read, “We can never find an all-encompassing axiomatic system of trust, without recourse to systems outside it.” It seems appropriate to conclude this report on MDLs with Long Finance’s Zen koan – “If you have some trust, I shall give you trust. If you have no trust, I shall take it away.”