5 Blockchain Essentials – Part 1
This series will provide a way to evaluate if the Blockchain concept is relevant for your business or client. It will include examples of successful use-cases, and also some not so successful ones, as well an up-to-date, summary of the current landscape.
I have been working in the technology architecture & delivery for twenty years. Over the last few years, I have taken in a keen interest in the Blockchain concept, gathering information from a range of experts, in economics, and in technology, and from a range of consultancies that provide a Blockchain offering.
This first post will focus on the fundamentals (with no technical jargon) of how to evaluate if the Blockchain concept is relevant for your organisation, and what are the possible benefits.
To Blockchain or not to Blockchain? That is the question.
What is Blockchain and do I need it?
Does your business benefit from transactions involving multiple parties, both internal and external to the company, where provenance, and tracking is critical to those transactions?
Finance, Insurance, Supply Chain, Tax, Identity and Customs are good examples of industries where this is the case.
Yes, my business meets that criteria. Does that mean I have to use cryptocurrency or tokens, and have an ICO to use Blockchain?
Bitcoin and other cryptocurrencies are single use-cases of the Blockchain concept.
An initial coin offering (ICO) is used to generate investment in a platform, or app, which gives the investors a return on investment in the form of selling those “coins” at a later stage, for a higher value. This is of course, IF the platform succeeds.
Risks around Bitcoin, cryptocurrency or ICOs should not impact your evaluation of the Blockchain concept for your business.
The learnings are definitely useful but are not always applicable.
Tokens, or cryptocurrency, are not a requirement for the implementation of the Blockchain concept.
How can the Blockchain concept benefit my business?
To understand the benefits, let’s dive in a little deeper. As outlined in the Verge, there is no universally agreed upon definition of Blockchain.
It’s a concept in its early stages and there is as yet no implementation (or use) of the concept that has been standardised.
The Blockchain concept adds a lot of value when trading or transacting with parties, where tracking or provenance is required.
To transact legitimately, parties need a way to “know” you are the owner of the goods, that they are genuine, and that the funds are available, as well as a trusted distribution mechanism. For the funds part, the method is to use a list of transactions that have taken place, i.e. a list or a ledger has been used.
Simply put, the Blockchain concept is a mechanism to enable trust, across the whole network, so that trades are legitimate by design, using a shared or “distributed’ ledger.
A “shared” spreadsheet is a good analogy
Imagine the shared ledger to be a spreadsheet.
The logic for adding legitimate transactions to the ledger, are applied by using “macros” on the spreadsheet. Certain parties, or “nodes” on the network, have their own copy of the spreadsheet, and every time a change is made, every nodes’ copy is updated according to the rules programmed into the macros or “smart contracts”.
“Blocks” are complete entries added to the spreadsheet. i.e. Rows.
The blocks are similar to Row 1, Row 2 etc.
Certain aspects of Row 2 are dependent on Row 1, for instance, like a cumulative count on the spreadsheet i.e. a chain of rows, or blocks.
To add Row 3, the macros would run on the data entered, to ensure that it was legitimate, and then all the nodes’ copies of the spreadsheet are updated.
If I tried to delete Row 1, then Row 2, and Row 3 would be impacted, so it’s not easy to delete Row 1 without updating the subsequent rows.
Hence the Blockchain concept doesn’t lend itself to the deletion of these entries, or blocks easily. It is seen as an immutable data store. (More about compliance later).
The spreadsheet can be permissioned or public
“Permissioned” – Some rows in the spreadsheet, or certain cells in the rows can be protected, so they can only be seen and changed by certain parties.
“Public” – The shared spreadsheet does not have any protected parts. Every cell is visible and can be updated by everyone, according to the logic applied by the macros.
The Blockchain concept is again simply the use of a “shared” spreadsheet, or ledger, to ensure legitimate transactions.
Blockchain is a concept, so you can use it how you want…. with tokens, without tokens, permissioned, public, 1 node, 5 nodes or 1000 nodes.
Hold on a minute! Spreadsheets and databases have been here for ages, why is this different to existing systems?
The difference comes in when updating or adding a row to the shared spreadsheet. Before it can be changed, every party on the network has to come to an agreement it is correct i.e. Row 2 is dependent on the agreed state, after Row 1.
I have thousands of users on my network, it will take ages for everyone to verify every single transaction. That’s ridiculous
With the Blockchain concept, the “rules” as to who can add or update; and what is legitimate, and what is not, are automatically enforced by the “macros” on the spreadsheet. These “macros” or “smart contracts” are basically software programs that allow logic to be applied on updates to the spreadsheet. The scaling has been an issue with various projects, but now there are enterprise scale examples, working in the real world. More on that later.
What’s all this decentralisation about? Why is everyone talking about “power back to the people”?
Fundamentally, because no one party has ownership of the ledger or shared spreadsheet, it is decentralised.
Let’s consider a “Clearing house” before and after the Blockchain concept. The clearing house is essentially a central store or entity that provides a level of trust to the whole ecosystem. It gives the merchant confidence that an organisation has the funds to pay for an item when they purchase an item or service.
Before the Blockchain concept:
The clearing house and the “agents” that are “trusted” act as gatekeepers who check the transactions follow certain rules and are reconciled. To transact, the clearing house or the agents would have to approve the status of a single organisation’s funds. If they didn’t approve it, the transaction would be declined.
There is clear potential for false positives and misuse.
After the Blockchain concept is implemented:
Any entity could interact with any other entity, with or without agents. Provenance, tracking and reconciliation would be ensured by design using the macros or smart contracts as the logic.
No one would be able to manipulate the data without following the rules of the whole ledger, and without everyone knowing, or a huge discrepancy. If a transaction doesn’t follow the rules in the smart contracts, or there is a discrepancy somewhere in the shared spreadsheet, then the update (transaction) is simply not completed.
The Blockchain concept is effectively automating what the checking agents and gatekeepers do for the “clearing house”, using every one’s input. It is a decentralised form of “trust” for the financial transactions.
It therefore follows, that for transactions where provenance is key, let’s say for an example for a Medical license – it cannot be faked, if we had a “shared” spreadsheet listing Medical licenses.
Yet another example
The Art world is another great use-case. A transaction between a seller and a buyer directly, or via an agent needs a certain level of “trust” that the item being sold is authentic and will be delivered to them on payment.
This trust has three key elements: provenance, a delivery tracking element, and a financial transaction. Provenance can be determined by the whole network of parties with access to the data store, i.e. is the painting authentic? When tracking is transparent, there is confidence in the delivery, and therefore the financial transaction is completed, with the correct rules to determine tax & fees.
What’s the benefit of all this?
Shared “trust” equates to higher consumer confidence and of course, less criminal activity. On the internet, especially, this is a key value add. Provenance is so transparent that no checking services are required. Genuine transactions occur, every time. Of course, all this depends on the concept being implemented properly (although “properly” remains to be defined or standardised).
The value add also applies to tracking physical items. All you need is a barcode, or some other tracking mechanism on a physical product, and connecting it to the shared spreadsheet, or ledger will provide a tracked product through the supply chain.
As demonstrated in the examples above, the Blockchain concept, as a trust mechanism adds value, not just internal to the organisation, but also to the whole ecosystem, or market.
Notably the most successful projects have been multiple organisations working together to build the “shared” spreadsheet, or ledger. A key aspect of it being shared, means it has to be implemented very carefully, by any organisation or cohort of organisations, to bring out the real value for the consumer, and the ecosystem.
If you think your organisation or client could benefit from using the Blockchain concept, but aren’t sure how to implement it or realise the value, contact us here at B2E. Also tune in to my next blog in the series where you can see it in action, using a scaled case-study.
Forthcoming articles in this BlockChain series:
Article 2: An Ounce of the Blockchain Concept in Action is Worth a Ton of Theory
Article 3: Difficulties in Implementing the Blockchain Concept are Just Things to Overcome, After All
Article 4: One Small Blockchain for Man, One Giant Leap for Mankind
Article 5: The Great Aim of Blockchain is not Knowledge, but Action
About the author, Aruna Koya
Aruna Koya is a B2E Principal who has spent 20 years working in the IT industry, starting as Software Developer then Department Head & Delivery related roles, progressing through to Director level.
Her most recent projects have seen her working to design and develop Blockchain solutions using Hyperledger, in the private, permissioned format for Enterprise solutions.