Blockchains in search of a problem
(and why Ethereum is a not-so-smart idea, if not borderline insane)
One of the results of the BitCoin mania of the past two years is, is that so-called blockchains are being recognised as practical solutions for certain problem spaces, such as the degree to which there is consensus about who owns what at a certain moment. The Ethereum project is an attempt to take this to another level: “smart” contracts and grid computing. Yes, that sounds pretty esoteric because it is. Read up on their white paper which explains it somewhat, in case you are unsure what these concepts mean. And they do have some merit, but not for what they are proposed for.
Long story short: the application of crypto-currency concepts to contracts is fit for textbooks as an example of a solution in search of a problem. The problem with contracts, even as mundane as the type of financial contracts the Ethereum white paper gives as examples, is rarely their authenticity.
Contracts are merely artefacts that bear witness of the obligations of the parties to a transaction. And like human witnesses, the accounts they give are almost never the complete picture of said obligations. While contracts in common law countries tend to be much more elaborate documents than they are in civil law countries, they still do not provide all answers to the questions that can arise over their execution. If they are well-drafted they will provide answers to the vast majority of foreseeable questions that can potentially arise, either by explicitly answering them or through reliance on the pre-existing body of applicable law. To put it in programmer’s terms (since anyone interested in this stuff is quite likely to be familiar with those anyway): contracts are not unlike computer programmes. Computer programmes tend to rely on existing building blocks such as libraries, make API calls to an underlying operating system, using the vernacular of the underlying processor architecture (be it opcodes or bytecode in the case of Java-like bytemachines). Contracts build similarly on the existing (but also future) body of law, be it statute law, jurisprudence, international treaties or unwritten law such as customary law and even the underlying principles of law. They are also written in a vernacular (legal English for example) that has lots of implied assumptions about their execution, with courts as their ultimate arbitrators. This is what makes choice of law and venue clauses so immensely important for conflict resolution: different courts in different jurisdictions may give different interpretations to begin with.
But here the similarities more or less end and the differences begin. For starters, that existing body of law is in continuous flux. Because law is an ongoing collective journey of discovery into our understanding how we, as a society, feel we should resolve our conflicts peacefully or at least with the minimum amount of violence necessary. In that problem space the question of the authenticity of an artefact that bears the incomplete witness of the parties’ obligations is vanishingly small grain in a vast desert of moving sand dunes. Simply put: the authenticity of a contract is rarely, if ever, questioned in practice. And if that happens, there tends to be sufficient circumstantial evidence to answer that question. Putting blockchains to use for this problem is nice, but the problem is nowhere near acute enough to expect any uptake of block chain technology for this. Because even in the era of picture-perfect scanners and printers we are fine with hand-written signatures. The big questions of contract law are about their meaning, not about their syntax. And the actual meaning is time and location dependent, but never completely knowable.
That said, blockchains do have interesting potential applications in the legal sphere for specific purposes: the registration of information that must be publicly available and whose veracity must be without question for prolonged periods of time. Meaning decades, if not centuries. Think about published legislative documents, administrative decisions such as permits, real estate registries, etc.
Which gets me to the true insanity of the Ethereum project: it proposes the mixture of data and code. Basically, “”smart” contracts (or documents for that matter) are written in a Turing-complete language on purpose (because they feel that is an unnecessary limitation of Bitcoin). They rely on the execution of arbitrary code on your computer for you to even read them. Which means that they add another level of fundamental unknowability, because of Turing’s halting problem. A much more eloquent and learned explanation why that way lies madness can be found in this great lecture by Meredith Patterson and Sergey Bratus at the 28th Chaos Congress. “Smart” contracts cannot be made secure and are therefore a dumb idea. “Smart” legal documents in less expressive languages may have a valid use and are worth looking into, but not for contracts.
A not-so-brief post scriptum (subject to further change)
This little rant of mine drew a lot more attention than I expected. And subsequently some criticism. Mostly that I was being too harsh, had misunderstood “smart contracts” since they are not contracts at all and am misconstruing the halting problem to the point of “smoking crack”, which is supposedly irrelevant anyway because of the instruction limit of Etherium.
For starters the notion of a “smart contract” not being a contract at all and therefore being misunderstood. The short answer is: words have meanings and if you do not want your concept to be conflated with traditional contracts do not call them contracts. The longer answer is that the first time the term “smart contract” was coined by Nick Szabo in 1997 it already was meant to cover legal documents. And no, I was not aware of Szabo’s work when I wrote my little article. To quote Szabo:
The basic idea behind smart contracts is that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher.
If anything, this means that the notion of “smart contracts” has been tied to contracts in general from the very start. In a way, Szabo already understood that law is code, and code is law, way before Larry Lessig did. He understood it wrong, I think, but that is for another article. All this doesn’t mean that Ethereum “smart contracts” are real contracts, Jens Cook suggested they should have been called “smart instruments” and I think he is right. If they had been called that I never would have written the article anyway.
On the halting problem, and its irrelevance because of the instruction execution limit: the instruction execution limit is irrelevant because of the possibility to daisy chain “smart contracts”. A more sophisticated argument is that the halting problem is being misconstrued since it is only mathematically proven to be unsolvable if the instruction space is infinite. Which, even with daisy-chained “smart contracts” is not the case here (although ironically enough a wide adoption of Ethereum would lead to the closest real-life approximation of this). That still does not mean that Turing’s halting problem has no application at all when not all of its preconditions are fulfilled. It is part of a larger body of work. Fore example there is the more generalised Rice’s theorem which has subsequently been generalised even further to:
There exists no automatic method that decides with generality non-trivial questions on the behaviour of computer programs.
Which means that unless you prove a programme’s behaviour mathematically in advance, you have a weird machine that is fundamentally unpredictable. And therefore insecure. Which means that Ethereum is either fit for trivial computational problems or fundamentally insecure.
(background photo CC-BY NobMouse @ Flickr)
