Is blockchain a security topic?

Yet again, we need to understand how systems and the business work together and be honest about the fit.
865 readers like this.
How OpenChain can transform the supply chain

Internet Archive Book Images. Modified by CC BY-SA 4.0

Blockchains are big news at the moment. There are conferences, startups, 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.1 If you're looking for an initial overview, you could do worse than the Wikipedia entry—but that's not the aim of this post.

Before we go much further, one useful thing to know about many blockchain projects is that they aren't. Blockchains, that is. They are, more accurately, distributed ledgers.4 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 discussion.

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. To build a block—a set of transactions to put into a blockchain—and then 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.5 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 cryptocurrency who may be passing each other vanishingly small or eye-wateringly big amounts of money, and they don't need to know each other's identity in order to make transactions.

To be clearer, 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 IRL6 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. Cryptocurrencies 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 cryptocurrency 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 systems 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 pseudonymity and permissionless blockchains can fit well today: most (all?) cryptocurrencies are permissionless. Permissioned blockchains are a different kettle of fish, however, and they're the ones many businesses are looking at now. 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.7 It's not just that identity is interesting, although 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 difficult8—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 a "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 that 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. And if you don't think about the questions I noted above, about long-term bindings of identity, you're going to be in for some serious problems when, for instance:

  • an entity is spoofed
  • an entity goes bankrupt
  • an entity is acquired by another entity (buyouts, acquisitions, mergers, etc.)
  • an entity moves into a different jurisdiction
  • a 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 that are more difficult to manage within the sorts of systems we are generally concerned with in this article.

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 the latest buzzword technology. Yet again, we need to understand how systems and the business work together and be honest about the fit.

1 If you come across one of these, please let me know. Put a picture in a comment or something.2

2 Even better—start one yourself. Make sure I get an invitation to the opening.3

3 And free everything.

4 There have been online spats about this. I'm not joining in.

5 There are others, but I'll save those for another day.

6 IRL = "in real life." I'm so old-skool.

7 For me. If you've got this far into the article, I'm hoping there's an even chance that the same will go for you, too.

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

This article originally appeared on Alice, Eve, and Bob—a security blog and is republished with permission.

User profile image.
I've been in and around Open Source since around 1997, and have been running (GNU) Linux as my main desktop at home and work since then: not always easy...  I'm a security bod and architect, co-founder of the Enarx project, and am currently CEO of a start-up in the


I'm going to start off with a bold statement: If your use case is permissioned, then _a blockchain of the type you describe is the wrong tool, Proof of Work or not._

Satoshi Nakamoto's whitepaper was brilliant because it squared a longstanding circle: Distributed consensus on asynchronous networks in the permissionless setting.

Distributed consensus for synchronous and semi-synchronous networks in the permissioned setting had long since been solved - Paxos, Raft, and many others occupy this space. Some of them - such as Byzantine Paxos - offer _strictly_ stronger resilience guarantees than Nakamoto's system.

More recently, asynchronous networks have also been addressed, with Andrew Miller's Honey Badger BFT protocol standing out[1][2]

As a result, the space of "distributed consensus in the _permissioned_ setting" is spoiled for choice - and moreover, _these choices have much better properties than you describe_.

You describe a protocol system where you _have_ to choose some actor, and once the choice is made, you're stuck with the consequences of what they add. In short: Elect a dictator who can only make one law before the next election.

However, all of the protocols I describe are _proper consensus protocols_ - in order for a transition to be valid (that is "a block added to the chain", though that is merely _one representation_ one might choose), a quorum of participants must agree. Here, the group validates the _change, voting on the law directly rather than choosing a dictator. Once an entry is added to the ledger, it is well and truly valid - immediately.

The winner-take-all nature of Nakamoto-style blockchains forces a much _weaker_ notion of consistency - one in which the newest blocks of the chain are only provisionally valid, and confidence in them grows as they are buried under their successors. _This is not necessary in the permissioned setting_.

Virtually all of the concerns you raise, however, are _deeply predicated_ upon exactly this flawed model - a model that gives rise to trust issues, inefficiency, and uncertainty about exactly when a change is durable. Replacing it with a better model is a far cleaner solution than agonizing about choices that shouldn't have to be made.

As a further note, using a Merkelized linked list (i.e. blockchain) is in and of itself a _suboptimal representation_ for the ledger - research on secure logging has given better structures, which resist attacks (such as truncation) that a Merkelized linked list cannot, and support vastly more efficient verification and take vastly less space.[3]


Mike, very good article. You are very right that for permissioned blockchain to be successful you have to do your homework up front regarding trust. I have written supplier and distribute ageements in my global activities, and the details of potential changes in the parties must be carefully considered.

On a smaller note, I think one word in the article might be wrong (my be wrong myself though). Notice the sentence "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)." I think you meant "know" and not "now".

I have written an article on Blockchain too and am looking for typos all the time.

Thanks, Ron. Taking the approach of written agreements makes a lot os sense, and sounds like a good way of forcing people to consider what changes may be occurring.

To your second point, I _did_ mean to use "now" alongside "know". The sense I intended was "if you don't know at this moment in time, then...". Hope this is helpful.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Find the perfect open source tool

Project management, business intelligence, reporting, and more. Check these popular projects.