What’s a blockchain “smart contract”? 

The first thing to know about blockchain smart contracts is they’re not contracts, smart or necessarily on a blockchain.

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 hte 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.

 

 

Blockchain: should we all play?

Don’t increase the technical complexity of a process just because you’ve got a cool technology that you could throw at it.

I’m attending Open Source Summit 2017* this week in L.A., and went to an interesting “fireside chat” on blockchain moderated by Brian Behlendforf of Hyperledger, with Jairo*** of Wipro and Siva Kannan of Gem.  It was a good discussion – fairly basic in terms of the technical side, and some discussion of identity in blockchain – but there was one particular part of the session that I found interesting and which I thought was worth some further thought.  As in my previous post on this topic, I’m going to conflate blockchain with Distributed Ledger Technologies (DLTs) for simplicity.

Siva presented three questions to ask when considering whether a process is a good candidate for moving to the blockchain.  There’s far too much bandwagon-jumping around blockchain: people assume that all processes should be blockchained.  I was therefore very pleased to see this come up as a topic.  I think it’s important to spend some time looking at when it makes sense to use blockchains, and when it’s not.  To paraphrase Siva’s points:

  1. is the process time-consuming?
  2. is the process multi-partite, made up of multiple steps?
  3. is there a trust problem within the process?

I liked these as a starting point, and I was glad that there was a good conversation around what a trust problem might mean.  I’m not quite sure it went far enough, but there was time pressure, and it wasn’t the main thrust of the conversation.  Let’s spend a time looking at why I think the points above are helpful as tests, and then I’m going to add another.

Is the process time-consuming?

The examples that were presented were two of the classic ones used when we’re talking about blockchain: inter-bank transfer reconciliation and healthcare payments.  In both cases, there are multiple parties involved, and the time it takes for completion seems completely insane for those of us used to automated processes: in the order of days.  This is largely because the processes are run by central authorities when, from the point of view of the process itself, the transactions are actually between specific parties, and don’t need to be executed by those authorities, as long as everybody trusts that the transactions have been performed fairly.  More about the trust part below.

Is the process multi-partite?

If the process is simple, and requires a single step or transaction, there’s very little point in applying blockchain technologies to it.  The general expectation for multi-partite processes is that they involve multiple parties, as well as multiple parts.  If there are only a few steps in a transaction, or very few parties involved, then there are probably easier technological solutions for it.  Don’t increase the technical complexity of a process just because you’ve got a cool technology that you can throw at it******.

Is there a trust problem within the process?

Above, I used the phrase “as long as everybody trusts that the transactions have been performed fairly”******.  There are three interesting words in this phrase*******: “everybody”, “trusts” and “fairly”.  I’m going to go through them one by one:

  • everybody: this might imply full transparency of all transactions to all actors in the system, but we don’t need to assume that – that’s part of the point of permissioned blockchains.  It may be that only the actors involved in the particular process can see the details, whereas all other actors are happy that they have been completed correctly.  In fact, we don’t even need to assume that the actors involved can see all the details: secure multi-party computation means that only restricted amounts of information need to be exposed********.
  • trusts: I’ve posted on the topic of trust before, and this usage is a little less tight than I’d usually like.  However, the main point is to ensure sufficient belief that the process meets expectations to be able to accept it.
  • fair: as anyone with children knows, this is a loaded word.  In this context, I mean “according to the rules agreed by the parties involved – which may include parties not included in the transaction, such as a regulatory body – and encoded into the process”.

This point about encoding rules into a process is a really, really major one, to which I intend to return at a later date, but for now let’s assume (somewhat naively, admittedly) that this is doable and risk-free.

One more rule: is there benefit to all the stakeholders?

This was a rule that I suggested, and which caused some discussion.  It seems to me that there are some processes where a move to a blockchain may benefit certain parties, but not others.  For example, the amount of additional work required by a small supplier of parts to a large automotive manufacturer might be such that there’s no obvious benefit to the supplier, however much benefit is manifestly applicable to the manufacturer.  At least one of the panellists was strongly of the view that there will always be benefit to all parties, but I’m not convinced that the impact of implementation will always outweight such benefit.

Conclusion: blockchain is cool, but…

… it’s not a perfect fit for every process.  Organisations – and collections of organisations – should always carefully consider how good a fit blockchain or DLT may be before jumping to a decision which may be more costly and less effective than they might expect from the hype.


*was “LinuxCon and ContainerCon”**.

**was “LinuxCon”.

***he has a surname, but I didn’t capture it in my notes****.

****yes, I write notes!

*****this is sometime referred to as the “hammer problem” (if all you’ve got is a hammer, then everything looks like a nail)

******actually, I didn’t: I missed out the second “as”, and so had to correct it in the first appearance of the phrase.

*******in the context of this post.  They’re all interesting in the own way, I know.

********this may sound like magic.  Given my grasp of the mathematics involved, I have to admit that it might as well be*********.

*********thank you Arthur C. Clarke.

Is blockchain a security topic?

… we need to understand how systems and the business work together …

Blockchains are big news at the moment.  There are conferences, start-ups, exhibitions, open source projects (in fact, pretty much all of the blockchain stuff going on out there is open source – look at Ethereum, zcash and bitcoin as examples) – all we need now are hipster-run blockchain-themed cafés*.  If you’re looking for an initial overview, you could do worse than the Wikipedia entry – that’s not the aim of this post.

Before we go much further, one useful thing to know about many blockchains projects is that they aren’t.  Blockchains, that is.  They are, more accurately, distributed ledgers****.  For now, however, let’s roll in blockchain and distributed ledger technologies and assume we’re talking about the same thing: it’ll make it easier for now, and in most cases, the difference is immaterial for our discussions.

I’m not planning to go into the basics here, but we should briefly talk about the main link with crypto and blockchains, and that’s the blocks themselves. In order to build a block, a set of transactions to put into a blockchain, and then to link it into the blockchain, cryptographic hashes are used.   This is the most obvious relationship that the various blockchains have with cryptography.

There’s another, equally important one, however, which is about identity*****.  Now, for many blockchain-based crypto-currencies, a major part of the point of using them at all is that identity isn’t, at one level, important.  There are many actors in a crypto-currency who may be passing each other vanishingly small or eye-wateringly big amounts of money, and they don’t need to know who each other is in order to make transactions.  To be more clear, the uniqueness of each actor absolutely is important – I want to be sure that I’m sending money to the entity who has just rendered me a service – but being able to tie that unique identity to a particular person IRL****** is not required.  To use the technical term, such a system is pseudonymous.  Now, if pseudonymity is a key part of the system, then protecting that property is likely to be important to its users.  Crypto-currencies do this with various degrees of success.  The lesson here is that you should do some serious reading and research if you’re planning to use a crypto-currency, and this property matters to you.

On the other hand, there are many blockchain/distributed ledger technologies where pseudonymity is not a required property, and may actually be unwanted.  These are the types of system in which I am most generally interested from a professional point of view.

In particular, I’m interested in permissioned blockchains.  Permissionless (or non-permissioned) blockchains are those where you don’t need permission from anyone in order to participate.  You can see why pseudonimity and permissionless blockchains can fit well today: most (all?) crypto-currencies are permissionless.  Permissioned blockchains are a different kettle of fish, however, and they’re the ones at which many businesses are looking at the moment.  In these cases, you know the people or entities who are going to be participating – or, if you don’t know now, you’ll want to check on them and their identity before they join your blockchain (or distributed ledger).  And here’s why blockchains are interesting in business********.  It’s not just that identity is interesting, though it is, because how you marry a particular entity to an identity and make sure that this binding is not spoofable over the lifetime of the system is difficult, difficult, lemon difficult******** – but there’s more to it than that.

What’s really interesting is that if you’re thinking about moving to a permissioned blockchain or distributed ledger with permissioned actors, then you’re going to have to spend some time thinking about trust.  You’re unlikely to be using a proof-of-work system for making blocks – there’s little point in a permissioned system – so who decides what comprises as “valid” block, that the rest of the system should agree on?  Well, you can rotate around some (or all) of the entities, or you can have a random choice, or you can elect a small number of über-trusted entities.  Combinations of these schemes may also work.  If these entities all exist within one trust domain, which you control, then fine, but what if they’re distributors, or customers, or partners, or other banks, or manufacturers, or semi-autonomous drones, or vehicles in a commercial fleet?  You really need to ensure that the trust relationships that you’re encoding into your implementation/deployment truly reflect the legal and IRL trust relationships that you have with the entities which are being represented in your system.

And the problem is that once you’ve deployed that system, it’s likely to be very difficult to backtrack, adjust or reset the trust relationships that you’ve designed in.  And if you don’t think about the questions I noted above about long-term bindings of identity, you’re going to be in some serious problems when, for instance:

  • an entity is spoofed;
  • an entity goes bankrupt;
  • an entity is acquired by another entity (buy-outs, acquisitions, mergers, etc.);
  • an entity moves into a different jurisdiction;
  • legislation or regulation changes.

These are all issues that are well catered for within existing legal frameworks (with the possible exception of the first), but which are more difficult to manage within the sorts of systems with which we are generally concerned in this blog.

Please don’t confuse the issues noted above with the questions around how to map legal agreements to the so-called “smart contracts” in blockchain/distributed ledger systems.  That’s another thorny (and, to be honest, not unconnected issue), but this one goes right to the heart of what a system is, and it’s the reason that people need to think very hard about what they’re really trying to achieve when they adopt our latest buzz-word technology.  Yet again, we need to understand how systems and the business work together, and be honest about the fit.

 


*if you come across one of these, please let me know.  Put a picture in a comment or something.**

**even better – start one yourself. Make sure I get an invitation to the opening***.

***and free everything.

****there have been onlines spats about this.  I’m not joining in.

*****there are others, but I’ll save those for another day.

******IRL == “In Real Life”.  I’m so old-skool.

*******for me.  If you’ve got this far into the article, I’m hoping there’s an evens chance that the same will go for you, too.

********I’ll leave this as an exercise for the reader.  Watch it, though, and the TV series on which it’s based.  Unless you don’t like swearing, in which case don’t watch either.