Blockchain, or to use the wider term decentralised computing, could represent the next shift in computer systems thinking, following on from the likes of the internet, client-server architectures and databases.
However, it faces a real risk that initial attempts at deploying blockchain don’t deliver the expected benefits, expectations are not met, and as a consequence its wider adoption is set back.
Typical expectations are that transactions will be faster, transaction costs will be lowered, and that the system will have integrity and so be trustworthy. Integrity and trust is a major point, particularly when people have lost faith in existing financial systems and institutions.
Blockchain is really two things: a technology and a philosophy.
The benefits don’t derive from just the technology but in fact they mostly come from the underlying philosophy. If you implement a system based upon blockchain technology but don’t adopt the philosophy, then it won’t deliver all the benefits that you are looking for.
The technology is the computer part: the definition of data, the set of operations that can be performed upon that data, the computers that hold the data and perform those operations, and the interfaces to allow you to see the data and kick off the different operations. All quite standard as far as computer systems go.
If we think about a cryptocurrency, like bitcoin, the data is the list of coins and who owns each coin, the operations relate to transferring coins between people, the computers are the blockchain nodes, and the interfaces are the various wallet applications.
Where blockchain differs from a traditional architecture is that each of the blockchain nodes holds a complete copy of all data and each node executes every operation to verify that its results reconcile with all the other nodes; in effect cross checking each other.
This leads onto the philosophy.
The blockchain philosophy is that no single entity or interest group should have control of the blockchain, its control should be decentralised, and that everything should ideally be open and transparent. It’s this philosophy that ensures integrity and provides the basis for that all important integrity and trustworthiness.
Decentralisation ensures that no single entity or interest group can arbitrarily change the current data or perform an unauthorised operation.
In terms of cryptocurrency, this means that nobody can change who owns a coin by manipulating the data directly and that nobody can change a transfer operation to transfer 99% of the value to the new owner and illicitly syphon off 1%.
This is where the multiple nodes each with their independent copies of the data and verifying operations between nodes comes into play
If I were to change the ownership of a coin directly on my node’s data, all the other copies on the other nodes with the correct ownership will flag anything I do with that coin as an error during verification. Similarly, if I were to modify the transfer operation on my node to steal small amounts of coin then again when the results of my operation are verified on the other nodes it will fail the cross check and be discarded.
The verification process relies on all the other nodes agreeing the data, applying the same operation and correlating the results. If the majority of nodes, i.e. more than 50%, agree with the results then the operation is accepted and its results become the current data. Each node has a vote and consensus rules the day.
To further refine the point that no single entity or interest group should have control of the blockchain, in actual fact no single entity or interest group should control more than 50% of the nodes.
If I control more than 50% of the nodes, I could either change the data directly or update the operations on all my nodes and when this is crosschecked by the other nodes my nodes would outvote the others and my “hacked” data would be approved.
In order to have confidence that the blockchain is behaving in a trustworthy manner, you need to be confident the rules are being applied correctly in the blockchain node software itself. If we expand the blockchain example to cover smart contracts, then you need to be sure that the contracts are being executed as per the contract definition.
If the software running the blockchain is proprietary, how can you be sure that it is operating honestly?
If the blockchain software is being provided by a member of the blockchain then it raises concerns that one single entity has an unacceptable control over the blockchain as they could introduce an upgrade that changes the data or the operations outside of the agreed specification for their own benefit. One example of this could be a blockchain executing financial settlements between financial organisations where the blockchain software is being provided by one of those financial organisations.
Blockchains based on open source software are by nature transparent and open, making it possible to verify that the system performs as per the agreed specification.
If the blockchain is running proprietary software from an organisation whose business is based on supplying blockchain software and they have no interest in the implemented blockchain itself, their interest would best be served by ensuring that their software is well behaved to safeguard their future business.
Returning to those expectations.
In the early days of blockchain much was made over the speed of blockchain based systems over traditional systems in fields such as financial payments, remittances, and settlements.
These normally compared the new blockchain process against a traditional process which involved transactions across multiple, possibly external, systems. Such a revised process would be quicker even if it were implemented on a traditional platform.
The blockchain architecture itself is not a fast architecture as the consensus mechanism across all the nodes is time consuming and a similarly revised process implemented on a standard architecture will outperform a blockchain based approach.
Blockchain is not faster than a standard-architecture based system.
A lower transaction cost was similarly touted as a major benefit but again this was usually a comparison with an existing process with multiple systems and charges/fees involved.
Blockchain requires more computing infrastructure than standard architecture due to the multiple nodes and the tremendous duplication of data – think about the amount of infrastructure currently supporting the bitcoin blockchain.
However, in the decentralised blockchain you only are responsible for, and paying for, your own node, not all the nodes in the blockchain. If the aim is a fully redundant geo-replicated infrastructure, then implementing a blockchain and getting other parties to pay for all the other nodes certainly is more cost effective than paying for the entire infrastructure yourself.
Blockchain is more cost effective than a standard architecture system only if the portion of the blockchain that you are actually paying for costs less than what you would pay for that standard architecture system.
These cost benefits only come from adopting the blockchain philosophy of decentralised computing. At the simplest level it’s about not having a blockchain based on three nodes in your own data centre but having the nodes spread across and provided by all the interested parties.
Similarly, integrity and trust come from the blockchain philosophy, that of decentralisation which means no party having a disproportionate influence over the system, and of openness and transparency which means everybody can see that the system only operates within its rules.
So, when is a blockchain not a blockchain?
A blockchain system is not truly a blockchain when it is implemented on blockchain technology but doesn’t embrace the blockchain philosophy.
If it is not a truly blockchain then the benefits of lower costs and the acceptance of integrity and trustworthiness will most likely not be achieved and sadly expectations won’t be met.
If you want your blockchain project to be a success, ensure you are adopting the philosophy as well as the implementing the technology.
