Private vs. Public and Permissioned vs. Permission-less

 

 

 

 

There are two related concepts regarding the most general types of blockchains:

  1. The idea of a blockchain that is “public” vs. one that is “private” (the “open door” and “passport bearer” photos above),
  2. The notion of a blockchain that is “permissioned” vs. a “non-permissioned” (or “permission-less“) blockchain.

We have seen people conflate items 1 and 2 (e.g. saying a public blockchain is a permission-less blockchain), and we have seen people maintain a subtle distinction between 1 & 2 above.

On this latter point, for people who maintain a distinction between 1 & 2: the concept is that the public/private distinction has to do with user authentication (WHO are you) and the permissioned/permission-less distinction has to do with user authorization (WHAT can you do). Although there doesn’t seem to be (ahem) 100% consensus on exactly what these terms mean, Blocktonite offers the following explanations of these subtle distinctions:

Public vs. Private

 These terms are generally used to describe whether a blockchain is open to literally anyone with an internet connection, symbolized by the open door graphic above, or if access (read, write, or read/write) to a blockchain is controlled by one or more parties. A very real example of a private blockchain are those set/up by consortia of parties with a shared interest in a particular community or marketplace. R3, the consortium of major banking institutions, is a prime example. In the case of “consortia based” blockchains – there are rules for consensus that stray away from the “proof of work” or “proof of state” mechanisms of public blockchains like Bitcoin (e.g. 10 out of 15 consortium members must agree before a transaction is posted to the blockchain).

You could have a private blockchain under the authority & control of one organization, but, frankly – why would you do that? That situation begins to sound like a secured, high performance, database!

Permissioned vs. Non-Permissioned

Generally speaking, we believe it is useful to think of public blockchains as “non-permissioned” (the Bitcoin blockchain would be “exhibit A” in this way) and private blockchains a “permissioned”.

However, we also believe a useful way to think about whether a blockchain is “permissioned” or not – is if there is the presence of some entity/entities who control what kind of transactions a blockchain participant can perform.  Example: perhaps I’m a bank who is “permissioned” to participate in R3, but I’m not allowed to see or initiate certain interbank transfers on the R3 network.  The fact that I need to be cleared to participate in R3 makes it a private blockchain, and the fact that I’m allowed to perform only certain transactions makes R3 a permissioned blockchain.

In the end, this discussion is a matter of semantics – the more important point is to understand blockchain deployment types and design points.