Perspectives Beyond Blockchain
Lessons from Correspondence Chess
In correspondence chess, players exchanged their moves using letters over the mail (usually postcards because of the cheaper stamps). It may be hard to understand, in these days of Word Feud and other faster-paced games, but people could really enjoy playing with the glacial speed of the postal services.
A quite ingenious variant was chess by money transfer. The Netherlands had a ‘Giro service’ quite early, starting in 1918; it was even the first such fully automated service in the world. The Giro provided easy and cheap money transfer. As we have today with money transfer, a limited space was available for a message on the why of the transfer. Plenty of room for a chess move! People would transfer a low amount of money to and fro, sometimes no more than a single cent. Obviously, the money wasn’t important at all — but a transfer of zero cents wasn’t allowed.
The Giro didn’t mind. On the contrary: a transfer is a transfer and people paid their transaction costs (usually less than the cost of a stamp). An additional boon for the players was that the Giro kept a perfect history of the game: they could not repudiate their moves.
Chess by money transfer turns out to be a perfect model for Blockchain, especially the more programmable variants such as Ethereum. If it weren’t for Vitalik Buterin’s youthful age, I’d swear he must have played Giro chess as a kid!
This is how it goes.
Blockchain(1) has these features:
- anyone can participate to become a user, by opening an account and putting some money in it (2);
- every user can add data to his account;
- every user can transfer money to other accounts and include some data.
So far, we have perfect correspondence with a banking system. Of course, this is exactly what Satoshi Nakomoto had in mind when he created Bitcoin. But Vitalik Buterin went beyond, by exploiting the room for extra data. His Ethereum can be programmed.
Let’s extend the Giro chess metaphor. Imagine someone setting up a calculation service (we’re talking pre-internet here!). A Giro account holder could use that service by transferring a fee into the service account, sending along a calculation to be made. The receiver — let’s call him a ‘computer’ — would perform the calculation and return the answer by transferring back a single cent.
Now you’ll be able to guess the extra features of Ethereum:
- every user can install (Blockchain) programs on it (3). A program has an account, too;
- a program can be started by every user, by putting some money in it’s account out of his own account (think of it as a jukebox);
- programs can be constructed to involve other users. They then can share data and exchange money according to the program’s logic.
This is how a Blockchain program that performs a specific computation is operated. To activate it, send some money to the program’s account and the data for it to work on. Now envision the possibility of program accounts calling each other to set up really complex computations, and you have a firm grasp of Ethereum’s virtual machine.
Usually, Blockchain is explained in terms of a ‘public ledger’. If you find that hard to understand, just think of how the Giro kept a perfect record of the transactions that make up a game of chess. The players could not repudiate their earlier moves. This is precisely what Blockchain guarantees, too — albeit without a central organisation like the Giro that keeps the books and vows for it. Anyway, we can skip the ledger without compromising our understanding of Blockchain, as long as we keep in mind that data on the Blockchain cannot be secretly changed. It is non-repudiable.
So the Blockchain makes for a deployment infrastructure that guarantees its users absolute transparency with regard to data storage and handling. How is that for a change, eh?! There is no one that can fiddle the knobs, no one to whisk away some details. All those involved in a particular program, have, in principle, full access to all that is going on. So if a rogue user tried to do something fishy with his or your account, you’d know it. And there is no central authority to run it or to bar anyone from participating. No wonder Bitcoin/Blockchain made headlines, ten years ago.
Now while this is all really, really clever, it is clever in the way of a singing saw. Clever, as in: apply something that is meant for a particular purpose, to an entirely different task. Of course, one is impressed by the music that can be concocted out of a saw; but for concert hall performance, a violin is preferred.
If Blockchain is the saw, what is the violin?
It turns out that Blockchain is used for all sorts of co-operation tasks. Fair trade, property transactions, notary transactions in general, insurance claims processing, identity management, tracking supply chains, voting in elections all are examples. While Blockchain languages are ‘Turing complete’, meaning any program can be expressed in them, you won’t typically use a Blockchain to run, say, an astronomical simulation, a word processor or a spreadsheet. As a matter of fact, Blockchain deployment is not exactly lightning fast, nor cheap. So to find a business case, you’d really have to capitalise on its outstanding features and these would be universal access and non-repudiation. Non-repudiation gives it away: to repudiate is ‘to deny the truth or validity of’ and this is something that happens between people (start to repudiate your statements to yourself, and people might doubt your sanity). So, co-operation.
To sum it up: Blockchain is used as an infrastructure to support people who act together. But piggy-backing co-operation support on money transfer is not the most straightforward way to get at it. Here are three reasons why it is not even a good idea:
First: by intertwining computation with financial accounts, Blockchain is of necessity a paid deployment service. Put simply: you cannot run a program without paying. This is similar to computing in the cloud. Pay up and run your program. Nothing wrong with that in principle, but it swings an economic force into play: competition on price. Now it turns out, in computing services, that bigger is cheaper and therefore better. This is why we see enormous concentration of cloud services; it is not like there is a cloud service operator in every town, like there is a barber.
But concentration is anathema to Blockchain! It’s special features depend on distribution, not centralisation. The ultimate insult would be Amazon running a giant Blockchain(4). To concentrate Blockchain is to defeat its purpose, its usefulness.
Second: there is nothing in Blockchain and its languages that make it particularly suited for co-operation, other than its non-functional qualities(5) and the fact of user accounts. The languages are just conventional imperative languages, with access to a rather simple database built in, no matter how devilishly clever it is to infuse the notion of computation to the bones with money transfer practices!
Third: co-operation is always local to some context. A co-operation involves a limited number of people. In that context they exchange information to co-ordinate their actions. That information should not leave the context. This is what privacy is about. However, Blockchain’s users share a single database. This brings all known problems with privacy into play. It also explains the fascination, in the Blockchain community, with encryption. If you cannot keep your information distribution in check, you’ll have to make sure only the right people can make sense of it. This shows that the way non-repudiation is achieved (by making information accessible to everyone) conflicts with privacy.
Blockchain’s popularity shows the deeply felt need in society and the responsible part of the computing community to support co-operation with an infrastructure that cannot be monopolised, that cannot be turned into a money machine at the expense of citizens and the fabric of our society. But as a solution to fulfil that need, it is flawed. Blockchain was meant to support a monetary service and notwithstanding ten years of ingenious R&D, it has not outgrown these roots. I argue it never will, given the conceptual entanglement between computation and finance.
This does not preclude good support for co-operation. I’ve explained Perspectives in some detail in previous posts (e.g. Stop Talking About Data!) and I will continue to do so in instalments to come. In brief: Perspectives is a method to design co-operation, bringing concepts like context, role and action to the table. Perspectives models can be executed on a distributed runtime. This solves the deployment problem completely: we all bring our own device. Deployment is not a service, in Perspectives. When a model is executed, the runtime guarantees the following invariant: if, according to the model, you can or need to perform a task, you’ll have all necessary information on your own device, automatically. Nothing more, nothing less and neither is there a central repository that holds all data. This means that privacy is completely in the hands of the modeller.
The very fact that information is spread among those who need it, goes some way towards non-repudiation. For many purposes, this is quite good enough. It is not as if non-repudiation is a big thing in, say, co-ordinating your babysitting, running a church fair, or any other of the hundreds of co-operations in your daily life. But sometimes it is not enough, the primary example being, again, money transfer. For these situations, Perspectives can be used to build a witnessing scheme — but that is for a next post.
So, yes, you can make Blockchain sing; but for many reasons, look beyond, to Perspectives!
This is the fifth column in a series. The previous one was: The internet is not for sharing. Here is the series introduction.
(1). I will write as if there is but a single Blockchain system (ignoring all the varieties out there) for clarity of exposition, without loss of generality and force of argument.
(2). There is a long story about tokens etc. but for simplicity we can think of it as money.
(3). The programs on a Blockchain need to be written in special languages.
(4). I have not explained this. The short argument is that Blockchain’s database is copied and kept on many servers, precluding attempts by any one server operator to monopolise it and thereby create an opportunity to fiddle the books. See “Why Any Blockchain Will Become Centralised”.
(5). Non-repudiation and universal access are the non-functional qualities I’ve capitalised on in this article. Availability and reliability are examples of other non-functionals.