code – Page 2 – Alice, Eve and Bob

The first thing to know about blockchain smart contracts is they’re not contracts, smart or necessarily on a blockchain. They are, in fact, singularly ill-named*. Let’s address these issues in reverse order, and we should find out exactly what a smart contract actually is along the way. First, and introduction to what transactions are, and things which aren’t transactions.

An intro to transactions and non-transactions

The best known blockchains are crypto-currencies like bitcoin**. The thing about currencies – virtual or not – is that what you mainly want to do is buy or sell things using them. What you want is a simple transaction model: “once I provide you with this service, you’ll give me this amount of currency.” We know how this works, because every time we buy something in a shop or online, that’s what happens: the starting state is that I have x amount, and the state after completion of the transaction is that I have x-y amount, and you have y amount****. It’s the moving from one state to another that you care about before you complete the transaction. Most crypto-currencies are set up to support this type of construct.

This is great, but some clever people realised that there are actually many different ways to do this. Ethereum was where non-transactional constructs made it big time, and Solidity is the best known example. Both, I’m pleased to say, are open source projects. Why not have a more complex set of conditions that need to be met before I hand over whatever it is that I’m handing over? And – here’s the clever bit – why not write those in code that can be executed by computers? You might want the currency – or whatever – only to be released after a certain amount of time, or if a stock price keeps within a particular set of boundaries, or if a certain person continues to be prime minister*****, or if there’s no unexpected eclipse within the next five days******. You could have complex dependencies, too: only complete if I write a new post three weeks in a row and nobody writes unpleasant comments about any of them*******. Write this code, and if the conditions are met, then you move to the next state.

Not just for blockchains

Let’s start addressing those “not” statements.

Now, in a blockchain, the important thing is that once the state has changed, you then ensure that it’s recorded on the blockchain so that it’s public and nobody can change or challenge it. But there are other uses for blockchain technology, as I explained in Is blockchain a security topic? Permissionless systems, often referred to as DLTs, or “Distributed Ledger Technologies” are a great fit for non-transactional state models, largely because the sort of people who are interested in them are closed groups of organisations who want to have complex sets of conditions met before they move to the next state. These aren’t, by the tightest definition, blockchains. Banks and other financial institutions may be the most obvious examples where DLTs are gaining traction, but they are very useful in supply chain sectors, for instance, where you may have conditions around changing market rates, availability and shipping times or costs which may all play into the final price of the commodity or service being provided.

Not that smart

Smart contracts could, I suppose, be smart, but for me, that means complex and able to react to unexpected or unlikely situations. I think that people call them “smart” because they’re embodied in code, not for the reasons I’ve suggested above.

That’s actually a very good thing, I think, because I don’t think we want them to mean what I was talking out. Most of the usages that I’m aware of for “smart contracts” are where two or more organisations agree on a set of possible outcomes of a system based on a set of known and well-constrained conditions. This is what contracts are generally about, and although I’m about to argue with that part of the nomenclature as well, in this context it’s fairly apposite. What you want, generally, is not unexpected or unlikely situations and smart processing in an AI/ML type way, because if you do, then the parties involved are likely to get outcomes that at least one or more of them are surprised, and likely unhappy, about. Simple – or at least easily defined – is a key behaviour that you’re going to want built into the system. The Solidity project, for example, seems aware of at least some of these pitfalls, and suggests that people employing smart contracts employ formal verification, but as we’ll see below, that just scratches the surface of the problem.

Not contracts

Of course, there are some contracts – IRL contracts – that exist to manage complex and unexpected conditions. And they exist within a clear legal jurisdiction. The words and phrases that make them up are subject to specific and well-defined processes, with known sanctions and punishments where the conditions of the contract are not met or are broken. There are often instances where these are challenged, but again, clear mechanisms exist for such challenges.

For now, “smart contracts” just don’t fit this description of a contract. Just mapping legal contractual wording to computer code is a very complex process, and the types of errors to which processing of code is prone don’t have a good analogue within the justice system. There’s the question, as well, of what jurisdiction is relevant. This is usually described in the contract terms, but what if the processing of the “smart contract” takes place in a different jurisdiction to that of the parties involved, or even in an unknown jurisdiction. Should this matter? Could this matter? I don’t know, and I also don’t know what other types of issue are going to crawl out of the woodwork once people start relying on these constructs in legally-enforceable ways, but I doubt they’re going to be welcome.

We’re not helped, as well, by the fact that when IT people talk about software contracts, they’re talking about something completely different: it’s the advertised behaviour of a system in the context of known inputs and starting conditions.

What has this got to do with security?

Once a transaction – or “smart contract” has completed, and made its way onto the blockchain or distributed ledger, it is immutable, pretty much by definition. But what about before then? Well, simple transactions of the type described at the beginning of this post are atomic – they happen or they don’t, and they are “indivisible and irreducible” to use the jargon. They are, for most purposes, instantaneous.

The same is not true for “smart contracts”. They require processing, and therefore exist over time. This means that while they are being processed, they are subject to all the sorts of attacks to which any system may be vulnerable. The standard list is:

C = confidentiality. The state of a “smart contract” may be subject to snooping, which may lead to asymmetric knowledge or leakage to non-approved parties.
I = integrity. This is the nightmare case for many “smart contracts”. If an entity – whether a party to the underlying contract or not – can change the internal state of the code executing the “smart contract” intentionally or unintentionally, then the outcomes of that “smart contract” will not be as expected, and any of the parties involved may have good cause to dispute the outcome. What’s more, such a dispute may not even depend on proof of loss of integrity, but just on suspicion. Proving run-time integrity – let alone mitigating when it is shown to have been lost – is extremely difficult within an execution context.
A = availability. If one party sees that the conditions associated with a “smart contract” are turning out to be unfavourable to them, then they might try to affect the availability of any part of the system the makes up the “smart contract”, whether the processing of the code itself, the inputs to the system or the outputs from the system. Any of these might have a significant impact on the real-life outcomes.

So what?

This post started with what may have seemed to be a pedantic attack on a naming convention. As I think will probably be clear********, I’m not comfortable with the phrase “smart contract”, and that’s mainly because I think it has caused some people to think that these constructs are things that they’re not. This, in turn, is likely to mean that people will use them in contexts where they’re not appropriate.

I also worry that because the use of words means that they bring baggage with them, this will lead to people not fully thinking through the impact of security on these constructs. And I think that the impact can be very major. So, if you’re looking into these constructs, please do so with your eyes open. I’ve not talked much in this article about mitigations, but some exist: keep an eye on future posts for more.

*I like to think that the late, lamented authors Terry Pratchett and Douglas Adams would both appreciate smart contracts for exactly this reason.

**the first thing you’ll find many bitcoin commentators saying is “I wish I’d bought in early: I’d be a multi-millionaire by now.”***

***I wish I’d bought in early: I’d be a multi-millionaire by now.

****less taxes or house cut. Sorry – that’s just the way the world works.

*****or doesn’t.

******I’m not expecting one. I’d tell you, honest.

*******this is not an invitation.

********if it isn’t by now, either you’ve not read this carefully enough, or I’ve done a bad job of explaining. Try reading it again, and if that doesn’t help, write a comment and I’ll try to explain better.

大勢がレビューしていても信用しないという仮説

Writing code is hard. Writing secure code is harder: much harder. And before you get there, you need to think about design and architecture. When you’re writing code to implement security functionality, it’s often based on architectures and designs which have been pored over and examined in detail. They may even reflect standards which have gone through worldwide review processes and are generally considered perfect and unbreakable*.

However good those designs and architectures are, though, there’s something about putting things into actual software that’s, well, special. With the exception of software proven to be mathematically correct**, being able to write software which accurately implements the functionality you’re trying to realise is somewhere between a science and an art. This is no surprise to anyone who’s actually written any software, tried to debug software or divine software’s correctness by stepping through it. It’s not the key point of this post either, however.

Nobody*** actually believes that the software that comes out of this process is going to be perfect, but everybody agrees that software should be made as close to perfect and bug-free as possible. It is for this reason that code review is a core principle of software development. And luckily – in my view, at least – much of the code that we use these days in our day-to-day lives is Open Source, which means that anybody can look at it, and it’s available for tens or hundreds of thousands of eyes to review.

And herein lies the problem. There is a view that because Open Source Software is subject to review by many eyes, all the bugs will be ironed out of it. This is a myth. A dangerous myth. The problems with this view are at least twofold. The first is the “if you build it, they will come” fallacy. I remember when there was a list of all the websites in the world, and if you added your website to that list, people would visit it****. In the same way, the number of Open Source projects was (maybe) once so small that there was a good chance that people might look at and review your code. Those days are past – long past. Second, for many areas of security functionality – crypto primitives implementation is a good example – the number of suitably qualified eyes is low.

Don’t think that I am in any way suggesting that the problem is any lesser in proprietary code: quite the opposite. Not only are the designs and architectures in proprietary software often hidden from review, but you have fewer eyes available to look at the code, and the dangers of hierarchical pressure and groupthink are dramatically increased. “Proprietary code is more secure” is less myth, more fake news. I completely understand why companies like to keep their security software secret – and I’m afraid that the “it’s to protect our intellectual property” line is too often a platitude they tell themselves, when really, it’s just unsafe to release it. So for me, it’s Open Source all the way when we’re looking at security software.

So, what can we do? Well, companies and other organisations that care about security functionality can – and have, I believe a responsibility to – expend resources on checking and reviewing the code that implements that functionality. That is part of what Red Hat, the organisation for whom I work, is committed to doing. Alongside that, we, the Open Source community, can – and are – finding ways to support critical projects and improve the amount of review that goes into that code*****. And we should encourage academic organisations to train students in the black art of security software writing and review, not to mention highlighting the importance of Open Source Software.

We can do better – and we are doing better. Because what we need to realise is that the reason the “many eyes hypothesis” is a myth is not that many eyes won’t improve code – they will – but that we don’t have enough expert eyes looking. Yet.

* Yeah, really: “perfect and unbreakable”. Let’s just pretend that’s true for the purposes of this discussion.

** …and which still relies on the design and architecture actually to do what you want – or think you want – of course, so good luck.

*** nobody who’s actually written more than about 5 lines of code (or more than 6 characters of Perl)

**** I added one. They came. It was like some sort of magic.

***** see, for instance, the Linux Foundation‘s Core Infrastructure Initiative

Tag: code

What’s a blockchain “smart contract”?