Introduction
In my previous post I covered key concepts fundamental to understanding blockchain technology, and detailed a small handful of real world use-cases. In this post I’d like to go a little further and cover some fundamentals crucial to understanding exactly how blockchain participants (human or software) can have trust in a system that is inherently trustless.
A recap
Generally speaking, blockchain is technology comprising a distributed network of computers called nodes, each running software designed to perform several functions. The key functions are transaction validation, chain security and chain building using consensus algorithms.
Consensus
But what exactly do we mean by consensus? How does it factor into the near-instant transfer of value without double spending? How is it leveraged to achieve systems of decentralised storage and Distributed Autonomous Organisations, particularly between participants who may not formally trust each other outside the system?
Wikipedia describes consensus as “…a decision in the best interest of the whole…”. Wikipedia itself utilises consensus when the community modifies controversial articles, or articles requiring several areas of expertise. It is fundamentally about group decision-making in order to arrive at a single source of truth. But to understand consensus in a blockchain, we first need to understand what exactly such a mechanism is trying to achieve; securing against malicious or faulty behaviour from nodes, from incoming transaction data (problems that are down to the Byzantine Generals Problem) and the synchronisation of each node’s knowledge of the network’s current state, being but three examples.
In terms of human organisations, a national army comprises a military hierarchy where decisions concerning actions affecting many infantry units, are traditionally made by a single member – the General. In a co-operative organisation such as New Zealand’s Fonterra, proposed fiscal or organisational legislative action is always performed by means of a decision made by more than one member. But in order for members of either of the above examples to enact or approve decisions, a level of trust in those that make or propose them is required by the rest of the organisation.
Organisationally speaking. trust comes from varied sources; industry or academic qualifications or perhaps appointment by someone already in possession of trust. In the absence of these, and sometimes in addition to them; prior friendships, mood, whim and other biases also affect outcomes. When implemented in a blockchain however, consensus is a system of decision-making to reach agreement among the network members – its peers. Human biases are eliminated in favour of systems of mathematics, logic and cryptography, packaged up in a transparent and open manner using open source technology and open data. However, such systems are not without issues of their own as we shall see when we discuss permissionless and permissioned blockchain implementations shortly.
Consensus Implementations
Depending on your definition, there are around 20 different blockchain and blockchain-like implementations, each designed to do a specific job. Bitcoin for the transmission and store of value in Bitcoins, Ethereum for long-running programs of almost any kind, IOTA for micro-transactions between devices in an IoT (Internet of Things) network, HyperLedger Fabric, Sawtooth and Iroha for enterprise, and many others. It is the sheer variation of distinct use-cases that requires different ways of validating transactions, securing networks and appending blocks.
Proof of Work
The Proof of Work (PoW) algorithm built into bitcoin known as HashCash, was originally created to reduce email spam. It was thought that if a charge could be applied to the sending of bulk email, the cost to spammers would become prohibitive. When used for Blockchain, immutability is one of HashCash’s prime features. Transaction accuracy can be (almost) guaranteed by requiring nodes to expend energy in the form of electricity to perform a computationally expensive puzzle, resulting in new blocks being added to the chain. This process is known as mining. Successful nodes are rewarded with newly minted bitcoin currency each time the puzzle is completed. If any attempt to change a transaction is made, all nodes in the network would be required to expend a lot of new electricity in re-calculating each block’s transactions. Way too much, it turns out, to be an effective attack.
Proof of Stake
In Proof of Stake, nodes aren’t mining anything. Instead, they act as transaction validators. Each node puts down a payment using the cryptocurrency of the network. For each round of participation, the greater the amount staked, the greater are the chances of a node being selected by the algorithm to participate in block validation. The reward for then successfully validating a block is proportional to the amount staked.
Proof of X
There are many alternative consensus algorithms already in use or proposed, whose end result is agreement among participants, or a subset of them as to the state of the network. Proof of Storage uses a node’s ability to verify that it has sufficient hard-drive storage capacity to participate, systems such as Filecoin and Storj use this. Proof of Bandwidth is a similar idea, and there is also PBFT, Proof of Burn, Proof of Capacity, Proof of Elapsed Time and many others, each designed for a specific use-case.
Trustless Trust
We’ve seen that a system built on open source software, that provides open data via principles of open access can be trusted by users to secure itself for the benefit of applications running on top of it. But so far we have only discussed ‘classic’ blockchain implementations that are open and permissionless. But what about applications that require a blockchain backend to be unavailable and closed by design? Who on earth would want such a thing, and what would it look like?
The Enterprise In The Room
Classic enterprise organisations from SMEs to government have seen the benefits that decentralised consensus can bring to their business, and they want in. But enterprise can’t just let just anyone into their networks, or to view its data; a great number have extremely onerous compliance and regulation to contend with. So the sum-total of all participants’ ‘off-chain’ compliance needs to be fulfilled by the system itself. In such systems participants are usually represented by parties already known to one another outside the network; companies already involved in a service or supply chain for example. Because participants are already known, a large chunk of the unknowns are mitigated in one fell swoop.
A permissioned blockchain therefore restricts participants’ access to, and participation in, the network for the purposes of legislative compliance and traditional ideas around network and data security.
Now coming at these blockchain implementations armed only with a knowledge of open, permissionless implementations, confusion and a little suspicion is understandable. If a chain is hidden away behind a firewall, surely it loses all vestiges of blockchain’s (supposedly) distributed nature, and the data centre in which the network is located, however secure, becomes the honeypot to which attackers, savvy to the network’s physical location, are attracted? If the number of validating nodes within the network is only in the order of the hundreds (as it usually is in HyperLedger Fabric for instance), how good can the quality of consensus actually be?
It turns out that with careful study of projects suited to enterprise such as multi-party identity and supply-chain management between organisations already known to one another, that the type of DLT implementation and also the consensus mechanism at its heart, may need to differ or change. There are now sufficient permissioned and permissionless (and hybrid) implementations available that for common use-cases, there is already a solution suited to them.
This then leaves only cloud engineers to install and maintain them and developers to build applications on top of them. This is the way things should be, and is the way things are already for traditional web-based applications in most development shops.
HyperLedger
The HyperLedger Project is an open source collaboration between a group of global companies (IBM, Intel, Huawei and others) who set out to build a set of common tools, and a common language for blockchain and DLT technology. The project is maintained by the Linux Foundation and comprises eight different projects at present. Five of these are blockchains, some with pluggable consensus mechanisms, and three are modules used to build or integrate Hyperledger-based DLT technology with other systems.
From an open perspective, the downsides of permissioned chains – such as a perceived increased attack surface from non-geographically distributed nodes, the possibility that ‘open’ APIs into transactions might be filtered at source and that the total number of nodes is comparatively small (with even fewer actually participating in validation, under PBFT for example) – it seems that such systems are entirely missing the point of distributed consensus.
Let’s think about the problem from an Enterprise Architect’s perspective for a moment. The kinds of problems these organisations believe can be solved with DLT, will likely only ever concern a few organisations, all of whom are already known to one another. This means that Smart Contracts written in well-known languages like Go and Python and the ability for consensus engines to be pluggable, are just two bonuses on top of the sub-second transaction times, now achievable given the very low network latencies of your average datacentre.
Summary
The HyperLedger Projects are open source and have open governance at their core. Once they have greater momentum, especially from Enterprise users and those initially only familiar with permissionless systems such as Ethereum for example, the perceived problems will be addressed as they are encountered. Should developers still not feel happy about the state of a project, it can be forked, just like any other open source project.
Questions remain for the truly ‘open’ among us as to how effective permissioned systems can really be given even the small number of issues touched upon here. As always, time will tell.
A very healthy question to ask when considering DLT as part of any solution is “Can’t we just host a database and a web-based app?!”. Nine times out of then, the answer will be “probably”. But for the remainder, or if after asking, that the qualities of data immutability, multi-party interaction and strong assurances of data integrity are deemed critical, then we’d better talk.
About Russell
Russell is a Senior Developer on our SilverStripe bespoke development team. He is fascinated by the changes blockchain and its applications can bring about in the disruption and transformation of the world’s sociological and technological landscape.
