Lawyers Dancing on a Blockchain

For some reason, lawyers, in particular, seem to be drawn to the concept of Blockchain or Distributed Ledger Technology (DLT).

I believe, it may be something to do with the fact that lawyers work in a profession where ‘truth’ is decidedly optional. Lawyers spend their lives dissembling, obfuscating,?being selective about facts?without, of course, ever ‘actually’ lying.?Furthermore, if you want someone to argue the opposite case, just ask the same lawyer and pay the fees. They will vigorously defend any case that are being paid for, and sometimes, to their credit, pro bono.

So, if lawyers come upon something that may be immutably TRUE, they will be attracted to it, like moths to a flame , even if theoretically?such a concept would put them out of a job.

Recently, the UK Law Society[1] published* a huge report that attempts valiantly to be somewhat even-handed about technology but fails miserably to remove the stars from ?their eyes (dripping with conformation bias).?It is?classic legal document, lawyers dancing on the head of a pin, ?without noticing that the pin does not exist; the pin is just hot air.

An example of the confirmation bias that pervades this document is the definition of DLT:

“The term DLT refers to a broad umbrella of technologies that seek to store, synchronise and maintain digital records across a network of computing centres”

But of course, the many systems that are used today in business around the world, even in law firms, could fit this definition precisely, even more so, as many small businesses are migrating to the ’Cloud’.

So, we (and the lawyers) are none the wiser about what a DLT actually is, but we will give the Law Society the benefit of the doubt that they are scrambling in the dark for some justification for this huge effort and we ‘sort of’ know what they mean.

The document proceeds through an interminable 236 pages of stuff that is cobbled together with no apparent coherent story, other than we think we know something you don’t.?The author could dissect it in detail but it is not worth doing so because the report falls at the first hurdle, actually Section 1, which, in a very lawyerly touch , starts at page 28 .

Very clumsily, the introduction tries to slide over the tough question – why exactly should I bother to read this – by making a pig’s ear of trying to differentiate between centralised, decentralised ?and distributed ‘ledgers’.?The writer concludes that even though centralised and decentralised ledgers[2] ?are used day in day throughout business, ‘distributed’ ledgers are the way to go.

So, what is a distributed ledger? Doesn’t give a real definition but states, after bad-mouthing the opposition, ?that

“Distributed ledgers seek to avoid the drawbacks associated with centralised and decentralised ledgers by, amongst other things, removing points of failure … ?Distributed ledgers see the ledger (or parts of the ledger) replicated and stored across a network of computing centres. This network of computing centres, known as nodes, work to update the ledger as new updates (i.e. transactions) arise, and propagate the updated ledger to the network.”

Of course, ?that would be a jolly good thing if it were not for the fact that THIS IS HOW FINANCIAL TECHNOLOGY WORKS TODAY! And has done so since last century.

9/11

The 9/11 attack on New York did enormous damage to life and property but failed in one of its primary objectives – to inflict serious damage to the US and world’s financial systems. One of the many stories of heroics at the time was of the IT staff who managed to reorganize the world’s financial networks in a matter of a few ?hours to keep banks open even though huge damage was done ?to financial infrastructure. ?

A year after the terrible events, the Vice Chair of the Federal Reserve wrote:

“Despite the shock, long-term devastation, and disruption of public infrastructure and commercial activities in the world's financial center, the U.S. financial system largely remained open throughout the day and thereafter. Banks and other financial intermediaries stayed open. Key wholesale and retail payments system remained operational, like other financial activities, except to the extent that telecommunications disruptions had a temporary or local effect. Even firms in the World Trade Center were able to resume business from other offices or from contingency sites within hours of the attack. The response of the financial industry and the speed with which it resumed business was extraordinary and can be attributed only to its long-standing commitment to, and extensive preparations for, ensuring continuity of operations in the wake of physical and cyber disruptions”.

And how did the many firms impacted by 9/11 actually do that?

By using Distributed and specifically Replicated systems and databases (Ledgers).?Wall Street firms had been preparing for just such a disaster for years and their professionalism kicked in to save the US and world economy.

For anyone familiar with the technology involved and location, the picture of a group of people standing on the Jersey City waterfront looking across the Hudson ?to the Twin Towers and watching their colleagues die in Lower Manhattan ?is especially poignant. They were the lucky ones and they turned around, went back to their offices and worked tirelessly to keep their firm’s systems and the financial systems going.

How come these people were in Jersey City?

In the 1970s, computer systems in the financial industry ran on large expensive ‘mainframes’ and because telecommunication technology was immature, these systems tended to be located in the same buildings as their users, in Wall Street or the City of London.

However, managers were very well aware of how vulnerable such a set up could be. In 1975, bombs were exploded by Puerto Rican nationalists near Wall Street. And from the 1980s until 2000, bombs, detonated by the IRA, were exploded across London, impacting the major financial centres.

From the 1980s, large financial institutions ?began to build back-up or secondary data centres away from financial centres, which could be activated within hours if a primary data centre was lost, not only due to bombs but other disasters, such as floods. These were known as ‘cold’ standby sites.

As telecommunications improved, especially using fibre optic cabling, it became possible to transmit data from a primary to a secondary site in real time, which allowed the secondary data centre to be brought into action quickly if there was a disaster at the primary location. This was known as a ‘hot’ standby.

The same high-speed telecommunications technology also allowed data centres to be relocated away from city centres to greenfield locations that could be more tightly secured but in turn that placed pressure on firms to have multiple independent ?telecommunications providers.

Although, hot standby in the event of a disaster at a primary site was good it became obvious that even a small delay could prove unacceptable, and so the concept of ?‘parallel’ operations was developed in the late 1980s. This meant that the same systems could be running on both sites ‘in parallel’, sharing the load but configured such that ?if one site ‘went down’ the other could take over and handle the volume until the failed system came back up again, and started to again take up some of the load.

From the 1990s, as computers became ever smaller and more powerful, the need for large specialised data centres became less and the concept of networking batteries of smaller computers to act as a ‘server farm’?became the dominant data centre architecture. And server farms could be located anywhere that was reachable by reliable, fast telecommunications networks and today processing is ‘distributed’ across such server farms according to the optimal mix of ?processing and response times required.

But you don’t get anything for nothing!

In a parallel environment, how does one ensure that a transaction is processed once and only once, since no one wants to be duplicating massive payments?

To achieve this critical objective, there must a degree of synchronisation[3], such that when one computer ‘claims’ or is ?‘allocated’ a transaction it is permitted to complete it, while other computers process their own allocated transactions.

But what happens if a computer that has been allocated a transaction fails, through software or hardware error??Then the transaction(s) ‘in flight’ must be retrieved and reallocated to other computers to complete. And when the failed computer returns, any ‘in flight’ transaction(s) must be cleaned up.

It is the software that synchronises the flow of transactions into and out of a server farm that ultimately determines the performance and reliability of any truly distributed system. And it is a non-trivial problem.

But in the distributed architecture proposed by the Law Society, there is no synchronisation , except reference to a particular software package ?- no need to worry about missing or duplicate transactions.

In?fact, the report claims that

“ Distributed ledgers are, theoretically, infinitely scalable, and by distributing their control and maintenance, seek to mitigate against the risk of attack”

The silly braggadocio of that comment is illustrated by the observation that with an infinite (or even very large) number of distributed ledgers in a real time configuration, one would never know which ledger was actually correct because they would all be processing every transaction at different speeds. This is made worse by the fact that the communications method proposed is by ‘broadcast’ and it cannot be assured that all ledger processors will receive all of the transactions in the same order[4], a problem that gets worse as the number of ledgers grows.

While the concept of a DLT is pitched as being state of the art, it is in fact already being overtaken by open-source software[5] and distributed databases, which are more flexible and tailored to business requirements and, of course, could be moved eventually to the Cloud.

The concept of the so-called ‘distributed ledger’ , which is THE rationale for this document, is not only ?ill-considered it is completely out of date and the report betrays a fundamental lack of knowledge of modern financial technology and current best practice transaction processing architectures.

To paraphrase Rumpole of the Bailey “I often think that a [lack of] knowledge of Technology is not a barrier to a Barrister’.

* Apologies, original references lost on transfer to LinkedIn

[1] Technically, although under the auspices of the Law Society, the document has been produced by a group called the Tech London Advocates (TLA).

[2] I believe that the writer actually means ‘databases’ but we will go with the characterisation for now, since DDT has other more deadly ?connotations.

[3] The report does mention synchronisation but gives no example of what its purpose is and how it operates, except to mention particular software package. Synchronisation which is essential to robust operation is relegated to a mere afterthought.

[4] Imagine the situation where a debit is received out of sequence before a credit and the transaction is refused.

[5] Such as Apache Kafka, EventstoreDB or Cockroach for diverse applications. However, there is no single magic bullet and any solution must be tailored to the business requirement