Beyond today’s generation of Blockchain – a lesson from the Wright Brothers

Ok, Blockchain continues to be hot. As CBInsights points out, Q1 2017 saw startup investment deals rise for the third consecutive quarter and the number of deals has grown an average of 16% QoQ since early 2016.

The reasons for the heat remains the potential disruptive implication of distributed ledger capabilities on how financial transactions are initiated, cleared and settled. Entire swaths of mid- and back-office functions across all types of financial instruments could be eliminated, with implications on every organization that deals with financial exchanges and payments. Which would be, uhm… everyone.

The operative word here is “could.”

There are many blockchain pilots, but as of yet, no production-scale implementations.

Why is that?

Let’s answer this question with an analogy -– from the first flying airplanes.

Lesson from the Wright Brothers (insight from Paul Dowling)

Samuel Langley (1834 – 1906) was an early pioneer in aviation, much as Ethereum (and others) represent the first generation of block-chain deployments. (Or, as Paul Dowding likes to say, the second generation, with Bitcoin being generation one.)

However, Langley’s ‘plane’ was never able to sustain flight. Enter the Wright brothers.

The Wright brother’s first explorations in aviation faced the same challenges / failures as did Langley’s. They realized, after their (performance) failures, that what was a needed was a re-think of aeronautical design principles. The execution problem wasn’t getting in the air, but rather being able to stay in it. In short, Langley’s model couldn’t scale. The tight focus on this part of the execution problem (e.g., to stay in the air) led the Wright brothers to re-think what the execution issues were and consequently develop new design principles to overcome them, namely, performance (staying in the air) and capacity (staying in the air a long time) issues.

Again, there was nothing “wrong” with Langley’s design… for the problem it was designed to solve – namely, getting in the air.

The lesson?

Focusing on the control issues to sustain flight required a re-think of the architecture and design of aviation – based on a new set of principles and capabilities that tackled the constraints of the previous ones in a new way. Throwing more people at a set of constraints within a design that structurally cannot scale – e.g., doing more of the same, only more of it – seldom works. It didn’t for Langley. And it arguably, won’t for blockchain.

Let’s take but one example of a current blockchain constraint, namely performance & scaling – characterized as latency, whereby you can’t go fast-enough not nearly near the level of the 30,000 transactions / second that would warrant the interest of a scalable leader, such as MasterCard or a clearing house for securities.

One of the key challenges rests on is consensus algorithms which works well within a small network structure (nodes) such as Repos where everyone knows each other and the transaction volume isn’t significant. But in a much higher, and shifting network, getting the consensus required based on the linear design of the transaction today will not work – which is why so many of the tests and use-cases banks (of all types) around blockchain remain “toys” or remain limited to well-bounded node structures. 

In short, a fundamental flow of today’s brute-force approach to making blockchains faster is its underlying design. As Paul Dowding, a brilliant and refreshingly pragmatic managing director at Gartland & Mellina, a high impact boutique consulting firm within the financial industry put it, “You can’t design a system (the first generation of blockchain) then add in scalability & process. You need to design it in. Otherwise, the constraints you’ve built into that process will be impossible – financially and time-wise – to wring out.”

What’s required is much like what the Wright Brothers did whether examining Langley’s design or their own initial failures: re-think and re-architect principles of performance, scalability and flexibility.

Which is what Paul is and has done… stay tuned!

Without solving these structural problems, there is no way functional areas will have either the confidence or willingness to move from pilot to production… in their area.

What’s required is much like what the Wright Brothers whether examining Langley’s design or their own initial failures: re-think and re-architect principles of performance, scalability and flexibility.