Category: blockchain

Web3 plus Confidential Computing

Technologies, when combined, sometimes yield fascinating – and commercially exciting – results.

Mike Bursell

Sponsored by Super Protocol

Introduction

One of the things that I enjoy the most is taking two different technologies, accelerating them at speed and seeing what comes out when they hit, rather in the style of a particle physicist with a Large Hadron Collider.  Technologies which may not seem to be obvious fits for each other, when combined, sometimes yield fascinating – and commercially exciting – results, and the idea of putting Web3 and Confidential Computing together is certainly one of those occasions.  Like most great ideas, once someone explained it to me, it was a “oh, well, of course that’s going to make sense!” moment, and I’m hoping that this article, which attempts to explain the combination of the two technologies, will give you the same reaction.  I’ll start with an introduction to the two technologies separately, why they are interesting from a business context, and then look at what happens when you put them together.  We’ll finish with more of a description of a particular implementation: that of Super Protocol, using the Polygon blockchain.

Business context

Introduction to the technologies 

In this section, we look at blockchain in general and Web3 in particular, followed by a description of the key aspects of Confidential Computing.  If you’re already an expert in either of these technologies, feel free to skip these, of course.

Blockchain

Blockchains offer a way for groups of people to agree about the truth of key aspects of the world.  They let people say: “the information that is part of that blockchain is locked in, and we – the other people who use it and I – believe that is correct and represents a true version of certain facts.”  This is a powerful capability, but how does it arise?  The key point about a blockchain is that it is immutable.  More specifically, anything that is placed on the blockchain can’t be changed without such a change being obvious to anybody with access to it.  And another key point about many blockchains is that they are public – that is, anybody with access to the Internet and the relevant software is able to access them.  Such blockchains are sometimes called “permissionless”, in juxtaposition to blockchains to which only authorised entities have access, which are known as “permissioned”.  In both cases, the act of putting something on a blockchain is very important – if we want to view blockchains as providing a source of truth about the world – then the ability to put something onto the blockchain is a power that comes with great responsibility.  The various consensus mechanisms employed vary between implementations but all of them aim for consensus among the parties that are placing their trust in the blockchain, a consensus that what is being represented is correct and valid.  Once such a consensus has been met a cryptographic hash is used to seal the latest information and anchor it to previous parts of the blockchain, adding a new block to it.

While this provides enough for some use cases, the addition of smart contracts provides a new dimension of capabilities.  I’ve noted before that smart contracts aren’t very well named (they’re arguably neither smart nor contracts!), but what they basically allow is for programs and their results to be put on a blockchain.  If I create a smart contract and there’s consensus that it allows deterministic results from known inputs, and it’s put onto the blockchain, then that means that when it’s run, if people can see the inputs – and be assured that the contract was run correctly, a point to which we’ll be returning later in this article – then they will happy to put the results of that smart contract on the blockchain.  What we’ve just created is a way to create data that is known to be correct and valid, and which we can be happy to put directly on the blockchain without further checking: the blockchain can basically add results to itself!

Web3

    Blockchains and smart contracts, on their own, are little more than a diverting combination of cryptography and computing: it’s the use cases that make things interesting.  The first use case that everyone thinks of is crypto-currency, the use of blockchains to create wholly electronic currencies that can be (but don’t have) divorced from centralised government-backed banking systems.  (Parenthetically, the fact that the field of use and study of these crypto-currencies has become known to its enthusiasts as “crypto” drives most experts in the much older and more academic field of cryptology wild.)

    There are other uses of blockchains and smart contracts, however, and the one which occupies our attention here is Web3.  I’m old (I’m not going to give a precise age, but let’s say early-to-mid Gen X, shall we?), so I cut my professional teeth on the technologies that make up what are now known as Web1. Web1 was the world of people running their own websites with fairly simple static pages and CGI interactions with online databases.  Web2 came next and revolves around centralised platforms – often cloud-based – and user-generated data, typically processed and manipulated by large organisations.  While data and information may be generated by users, it’s typically sucked into the platforms owned by these large organisations (banks, social media companies, governments, etc.), and passes almost entirely out of user control.  Web3 is the next iteration, and the big change is that it’s a move to decentralised services, transparency and user control of data.  Web3 is about open protocols – data and information isn’t owned by those processing it: Web3 provides a language of communication and says “let’s start here”.  And Web3 would be impossible without the use of blockchains and smart contracts.

    Confidential Computing

    Confidential Computing is a set of technologies that arose in the mid 2010s, originally to address a number of the problems that people started to realise were associated with cloud computing and Web2.  As organisations moved their applications to the cloud, it followed that the data they were processing also moved there, and this caused issues.  It’s probably safe to say that the first concerns that surfaced were around the organisations’ own data.  Keeping financial data, intellectual property, cryptographic keys and the like safe from prying eyes on servers operated in clouds owned and managed by completely different companies, sometimes in completely different jurisdictions, started to become a worry.  But that worry was compounded by the rising tide of regulation being enacted to protect the data not of the organisations, but of the customers who they (supposedly) served.  This, and the growing reputational damage associated with the loss of private data, required technologies that would allow the safeguarding of sensitive data and applications from the cloud service providers and, in some cases, from the organisations who “owned” – or at least processed – that data themselves.

    Confidential Computing requires two main elements.  The first is a hardware-based Trusted Execution Environment (TEE): a set of capabilities on a chip (typically a CPU or GPU at this point) that can isolate applications and their data from the rest of the system running them, including administrators, the operating system and even the lowest levels of the computer, the kernel itself.  Even someone with physical access to the machine cannot overcome the protection that a TEE provides, except in truly exceptional circumstances.  The second element is remote attestation.  It’s all very well setting up a TEE on a system in, say, a public cloud, but how can you know that it’s actually in place or even that the application you wanted to load into it is the one that’s actually running?  Remote attestation addresses this problem in a multi-step process.  There are a number of ways to manage this, but the basic idea is that the application in the TEE asks the CPU (which understands how this works) to create a measurement of some or all of the memory in the TEE.  The CPU does this, and signs this with a cryptographic key, creating an attestation measurement.  This measurement is then passed to a different system (hence “remote”), which checks it to see if it conforms to the expectations of the party (or parties) running the application and, if it does, provides a verification confirms that all is well.  This basically allows a certificate to be created that attests to the correctness of the CPU, the validity of the TEE’s configuration and the state of any applications or data within the TEE.

    With these elements – TEEs and remote attestation – in place, organisations can use Confidential Computing to prove to themselves, their regulators and their customers that no unauthorised peeking or tampering is possible with those sensitive applications and data that need to be protected.

    Combining blockchain & CC

    One thing – possibly the key thing – about Web3 is that it’s decentralised.  That means that anyone can offer to provide services and, most importantly, computing services, to anybody else.  This means that you don’t need to go to one of the big (and expensive) cloud service providers to run your application – you can run a DApp (Decentralised Application) – or a standard application such as a simple container image – on the hardware of anyone willing to host it.  The question, of course, is whether you can trust them with your application and your data; and the answer, of course in many, if not most, use cases, is “no”.  Cloud service providers may not be entirely worthy of organisations’ trust – hence the need for Confidential Computing – but at least they are publicly identifiable, have reputations and are both shameable and suable.  It’s very difficult to say the same about in a Web3 world about a provider of computing resources who may be anonymous or pseudonymous and with whom you have never had any interactions before – nor are likely to have any in the future.  And while there is sometimes scepticism about whether independent actors can create complex computational infrastructure, we only need look at the example of Bitcoin and other cryptocurrency miners, who have built computational resources which rival those of even the largest cloud providers. 

    Luckily for Web3, it turns out that Confidential Computing, while designed primarily for Web2, has just the properties needed to allow us to build systems that do allow us to do Web3 computing with confidence (I’ll walk through some of the key elements of one such implementation – by Super Protocol – below).  TEEs allow DApps to be isolated from the underlying hardware and system software and remote attestation can provide assurances to clients that everything has been set up correctly (and a number of other properties besides).  

    Open source

    There is one important characteristic that Web3 and Confidential Computing share that is required to ensure the security and transparency that is a key to a system that combines them: open source software.  Where software is proprietary and closed from scrutiny (this is the closed from which open source is differentiated), the development of trust in the various components and how they interact is impossible.  Where proprietary software might allow trust in a closed system of actors and clients who already have trust with each other – or external mechanisms to establish it – the same is not true in a system such as Web3 whose very decentralised nature doesn’t allow for such centralised authorities.

    Open source software is not automatically or by its very nature more secure than proprietary software – it is written by humans, after all (for now!), and  – but its openness and availability to scrutiny means that experts can examine it, check it and, where necessary, fix it.  This allows the open source community and those that interact with it to establish that it is worthy of trust in particular contexts and use cases (see Chapter 9: Open Source and Trust in my book for more details of how this can work).  Confidential Computing – using TEEs and remote attestation – can provide cryptographic assurances not only the elements of a Web3 system are valid and have appropriate security properties, but also that the components of the TEE itself do as well.

    Some readers may have noted the apparent circularity in this set-up – there are actually two trust relationships that are required for Confidential Computing to work: in the chip manufacturer and in the attestation verification service.  The first of these is unavoidable with current systems, while the other can be managed in part by performing the attestation oneself. It turns out that allowing the creation of trust relationships between mutually un-trusting parties is extremely complex, but one way that this can be done is what we will now address.

    Super Protocol’s approach

    Super Protocol have created a system which uses Confidential Computing to allow execution of complex applications to be made within a smart contract on the blockchain and for all the parties in the transaction to have appropriate trust in the performance and result of that execution without having to know or trust each other.  The key layers are:

    • Client Infrastructure, allowing a client to interact with the blockchain, initiate an instance and interact with it
    • Blockchain, including smart contracts 
    • Various providers (TEE, Data, Solution, Storage).

    Central to Super Protocol’s approach are two aspects of the system: that it is open source, and that remote attestation is required to allow the client to have sufficient assurance of the system’s security.  Smart contracts – themselves open source – allow the resources made available by the various actors and combined into an offer that is placed on the blockchain and is available to anyone with access to the blockchain – to execute it, given sufficient resources from all involved.  What makes this approach a Web3 approach, and differentiates it from a more Web2 system, is that none of these actors needs to be connected contractually.

    Benefits of This Approach

    How does this approach help?  Well, you don’t need to store or process data (which may be sensitive or just very large) locally: TEEs can handle it, providing confidentiality and integrity assurances that would otherwise be impossible.  And communications between the various applications are also encrypted transparently, reducing or removing risks of data leakage and exposure, without requiring complex key management by users, but keeping the flexibility and exposure offered by decentralisation and Confidential Computing.

    But the step change that this opens up is the network effect enabled by the possibility of building huge numbers of interconnected Web3 agents and applications, operating with the benefits of integrity and confidentiality offered by Confidential Computing, and backed up by remote attestation.  One of the recurring criticisms of Web2 ecosystems is their fragility and lack of flexibility (not to mention the problems of securing them in the first place): here we have an opportunity to create complex, flexible and robust ecosystems where decentralised agents and applications can collaborate, with privacy controls designed in and clearly defined security assurances and policies.

    Technical details

    In this section, I dig a little further into some of the technical details of Super Protocol’s system. It is, of course, not the only approach to combining Confidential Computing and Web3, but it is available right now, seems carefully architected and designed with security foremost in mind and provides a good example of the technologies and the complexities involved.  

    You can think of Super Protocol’s service as being in two main parts: on-chain and off-chain. The marketplace, with smart contract offers, sits on an Ethereum blockchain, and the client interacts with that, never needing to know the details of how and where their application instance is running. The actual running applications are off-chain, supported by other infrastructure to allow initial configuration and then communication services between clients and running applications.  The “bridge” between the two parts, which moves from an offer to an actual running instance of the application, is a component called a Trusted Loader, which sets up the various parts of the application and sets it running.  The data it is managing contains sensitive information such as cryptographic keys which need to be protected as they provide security for all the other parts of the system and the Trusted Loader also manages the important actions of hash verification (ensuring that what is being loaded what was originally offered) and order integrity (ensuring that no changes can be made whilst the loading is taking place and execution starting).

    Trusted Loader – configuration and deployment with Data and Application information into TEE instance

    But what is actually running?  The answer is that the unit of execution for an application in this service is a Kubernetes Pod, so each application is basically a container image which is run within a Pod, which itself executes within a TEE, isolating it from any unauthorised access. This Pod itself is – of course! – measured, creating an attestation measurement that can now be verified by clients of the application. We should also remember that the application itself – the container image – needs protection as well. This is part of the job of the Trusted Loader, as the container image is stored encrypted, and the Trusted Loader has appropriate keys to decrypt this and other resources required to allow execution.  This is not the only thing that the Trusted Loader does: it also gathers and sets up resources from the smart contract for networking and storage, putting everything together, setting it running and connecting the client to the running instance.

    There isn’t space in this article to go into deeper detail of how the system works, but by combining the capabilities offered by Confidential Computing and a system of cryptographic keys and certificates, the overall system enforces a variety of properties that are vital for sensitive, distributed and decentralised Web3 applications.

    • Decentralised storage: secrets are kept in multiple places instead of one, making them harder to access, steal or leak.
    • Developer independence: creators of applications can’t access these secrets, continuing the lack of need for trust relationships between the various actors.  In other words, each instance of an application is isolated from its creator, maintaining data confidentiality.
    • Unique secrets: Each application gets its own unique secrets that nobody else can use or see and which are not shared between instances.

    Thanks

    Thanks to Super Protocol for sponsoring this article.  Although they made suggestions and provided assistance around the technical details, this article represents my views, the text is mine and final editorial control (and with it the blame for any mistakes!) rests with the author.

    Photo by Rukma Pratista on Unsplash

    3 tests for NOT moving to blockchain 

    How to tell when you can avoid the hype.

    So, there’s this thing called “blockchain” which is quite popular…

    You know that already, of course.  I keep wondering if we’ve hit “peak hype” for blockchain and related technologies yet, but so far there’s no sign of it.  As usual for this blog, when I’m talking about blockchain, I’m going to include DLTs – Distributed Ledger Technologies – which are, by some tight definitions of the term, not really blockchains at all.  I’m particularly interested, from a professional point of view, in permissioned blockchains.  You can read more about how that’s defined in my previous post Is blockchain a security topic? – the key point here is that I’m interested in business applications of blockchain beyond cryptocurrency[1].

    And, if the hype is to be believed – and some of it probably should be[2] – then there is an almost infinite set of applications for blockchain.  That’s probably correct, but that doesn’t mean that they’re all good applications for blockchain.  Some, in fact, are likely to be very bad applications for blockchain.

    The hype associated with blockchain, however, means that businesses are rushing to embrace this new technology[3] without really understanding what they’re doing.  The drivers towards this move are arguably three-fold:

    1. you can, if you try, make almost any application with multiple users which stores data into a blockchain-enable application;
    2. there are lots of conferences and “gurus” telling people that if they don’t embrace blockchain now, they’ll go out of business within six months[4];
    3. it’s not easy technology to understand fully, and lots of the proponents “on-the-ground” within organisations are techies.

    I want to unpack that last statement before I get a hail of trolls flaming me[5].  I have nothing against techies – I’m one myself – but one of our characteristics tends to be enormous enthusiasm about new things (“shinies”) that we understand, but whose impact on the business we don’t always fully grok[6]. That’s not always a positive for business leaders.

    The danger, then, is that the confluence of those three drivers may lead to businesses deciding to start moving to blockchain applications without fully understanding whether that’s a good idea.  I wrote in another previous post (Blockchain: should we all play?) about some tests that you can apply to decide whether a process is a good fit for blockchain and when it’s not.  They were useful, but the more I think about it, the more I’m convinced that we need some simple tests to tell us when we should definitely not move a process or an application to a blockchain.  I present my three tests.  If your answer any of these questions is “yes”, then you almost certainly don’t need a blockchain.

    Test 1 – does it have a centralised controller or authority?

    If the answer is “yes”, then you don’t need a blockchain.

    If, for instance, you’re selling, I don’t know, futons, and you have a single ordering system, then you have single authority for deciding when to send out a futon.  You almost certainly don’t need to make this a blockchain.  If you are a purveyor of content that has to pass through a single editorial and publishing process, they you almost certainly don’t need to make this a blockchain.

    The lesson is: blockchains really don’t make sense unless the tasks required in the process execution – and the trust associated with those tasks – is distributed between multiple entities.

    Test 2 – could it work fine with a standard database?

    If the answer to this question is “yes”, then you don’t need a blockchain.

    This question and the previous one are somewhat intertwined, but don’t need to be.  There are applications where you have distributed processes, but need to store information centrally, or centralised authorities but distributed data, where one may be yes, but the other “no”.  But if this is question is a “yes”, then use a standard database.

    Databases are good at what they do, they are cheaper in terms of design and operation than running a blockchain or distributed ledger, and we know how to make them work.  Blockchains are about letting everybody[8] see and hold data, but the overheads can be high, and the implications costly.

    Test 3 – is adoption going to be costly, or annoying, to some stakeholders?

    If the answer to this question is “yes”, then you don’t need a blockchain.

    I’ve heard assertions that blockchains always benefit all users.  This is a patently false.  If you are creating an application for a process, and changing the way that your stakeholders interact with you and it, you need to consider whether that change is in their best interests.  It’s very easy to create and introduce an application, blockchain or not, which reduces business friction for the owner of the process, but increases it for other stakeholders.

    If I make engine parts for the automotive industry, it may benefit me immensely to be able to track and manage the parts on a blockchain.  I may be able to see at a glance who’s supplied what, when, and the quality of the steel used in the ball-bearings.  On the other hand, if I’m a ball-bearing producer, and I have an established process which works for the forty companies to whom I sell ball-bearings, then adopting a new process for just one of them, with associated changes to my method of work, new systems and new storage and security requirements is unlikely to be in my best interests: it’s going to be both costly and annoying.

    Conclusion

    Tests are guidelines: they’re not fixed in stone.  One of these tests looks like a technical test (the database one), but is really as much about business roles and responsibilities as the other two.  All of them, hopefully, can be used as a counter-balance to the three drivers I mentioned.

     

    1 – which, don’t get me wrong, is definitely interesting and a business application – it’s just not what I’m going to talk about in this post.

    2 – the trick is knowing which bits.  Let me know if you work out how, OK?

    3 – it’s actually quite a large set of technologies, to be honest.

    4 – which is patently untrue, unless the word “they” refers there to the conferences and gurus, in which case it’s probably correct.

    5 – which may happen anyway due to my egregious mixing of metaphors.

    6 – there’s a word to love.  I’ve put it in to exhibit my techie credentials[7].

    7 – and before you doubt them, yes, I’ve read the book, in both cut and uncut versions.

    8 – within reason.

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

     

     

    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.