The following two tabs change content below.
James Carlyle is the Chief Engineer of R3, and is focused on defining and building Corda. Previously, James was Chief Engineer within Corporate Banking at Barclays, where he designed and delivered the bank’s US banking and Dollar clearing platforms and Corporate internet channel. Before Barclays, James co-founded 2 startups and holds patents in mobile data search and directory technology. He is a Chartered Engineer, holds a degree in Engineering Science from University College, Durham, and is a fluent Japanese speaker from his earlier career in industrial engineering in Japan.
I’ve been working at R3 for a year, and the full significance of distributed ledgers and smart contracts has taken a while to dawn on me.
I joined R3 with a notion that a global unstoppable and incorruptible computer, which self-executed the transfer of value between participants, would be a wonderful thing. This was based on almost a year of writing Ethereum contracts from the very earliest days, when the developer experience consisted of sitting in a very small room for a day with the ever-patient Ken Kappler, some other visionaries and conspiracy theorists, and creating a simple registry contract in Serpent.
What’s changed for me is an understanding of why businesses need distributed ledgers. Businesses survive by dealing and trading with each other; and often, even when collaborating in a supply chain, they have different economic interests. They also have no universal system of record in which they manage their deals and agreements with each other.
The fundamental promise of distributed ledger systems is captured in a phrase coined by Richard Brown, prolific blogger and a colleague at R3. That phrase is “I know that what I see is what you see”. Unfortunately, in today’s world, we can’t take this for granted. To illustrate this, take a look at the world through the eyes of a person with colour-blindness. The same image is shown below in a way that people with normal vision see it, and duplicated in a way that people with one form of colour blindness see it. The difference is due to the way that the eye cone cells process information, and possibly the pathway from the eyes to the brain. But since we only ever have one experience, we fail to recognise that others see it differently.
The same applies in business. To illustrate this: My wife runs a small consulting business, and upon delivering work to a client, goes through a process of logging billable time, raising an invoice, applying credits using well known rules; printing the invoice and then sending it. On the client’s side, they receive the invoice, key it into their accounting package, apply credits (hopefully using the same rules), recognise an amount payable and then authorise payment of it. Unfortunately this type of repeated-unilateral processing results in differences of perception, as each step in the process can introduce error, and people naturally err in favour of themselves. It is also common across all areas of business, as every organisation runs its own system of record.
The Internet gave us something special – in situations like this, it replaces clunky physical delivery of invoices and other documents with electronic messaging, whether by email or by more sophisticated messaging networks. It has become a universal shared communication platform. It’s wonderful, but has two problems; one of semantics, where different parties see the same data but interpret it differently. and another of trust, because while it makes communication easy, it doesn’t itself provide validation or provenance of the data that it presents.
Distributed ledgers re-use the idea of a common communication layer, but add several layers on top. The first is the idea of data, not just shared as with a conventional database, but also distributed amongst the participants. This is provided by several different mechanisms, such as the global state provided by Ethereum, or the individual agreement states provided by Corda. Next is the idea of shared business logic, encoded in smart contracts, which are enforceable and executable. This controls how data can change over time in a way that all parties agree with, even if it is not in their economic interest. For Ethereum this is run by all the network nodes, and for Corda this is restricted to the actual parties to an agreement in order to preserve commercial confidentiality. The shared business logic is ‘mutualised’, so that many participants can share the costs and expertise needed to develop it, as well as agree to be bound by the rules contained within it. Distributed ledgers also provide immutable data – so that instead of overwriting them, old data are deprecated and linked to by the new data that replace them. And finally, distributed ledgers provide data provenance, because all parties to an agreement can independently verify the correctness of the data, by utilising the features of immutability, non-repudiable digital signatures, open and deterministic smart contract code, and linking to preceding historic data.
As a result of shared data controlled by shared business logic, all distributed ledger platforms attempt to make the guarantee that we started with, that ‘I know that what I see is what you see’. Instead of separate perceptions of different participants, we arrive at a shared perception, which we can finally call ‘the truth’. So the real significance of distributed ledgers is that they are not distributing information, but are distributing a verifiable truth, an undeniable agreement, and that makes them as profound an innovation as the internet itself.
Most distributed ledger use-cases focus on maintaining consensus between competing parties. A great irony would be that while a truth layer has been established within an organisation, and the organisation knows that it sees the same as a competing party, the existing systems within the organisation cannot make the same promises about the validity of internal data. A gap emerges, and data provenance is not maintained for the ‘last mile’ of data flows into and out of the organisation’s systems. One of the areas of validation for Corda that we’re working on is to demonstrate that it can be harnessed for internal data management as well, since the underlying architecture supports this easily.