Fork it up!

A Straight Line

Today’s topic really touches on the way blockchain participants come to consensus on when a set of transactions (a “block”) becomes “truth” and gets essentially cast in concrete as an immutable record on that blockchain.

Think of a blockchain as just that – a more or less straight set of links in a chain, where each link is a “block” of transactions in a given blockchain network (e.g. Bitcoin, Ethereum) and where a consensus of participants in that network (or “nodes” for our purposes here) have come to agreement that: “yeah, that block is valid according to the validation rules of that particular blockchain, so go ahead and forge that link on the chain.

When you Come to a fork in the Road, Take it

However, there are conditions where a blockchain can diverge into two chains going forward.  Broadly speaking there are three types of such forks.

Business As Usual

Sidebar:miner nodes” on a blockchain are incented to identify valid blocks of transactions submitted on their blockchain network and get consensus from a majority of all nodes that “their block” should be the next link on the chain.

Now, the first type of “fork” is perfectly normal – and occurs because two or more mining nodes have solved a puzzle (or performed some other “work”) to get their “block” on the blockchain at virtually the same time, creating 2 or more possible paths that the particular blockchain can take.

Over time (and we’re talking seconds here), one of those “paths” will increase in length as other miners choose one of the “fork paths” and build upon it with subsequent candidate “blocks”.  The shortest fork will eventually be orphaned and forgotten, and processing will proceed on the longest fork. This is why some folks (like merchants accepting Bitcoins) say that if you post a transaction on a blockchain, and the block containing your transaction  has 6 blocks or more built on top of it – you are GOOD – there’s an EXTREMELY low chance that you are on an “orphaned fork”.

Hard Choice

The other two types of forks are known as “hard” and “soft” forks.  In a hard fork, the blockchain software on computers in that blockchain network (“nodes”) is upgraded by at least some of the nodes, such that “old nodes” will judge blocks from the “new nodes” to be invalid.  If the “old nodes” are stubborn and will not upgrade, voila – a fork.  The most famous example of this was the hard fork in the Ethereum blockchain – leading to the new Ethereum fork and “Ethereum Classic” (like Coke and Coke Classic in the ’80s).

Soft Touch

In a “soft fork”, again you have a situation where some nodes have upgraded their blockchain software.  In THIS case, however, one or more of the rules for that particular blockchain have been constricted by the new software (we say that a “soft fork” is backwardly compatible with previous transactions in that blockchain).

Say that the “new nodes” now will validate transactions that are only up to 1 MB in length – whereas under the “old rules” transactions could be 2 MB in length.  The “old nodes” will validate any of the blocks from the “new nodes” – but if those “old nodes” try to MINE their own blocks – they could be rejected.  The issue in all of this: if the “new nodes” who mine blocks are a minority in that blockchain network, then eventually their “new fork” will be orphaned – BECAUSE those “new nodes” are a minority compared to the majority of “old node” miners.

The Good, Bad, and Ugly

So basically blockchain forks are a natural byproduct of the consensus method used, and are also a way to “upgrade” a particular blockchain’s rule.  Both good and bad things can happen – the most notorious “bad thing” was the Ethereum episode mentioned above. On the flip side, a well managed fork can allow a blockchain to evolve and improve without compromising the validity of past transactions.

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.

What is Blockchain?

If you google the phrase “what is blockchain” you will get (as of 6/3/17) 17 MILLION hits. We at Blocktonite don’t pretend that we can offer you as good an answer to that question as any of those folks. In fact, we’d be lying if we said WE totally get it.  However,  we plan on building over the next few weeks a special section of our library dedicated to the best explanations we’ve found.

Having said that – here’s the way we think about blockchain in terms of “what  is it for?”: it’s a way to allow a “community” who have some kind of shared interest (exchanging money, who has what property, where did a physical, virtual, or intellectual asset come from, and on and on) to agree on the state of that specific world (energy consumption, land ownership, money, etc.).  This sounds dull – but it’s yuge. Take it from us.  The best way to “get it” is to see how industries and countries and governments are thinking of ways to use blockchain (hence our attempt to highlight what’s going on in the areas of music, energy, state regulations, document management, internet of things, etc.).

From an “information technology” perspective, blockchain is an evolving foundational technological standard (meaning ‘raw’ technological plumbing) that can run on the internet. The internet today has literally hundreds of such foundational ‘services’ – most of which you experience but don’t directly interact with.  Examples:  “SMTP” is what your e-mail provider uses, “http” powers all the websites you access, “FTP” is what you are using when you upload/download files from somewhere, etc.  You rarely deal with these services directly – but your PC, Tablet, and mobile phone is using them on your behalf.  Blockchain is rapidly evolving as one of those core “foundational” services.