Richard Gendal Brown is CTO at R3.
This exclusive opinion piece is part of CoinDesk’s “Bitcoin at 10: The Satoshi White Paper” series.
There is a phenomenon in anthropology called the “Cargo Cult.” It was first observed in Melanesia in the late 19th century and most famously chronicled after World War II when remote Pacific tribes created pastiche airplane runways and mimicked long-departed air-traffic controllers in attempts to stimulate the return of military airdrops.
Cargo-culting consists of groups of people mistaking form for substance, latching on to an easily visible concept without understanding the underlying reason for its existence.
As we celebrate the 10th anniversary of the email that announced the birth of bitcoin, I have been reflecting on the prevalence of cargo-cults in the blockchain industry, what caused them and what we should do about it.
For example, many of the first business blockchain platforms broadcast all data to all participants, or coarsely-defined subgroups of participants. This isn’t how business works – contracts should be private of course. But full broadcast was how bitcoin did it so it sometimes felt like those platforms ‘cargo-culted’ the same concept, even though it made perfect sense for Bitcoin but absolutely no sense at all for business. They have since revised their designs but, as a community, we should ask ourselves: how did that happen? Can we do better in the future?
Similarly, many business blockchain platforms run on something called the Ethereum Virtual Machine (EVM) and require developers to program in a language called Solidity. Not because businesses want to learn entirely new languages but because that’s how ethereum did it.
The problem is that, whilst the EVM was an amazing achievement, it was only ever a temporary stopgap: the Ethereum community publicly plan to abandon it in the near future. So it’s hard to think of a reason for adopting it for entirely unrelated purposes, except perhaps for reasons of cargo-culting. This has real consequences: learning new languages costs money and technical decisions made by businesses last for a long time.
If these EVM-based business blockchains take root, one could imagine the world’s business ecosystem could be running the EVM long after the platform for which it was invented had moved on!
This slavish adherence to one specific solution to one specific problem even extends to a core tenet of the enterprise blockchain revolution: the existence of blocks.
Satoshi Nakamoto didn’t wake up one morning thinking: “What the world really needs is for transactions to be batched up and confirmed slowly in blocks!” No, bitcoin is a batch system because physical reality – the speed of light – means it’s impossible to design it any other way if you also want to achieve the system’s design goals around pseudonymous cryptoeconomically-intentivised consensus.
If Satoshi could have built a real-time system he would have done so.
So if you don’t have some of bitcoin’s requirements, what’s the argument for why your solution should look identical and work like a 1960s batch mainframe computer?
An Example to Strive For
I’ve long argued that the world of enterprise blockchains will consolidate far faster than anybody expects, that a “day of reckoning” is coming. On this, the 10th anniversary of the paper that sparked bitcoin, we can, perhaps, use a worked example to see what we can learn from how Satoshi approached this question of design, a design that was truly novel, and free from cargo-culting.
Reproduced below is the email that announced the birth of the entire project. Its first line reads: “I’ve been working on a new electronic cash system that’s fully peer-to-peer, with no trusted third party.”
With that deceptively simple sentence, Satoshi Nakamoto announced the arrival of Bitcoin.
Captured in those 19 words was what amounted to a precise requirements specification. Not a cargo-culted replication of an inappropriate idea from the past, but a specific set of requirements, from which a specific design then followed.
Let’s unpack some of those words to see how Satoshi did it.
- Fully peer-to-peer: so no central computers.
- No trusted third party: so the electronic cash must be intrinsic to the platform. (Otherwise you would have to trust the issuer.)
This also explains why there is such a focus on network participants running their own nodes: if you can’t rely on software you operate and control, then you’d be reliant on a trusted third party.
Perhaps more importantly, the lack of a trusted third party also implies that the transaction confirmation providers – miners – cannot be forced to be identified or else the need for an identify provider reintroduces a trusted third party through the back door.
This deliberate absence of real-world identities means you can’t implement “one participant one vote” so you need some other way to link to the real world. This leads to proof-of-work that layers one confirmation on top of the last which, in turn, means you have to give time for confirmations to propagate around the world which, in turn, leads to a need for batching, and hence the confirmations must come in the form of blocks. And so forth.
It’s only a small exaggeration to say that the entire architecture of bitcoin unfolds inevitably and relentlessly from those 19 words.
You work through the details and the whole architecture falls into place.
Risks and Choices
In sum, bitcoin is an amazingly elegant solution to a very well specified business problem.
It’s not without its problems, of course. And many of them are deep and fundamental: technical, environmental and cultural. But we can’t underplay the scale of Nakamoto’s achievement. Ten years on, the proliferation of “blockchain technology” would seem to suggest Nakamoto has been highly influential.
And yet… As I argued above, not all of the business blockchain platforms of today derive from a precise requirements specification and arduous engineering process. Instead, they feel very different. Some are, effectively, cargo-culted replicas of systems designed to solve very different problems.
The resolution of this problem lies in engineering.
To see what I mean, let’s look at Corda, the open-source blockchain platform my team supports and maintains, with the help of a large and growing open-source community. I don’t intend this piece to be a sales pitch – so I’ll say up front that there are problems to which Corda is an amazing solution… and problems for which is it not! Study it for yourself – and apply it where it makes sense.
But that is also my point: Corda is an engineered solution to a specific problem.
It so happens that Corda shares a lot in common with other blockchain platforms (cryptographically chained transactions, byzantine fault tolerant consensus options, massive scale and far more). But it also looks different in some fundamental regards.
As a result, we in the Corda community have been criticized for these seemingly unconventional design choices. But I believe this criticism was misplaced. The reason platforms like Corda look different is because they solve different problems and were engineered from the ground up to solve them. The differences are a feature, not a bug, so to speak.
For Corda, our mission is to enable people and firms to transact directly, with legal certainty, settlement finality, strict privacy, and total assurance that “what you see is what I see.” As a result, its design is different. For example, there is an identity layer, transactions are sent only to those with a need to receive them, transactions are confirmed one-at-a-time in real-time and so forth.
Those platforms that have identified a clear problem to solve and engineered a good solution to that problem are in rude health. Fresh off the back of the largest CordaCon ever, we head into 2019 with production deployments under our belts and large-scale adoption just ahead of us.
Thank you, Satoshi, for showing us the way.
Astronaut image via Shutterstock