Breaking Down Blockchain

The blockchain technology (BCT) that underpins Bitcoin is now some 7 years old. In that time, since the first open source blockchain application was released in January 2009, developers have built upon the open source code base creating numerous innovative implementations.

Each innovation addresses particular inherent weaknesses in the original design and implementation of BCT and is necessary, but the numerous blockchain options make the blockchain concept all the more abstruse.

Some implementations provide different speeds for arriving at consensus (important for high-transaction volume environments), some require less computational input to authenticate and authorise transactions (ideal for mobile applications), some require less overall energy consumption on the network (ideal for resource constrained environments), some enable sidechaining (a technique for tying other application information to an original blockchain), and some implementations provide tremendous block-forming scale to provide trillions-of-transactions-per-second scale (ideal for highly-regulated exchange environments).

This article breaks down the blockchain technology space providing a taxonomy, based on the work of Dave Birch, upon which emerging blockchain paradigms can be understood.

The following taxonomy (based on the work of David Birch of Hyperion Consult), partitioning the blockchain technology space based on answers to the following questions: (i) how many copies of the ledger are there, (ii) who is permitted to place transactions on the ledger, and (iii) who maintains integrity of the ledger.

A simpler way to think of this breakdown is in terms of who predominantly (i) reads, (ii) writes and (iii) integrates the ledger?

Based on Birch (2016) cited in “Distributed Ledger Technology: Beyond Blockchain”, Government Office for Science, Government of the United Kingdom.

The answer to the first question is implied for all blockchain based applications and the question is merely provided as a conceptual link to our existing database-oriented view of how ledgers are implemented. Traditional ledgers are centrally managed (centralised) and controlled and usually implemented in a single database managed by a trusted authority, like a bank. Typically only you and your bank can read the ledger, at least your section of the ledger. All blockchain applications by contrast consist of multiple ledgers (distributed) each participant holding a single copy of it with no single point of control with each participant able to write to it.

Restricted or Unrestricted

The next question asked is who is allowed to put transactions on the ledger within the blockchain application. Blockchain applications may be restricted in that they limit participation in the act of writing to the ledger. This may be for good reason. For example, a derivatives market that adopts blockchain technology may need the ability to handle exascale transaction volumes per second, sub-second consensus formation and only have a limited number of participating nodes on which the application can run; needs which the original blockchain implementation simply cannot meet.

Alternatively, blockchain applications may be unrestricted in that they permit anyone to write a transaction on the ledger. Writing a transaction to the ledger in no way means that it will be integrated into the single-source-of-truth that the ledger represents. The decision over how consensus will be formed will be made according to whether the ecosystem is permissioned of permissionless.

Permissioned or Permissionless

Ledgers can be further decomposed based on the answer to the final question: who manages integrity of the ledger? Or put another way, how does a transaction get integrated into the ledger permanently? There are two branches based on whether the application has a: permissionless or permissioned model for authentication and authorisation in the application.

Permissionless applications only require a unique identity so that the transaction parties are uniquely identifiable. No assertion of whether the identity is authentic in the real world or authorised to transact is made before integrating the ledger takes place. Bitcoin is an example of a permissionless blockchain application. Permissioned applications however expect the identity to be authentic and authorised to transact as it was attempted. Ripple is an example of a permissioned blockchain application.

In the next article, the four basic building blocks of al blockchain applications will be explained and the unique features of a sample of blockchain applications will be explored.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.