Of #Smart Contracts, Blockchains And Other Distributed Ledgers

Seems I caught Smart Contract Fever at last week's meeting of the Bitcoin & Blockchain Leadership Forum. So rather than continuing to fire random emails at colleagues, I've tried to calm myself down with a post on the topic.

For context it's important to understand that 'smart contracts' rely on the use of a cryptographic technology or protocol which generates a 'ledger' that is accessible to any computer using the same protocol. One type of 'distributed ledger' is known as a 'blockchain', since every transaction which is accepted is then 'hashed' (shortened into a string of letters and numbers) and included with other transactions into a single 'block', which is itself hashed and added to a series or chain of such blocks. The leading distributed ledger is 'Bitcoin', the blockchain-based virtual currency. But virtual currencies (commodities?) are just one use-case for a distributed ledger - indeed the Bitcoin blockchain is being used for all sorts of non-currency applications, as explained in the very informative book, Cryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic Order. As Jay Cassano also explains, another example is Ripple, which is designed to be interoperable with other ledgers to support the wider payments ecosystem; while Ethereum is even more broadly ambitious in its attempt to use smart contracts as the basis for all kinds of ledger-based applications.

Generally speaking, the process of forming a 'smart contract' would be started by each party publishing a coded bid/offer or offer/acceptance to the same ledger or 'blockchain', using the same cryptographic protocol. These would be like two (or more) mini-apps specifying the terms on which the parties were seeking to agree. When matched, these apps would form a single application encoding the terms of the concluded contract, and this would also be recorded in the distributed ledger accessible to all computers running the same protocol. Further records could be 'published' in the ledger each time a party performed or failed to perform a contractual obligation. So the ledger would act as its own trust mechanism to verify the existence and performance of the contract. Various applications running off the ledger would be interacting with the contract and related performance data, including payment applications, authentication processes and messaging clients of the various people and machines involved as 'customers' or 'suppliers' in the related business processes. In the event of a dispute, a pre-agreed dispute resolution process could be triggered, including enforcement action via a third party's systems that could rely on the performance data posted to the ledger as 'evidence' on which to initiate a specific remedy. 

Some commentators have suggested this will kill-off various types of intermediaries, lawyers and courts etc. But I think the better view is that existing roles and processes in the affected contractual scenarios will adapt to the new contractual methodology. Some roles might be replaced by the ledger itself, or become fully automated, but it's likely that the people or entities occupying today's roles would be somehow part of that evolution (if they aren't too sleepy). The need for a lot of human-readable messages would also disappear, signalling the demise of applications like email, SMS and maybe even the humble Internet browser. Most data could flow among machines, and they could alert humans in ways that don't involve buttons and keyboards.

So what are the benefits?

Well, it might take significant investment to set up such a process, but it should produce great savings in time, cost, record-keeping and so on throughout the lifetime of a contract. And, hey, no more price comparison sites or banner ads! Crypto-tech distributed ledgers would enable you to access and use a 'semantic web' of linked-data, open data, midata, wearables, smart meters, robots, drones and driverless cars - the Internet of Things - to control your day-to-day existence.

The downside?

This also might also play into the hands of the Big Data crowd (if they find a way to snoop on your encrypted contracts), or even the machines themselves. So it's critical that we figure out the right control mechanisms to 'keep humans at the heart of technology - the topic of the SCL's Tech Law Futures Conference in June, for example.

Meanwhile, I'm reviewing my first smart contract, which is proving rather like being involved in the negotiation of a software development agreement - which it is, of course. I'll post on that in due course, confidentiality permitting...

Regulating Convergence

This week I get the chance to chat about my three of my favourite topics from a legal standpoint: payments, peer-to-peer finance and data. 

All three are in a state of regulatory flux (which is also making for some late nights). But that tells you a lot about where commerce, and society itself are headed. The much vaunted 'convergence' of Web 1.0 has definitely arrived.

As ever, the challenge for independent regulation of these areas is to approach electronic commerce in a holistic way that promotes competition and innovation, rather than in a blinkered fashion that results that strangles innovative services at birth...

It should be a lively week.

More in a wrap-up post at the end.

DNA In A Cup, Rats And Primordial Soup

My article on recent developments in the data world is published at SCL - the IT Law Community.

Porting Midata Seems Simple Enough

LinkedIn (and Amazon.com) have demonstrated how easy it can be to transfer your transaction data from one service or application to another. This should be of interest to anyone interested in Midata.

LinkedIn recently took the decision to replace the function which allowed you to add third party applications to your LinkedIn profile with the ability to add direct links material hosted elsewhere. It appears that the third party applications had been necessary to enable the storage and display of the material on the LinkedIn platform. Ending that third party application programme will mean all the data you've loaded for display via at least some of those applications will no longer be available on your profile. The data would need to be transferred from the LinkedIn platform to a third party's systems in order to display or use it in similar fashion.

Unfortunately, I missed any notification of this decision, and only went looking for information in the Help pages when I found I could no longer add a book to my "Amazon Reading List by Amazon" app. (a nice way of tracking interesting books you've read). That I missed the news was a bit strange, as I'm a frequent LinkedIn user with over 900 connections, so maybe the commuication of this decision and its implications could have been handled a little better. 

However, the instructions for obtaining and displaying my reading list data were simple enough, and I am now the proud owner of a profile on Shelfari, the literary network facilitated by Amazon.com, into which I have imported my data from the application on LinkedIn.

Whether I can then display a list of books I've read to my followers on LinkedIn is a matter for LinkedIn. But it did seem that the updates to the reading list, rather than the list itself, was what sparked comment and discussion.

Midata Thoughts No. 2

I attended a meeting of the midata Transmission working group this week, which reviewed a set of scenarios based on those described in my previous post on this topic. I've updated my legal presentation by way of an overall summary, and will embed it below shortly. The working group scenarios are likely to go into a bit more detail and involve additional sub-scenarios. I assume they will be available once they have been reviewed by all the working groups and are considered in final form - possibly as part of a final report.

In essence, our discussion this week focused on: 

• clarifying the likely use-cases and consumer/small business benefit: the first few scenarios reflect how midata currently flows (e.g. release of current account data via online banking) which we agree is not terribly consumer friendly. The later scenarios reflect a more likely outcome, as new analytical and 'dynamic switching' services arise, for example, or as consumers begin to negotiate specific products or pricing (whether alone or in collaboration with others); and

• differentiating the various types of services that may be offered by new intermediaries (previously called 'personal information managers'): 

•  Midata Store: this service would only involve the provider acting as a reasonably passive repository of midata on the Customer's behalf, (e.g. merely holding it, or displaying and/or transmitting it without any alteration) could be called, say, a "Midata Store". It was also considered necessary to distinguish between a Midata Store that only receives midata from the Customer, and one that receives midata directly from a Current Supplier via a direct interface ("Linked Midata Store");

•  Midata Service Provider: this type of service would involves the receipt of midata on the Customer's behalf for the purpose of analysis, combining that data with other data and/or producing some kind of reliable result for the purpose of negotiating with Current Supplier or Third Party Supplier would involve processing on a greater scale.  This would clearly involve more technological (as well as contractual and co-regulatory) safeguards.

It was considered that Midata Stores and Midata Service Providers are likely to evolve their own specific technology/transmission standards and self-regulatory codes quite quickly, in addition to any trnsmission guidelines etc produced by the Midata programme. However, it would be difficult to mandate the creation of a specific trade body or related code at this point.

The next meeting I am due to attend is a meeting of the legal and regulatory working group at the end of this month.

Midata thoughts 121212 v2.0 from Simon Deane-Johns

Midata Thoughts No. 1

Hard on the heels of the government's recent warning shot, we're now into the working group phase of the voluntary Midata programme.

I'm involved in the working groups on Transmission and Data Protection Regulation & Enforcement. Other members of the Interoperability Board are also looking at Identification; Data Storage; and Onward Data Release to Third Parties. In due course, we will draw those aspects together, with the exact form and format of the output to be decided.

Of course, this is not intended as a 'closed shop' and I have tried to be transparent, via this blog, about my involvement. This has included publishing a summary of my response to the Midata consultation over the summer. In keeping with that, I am now embedding below a presentation of my initial thoughts following discussions on the roles of participants, process flows, the developing co-regulatory environment, risks, controls and challenges. I have also included scenario diagrams covering the three types of scenarios involved.

I welcome any comments, queries or suggestions you may have. I will post further updates in due course.

Midata Thoughts No. 1 from Simon Deane-Johns