In all the blockchain hype, a simple, yet self-refuting idea
keeps popping up: a Private Blockchain.
This post originally appeared on my blog
In order to understand why a private blockchain is nonsense, we must
first define what a block chain is and what it is not. Since Nakamoto
coined (PDF) the term, lets see if
his description helps:
a peer-to-peer distributed timestamp server to generate computational
proof of the chronological order of transactions
It does highlight some important traits of "a block chain" (Nakamoto
used a space between both words, I use the current popular term
blockchain):
- peer-to-peer: implying distribution; at least ruling out a central
authority - computational proof: implying it to be verifiable
- timestamp-server/chronological ordering: it's goal, but also implying
permanence
Marco Iansiti and Karim R Lakhani have a more accessible explanation:
an open, distributed ledger that can record transactions between two
parties efficiently and in a verifiable and permanent way.
- open (often called permissionless)
- distributed (often called decentralized)
- verifiable
- permanent (often called immutable)
In other words: anything that does not match those criteria, is by
definition, not a blockchain. It may be something similar, or even
something using similar techniques, but not a blockchain. This is
important.
We can also look at it from the other side: if a blockchain offers these
traits, when do we need a blockchain?:
(I downloaded this image years ago and forgot to note the author.
Sorry.)
This has the same treats, but turns the argument around: if your
requirements don't fit the exact things that blockchain offer: you don't
need a blockchain. In the case of a private blockchain: if it is not
public, you don't need a blockchain. We could stop here.
Reasons for wanting a private blockchain
So, why do people come up with private blockchains in the first place? We can group the arguments into three main arguments. I'll add a fourth.
- So we can store private data or other kinds of data that should not
be public. (We scrap the open and verifiable parts for privacy) - So we can control who has read/write access (We scrap the open
part for control) - So we can scale better (We scrap the distributed part for speed).
- Because we are not yet confident enough about the security and exact
traits to release on a public platform (We scrap the permanent part
for flexibility)
The fourth is the only valid argument to ever use a private blockchain:
as a temporary phase because you are still developing and finding out
the ins- and outs of your blockchain-application: very similar to how
you first release an app to your five friends and not upload it
immediately to an app store.
All others reasons are pure nonsense, because they don't need a
blockchain to get the exact same outcome. Or because by definition,
deploying that way, makes it not a blockchain. One could say, that by
deploying a blockchain in a private environment, it stops being a
blockchain.
But, there is more than just a play of words. Keep tuned.
Private data: public.
A blockchain has to be public in order to ensure permanence or
immutability.
Let's compare a blockchain to a household book. When I have such a book,
in a drawer in my office, I'm the only one who can read it and change
it.
So, when for some reason I bought a pair of expensive shoes, and a week
later want to hide that fact, I can simply remove that line from the
book. Or overwrite it with "pair of scissors". And boom. I never bought
shoes (according to the book).
But if that book is accessible amongst family members, for everyone to
review, or copy, it becomes a little more "immutable". I can still
remove the "expensive shoes" line, but people might know, and
family-members can call me out on it. With even more people who can
access the book (why not mail a weekly copy to all family and friends?)
the harder it becomes to change stuff afterwards.
A blockchain, however, has an additional trait: through
applied cryptography, it allows one to easily detect when a line is
changed. So all people who have a copy can detect with certainty and
easily that something has been changed that should not have been
changed. But this trait is only useful if other stakeholders can get
copies. In a private blockchain it is really easy to change something,
even when that change has a big, clearly visible effect. Simply because
there is no-one to witness that clearly visible effect!
The public part, is what ensures the permanency. Not because it is
impossible to change something (it is perfectly doable) but because that
change, or its cryptographically effects, are seen by, other
participants.
Bitcoin, for example is not permanent either, in theoretic sense. If
enough participants decide that the 0.01 BTC that you paid to John a
year ago, is sent to Mallory instead, that is what will happen: history
will be rewritten.
Bitcoins Immutability stems from the fact that anyone can detect such
a change, and that a vast majority then needs to acknowledge that
change.
The public part furthermore ensures that those participants will get
hurt when making such a retrospective change: they have a stake in the
(Bitcoin) blockchain, which will decrease in value because they just
have proved that this blockchain can be retrospectively mutated.
In a blockchain, public, or private, immutability is more of an
agreement amongst all participants that we won't change history.
Promised! it is not some magical "thing that comes from cryptography".
In a private blockchain that promise is easy to make. And even easier to
enforce: if Mallory changes some old record, just throw him out!
With that in mind: immutability is an agreement, so you can just choose
any database, even a shared excel sheet, and then promise each other
never to change anything. All you need is detection that something was
changed, which most database systems (or logging) will offer. You can
even add some cryptography to it to make tampering more obvious or
easier to revert or deal with.
Permissionless because we need control.
A blockchain has to be permissionless in order to ensure permanence.
This is very simple actually. If you can control who has access, you
control who decides what the truth is. Therefore, you hold the keys to
change history in any way that you want.
In the analogy of the household book, the person who controls who may
write in the book and who may read from it, is, by extension, the person
who controls what will get in the book and what not.
That person is, by extension, also the one in full control of rewriting
the history. Because when the access-controller wants something changed,
he can simply remove anyone opposing that change from write (and read)
access and then promote himself (or a proxy) to be able to write. And
then change it.
If other people can still read, they might notice that history is
rewritten, but will lack all power to do something about it. The truth
is what is in the blockchain, and they cannot change that, because of
lack of permissions. It matters little how clumsy or detectable such a
retrospective change is: the one with access control can, through that
power, make these changes.
Immutability in a blockchain is not something magical that comes from a
fancy technology . But it comes from the conditions a blockchain requires: the
environment, or "world" in which it runs make it immutable.
The irony is that, actually, there is a magic technology that ensures
immutability. And that technology is called blockchain. And hence has
to be a public blockchain. We've come full-circle.
No Distribution because of scaling or speed.
A blockchain has to be distributed in order to ensure a verifiable truth.
The opposite of distribution is centralization. To follow the "household
book" analogy, distribution would mean that several times a day (maybe
even after every change) copies are made and exchanged amongst people.
More important, however, is that none of these copies is considered "The
Truth".
If there is only ever one copy of the household book, changing stuff in
there (like ripping out a page) is trivial and -if done well- undetectable.
The obvious solution would be to photocopy every page (say, daily) and
keep those copies in multiple places. This is distribution. This is
inefficient, slow and expensive, as opposed to having one copy and simply trusting that.
But in essence what a blockchain does. Because of the exact reason of
trust: so that we don't have to trust one copyholder to tell us the
truth. This is the trustless nature of a blockchain.
When all the copies at all moments can be considered the truth any
difference between any copy will be detectable and should trigger an
alarm. We then need a conflict resolution: which one is the truth.
In Bitcoin, they simply say: what the majority of copy-holders have is
the truth. So if your book is copied amongst five people and two have in
there "berkes bought expensive shoes" but three don't, berkes did not
buy expensive shoes.
If only one book is elected as The Truth, and all others are simply
copies that could be used to proof that something was there at some
point, that really proves nothing: who is to say the person holding the
copy did not forge some records in there?
Distribution amongst all participants is crucial, because any central
authority can otherwise change history at will and without detection:
Verification is not possible and trust in an authority, or even a small
group of authorities, is required.
To turn it around: when you don't need that trustlessness, when you can
trust a central authority, you don't need a blockchain. To turn it
around again: if it requires trust, has an authority, by nature, it is
not a blockchain.
But what about my favorite coin?
If it has a "private" or "permissioned" blockchain, it is not using a
blockchain. It might still be a cryptographically backed database, a
solid cryptocurrency of very modern database, but it simply is not using
a blockchain. And because it is not using it, it lacks one or more of
the crucial traits.
Which means a single company could run away with your coins at any
moment (yes, Ripple, looking at you). Or which means it is fundamentally
insecure. Or it may offer very interesting solutions nonetheless.
I can probably build a very useful and interesting monetary exchange system
based on trust and a Google spreadsheet. But it ain't a blockchain. It's
"just" a spreadsheet on a Google server (with a really novel idea
around it).
"You say tomato, I say tomato"
Sure. If you want to call any database a blockchain, go ahead. If you
insist on calling a Google spreadsheet a blockchain: fine. Its not some
protected or trademarked term. You are even allowed to call my bicycle a
blockchain. It has a chain after all.
But this helps no-one. Because you are either reinventing a wheel, or
you are using an extremely inefficient technology in a place where far
better fitting, more efficient technologies would help you far better.
Some private blockchains are not blockchains because they are simply
other technologies.
But unfortunately most private blockchains are really just
inefficient, insecure or simply stupid implementations in which a public
blockchain-setup is used behind closed doors. This offers none of the
benefits of that public version, but all of the downsides.
Take git: git is not a blockchain; git is a
DAG;
so don't call it a blockchain. A DAG is very elegant, efficient
data-structure. That could even be used for distributed data-storage
within a small group of participants that need some
cryptographically-secure tamper-detection of their data. I'm mentioning
git, because there are some cryptocurrencies that do exactly this: using
a DAG to share truth amongst a private set of participants.
Or take BitTorrent: BitTorrent is not a blockchain; so don't call it
that. BitTorrent is a very neat implementation of Merkle trees, and
really brilliant for distributing large amounts of data over a large
amount of participants. Not a blockchain. I'm mentioning it, because
this technology is often enough if you need to ensure that all
participants have a copy of the data.
There are literally thousands of types of databases out there, some
allow ridiculously easy syncing, others
allow insane throughput, again others allow really
thorough consistency checks. Or cryptographically signed logs. Or
encryption of the data, or sharing of parts of data, or ... I could go
on. We don't call all these "blockchains" because of a hype. They are
not: They are proper solutions to a specific use-case. A blockchain is
one such solution, and like most technology, it applies to a very small
subset of use-cases. A private version, however, can never be such a
subset.
Positive feedback, as well as images of cats, calling me names, for
hating on your beloved altcoins, or other comments are very welcome at
my twitter or on
reddit.