September 26, 2017

“Private blockchain” is just a confusing name for a shared database

Banks and financial institutions seem to be all over the blockchain. It seems they agree with the Bitcoin community that the technology behind Bitcoin can provide an efficient platform for settlement and for issuing digital assets. Curiously, though, they seem to shy away from Bitcoin itself. Instead, they want something they have more control over and doesn’t require exposing transactions publicly. Besides, Bitcoin has too much of an association in the media with theft, crime, and smut — no place for serious, upstanding bankers. As a result, the buzz in the financial industry is about “private blockchains.”

But here’s the thing — “private blockchain” is just a confusing name for a shared database.

The key to Bitcoin’s security (and success) is its decentralization which comes from its innovative use of proof-of-work mining. However, if you have a blockchain where only a few companies are allowed to participate, proof-of-work doesn’t make sense any more. You’re left with a system where a set of identified (rather than pseudonymous) parties maintain a shared ledger, keeping tabs on each other so that no single party controls the database. What is it about a blockchain that makes this any better than using a regular replicated database?

Supporters argue that the blockchain’s crypto, including signatures and hash pointers, is what distinguishes a private blockchain from a vanilla shared database. The crypto makes the system harder to tamper with and easier to audit. But these aspects of the blockchain weren’t Bitcoin’s innovation! In fact, Satoshi tweaked them only slightly from the earlier research that he cites in his whitepaper research by Haber and Stornetta going all the way back to 1991!

Here’s my take on what’s going on:

  • It is true that adding signatures and hash pointers makes a shared database a bit more secure. However, it’s qualitatively different from the level of security, irreversibility, and censorship-resistance you get with the public blockchain.
  • The use of these crypto techniques for building a tamper-resistant database has been known for 25 years. At first there wasn’t much impetus for Wall Street to pay attention, but gradually there has arisen a great opportunity in moving some types of financial infrastructure to an automated, cryptographically secured model.
  • For banks to go this route, they must learn about the technology, get everyone to the same table, and develop and deploy a standard. The blockchain conveniently solves these problems due to the hype around it. In my view, it’s not the novelty of blockchain technology but rather its mindshare that has gotten Wall Street to converge on it, driven by the fear of missing out. It’s acted as a focal point for standardization.
  • To build these private blockchains, banks start with the Bitcoin Core code and rip out all the parts they don’t need. It’s a bit like hammering in a thumb tack, but if a hammer is readily available and no one’s told you that thumb tacks can be pushed in by hand, there’s nothing particularly wrong with it.

Thanks to participants at the Bitcoin Pacifica gathering for helping me think through this question. 


  1. Simon Taylor says:

    Why is the only valid argument: “The key to Bitcoin’s security (and success) is its decentralization which comes from its innovative use of proof-of-work mining. ”

    Who are you and what do you want to achieve?

    Chaining blocks of transactions together for known actors in highly valuable transactions (like say a $100M corporate loan) can actually solve significant bank cost and regulation challenges. This is no different to a VPN for secure networking.

    There may be possible futures in which that is a permissioned set of app logic on top of Bitcoin (and / or Ethereum), but for right now, I’m not sure Bitcoin, in the middle of the BIP 100 / XT debacle is up to that task.

    There seems to be an obsession with the fact that a censorship resistant thing was created. Therefore we should use that censorship resistant thing, for everything, because censorship resistance is what we want…

    But who are you, and what do you want to achieve?

    If you’re a bank, you don’t want censorship resistance. So why would you use Bitcoin in it’s current state? It doesn’t meet the functional and non functional requirements of banking. There may however be things you can do today, that solve business challenges and – if – the open source community gets Bitcoin (or an alternate) up to where it needs to be, then great. Migrate, share, merge, side… chain your way on there.

    For me the most compelling use cases are a blend of permissioned structures, using the unpermissioned blockchain as a universal pointer / reference (e.g. Everledger).

    If someone does get the one global ledger for the world up to scratch, trust me, banks would adopt it in a heartbeat.

    • First off, chaining blocks together in a replicated database has been done since the 70’s. Prior to the hype of bitcoin, we called that “journaling”. What that has to do with a VPN… I’m not sure.

      Blockchains that aren’t censorship resistance have been in full deployment for years. SWIFT, ACH, etc. They are all permissioned, however, the economics of this model has been such that a central provider (which is typically efficienct because a counterparty to the transactions is a mediator) are more cost efficient.

      *The only* efficiency of a blockchain is regulatory arbitrage. Permissioned ledgers offer no such efficiency. If you’re wondering how we unraveled the flash crash of 2010 – it’s through the commonplace time-tested, and centralized database technology of the 20th century. A blockchain would have only increased the obfuscation to this process. If you don’t believe this, ask any blockchain developer how he queries his blockchain – the answer will always be “via an rdms which indexes the blocks”

  2. This.

  3. Gideon Greenspan says:

    Thanks for this, it’s a question I have also thought about a lot. Some brief responses:

    a) Yes, a “private blockchain” is just a shared database. Really, it’s the shared database part that’s the interesting product, and the private blockchain is just the mechanism which enables it to happen. Perhaps other mechanisms exist as well.

    b) The innovations on which private blockchains depend have indeed been around for decades. Similarly the innovations on which the world wide web depended were around for decades before its invention. In both cases, something interesting still happens when these innovations are combined together to create a new product.

    c) The signatures and hash pointers aren’t the only interesting thing about private blockchains. Also, it’s the way in which the security model is redesigned to enable safe write access by multiple non-trusting (and even fiercely competitive) parties. The mechanism is either per-transaction constraints (Bitcoin style) or forced use of stored procedures (Ethereum style). Again, perhaps other mechanisms exist, but neither of these two are standard features of today’s databases.

    d) Forking from Bitcoin Core (as we’ve also done with MultiChain) or other public blockchain codebases is indeed only the first step towards implementing scalable enterprise-class private blockchains (or if you prefer, safe shared-write distributed databases). But it’s a quick and convenient way to get to something usable for pilot projects and R&D. In the long term, I believe that there will be a convergence between private blockchains and SQL-driven RDBMSes.

    FWIW more on this question:

  4. Dominic Williams says:

    It’s not quite true that a blockchain is just a shared database. The key is that it has no centralized control, and is secure w/o it. If a bank adopts for example T0’s solution based on PeerNova’s authenticated database, they introduce a new gatekeeper. The whole point is that they don’t want a new gatekeeper, they want a federated/permissioned blockchain.

    Future blockchains will be better described as ledgers. They will not use Proof of Work, which is already obsolete: far superior consensus algorithms already exist in the wings that don’t require delays, burning of electricity etc. These future ledgers will use server identities, which can be made Sybil resistant where the network is open using different techniques, and simply dealt out by a trusted dealer in the case of settlement and clearing (for example by an industry association).

    The main point, anyway, is that decentralized ledgers have huge advantages over shared databases, and that future ledgers will not have the performance problems of Bitcoin and related systems. Anyone interested in scaling decentralized systems generally should keep an eye on where various new techniques and consensus math will appear over coming months.

  5. Tim Sloane says:

    Mostly agree with your position. Would add one area of differentiation between private blockchain and a database. With a centrally managed database the cost associated with queries is born by the centralized entity while the cost of a query on the blockchain is born by the entity that wants the data. If the solution is a large quantity of public data that is accessed frequently, providing downloaded snapshots of the data may prove economically beneficial over support for remote queries.

  6. I agree. it is like a cancer cell growing on the vein. Transparency is just too hard for banks to commit. I wonder how they try to use quantum crypto into this strangely sounding phrase – ‘private blockchain’.