Underpinning blockchain

null

If you’ve opened a newspaper in the past few years – literally or digitally – there’s a good chance you’ll have come across the terms ‘blockchain’ and ‘DLT’. Despite the increasing coverage these technologies are receiving, few people are bothering to stop and explain how they work, what they are good for or why they are needed. And that is a problem why? Well, I reckon you need to know what a tool does before you can truly identify why you might want to use it and with blockchain being touted as a vital element of our future, having an awareness of the basics shouldn’t hurt!

Blockchain means blockchain

Unfortunately, blockchain hasn’t had a universally-accepted definition for a while. Google ‘define: Blockchain’ and you’ll be told it’s “a digital ledger in which transactions made in bitcoin or another cryptocurrency are recorded chronologically and publicly.” IBM, on the other hand, has called it a “peer-to-peer network of parties, who all participate in a given transaction.” Not only do these seem quite different, they’re also utterly impenetrable to the average person.

Underneath the often glossy, infuriatingly vague marketing, a blockchain is actually a very simple data structure. Using well-established cryptographic principles (which have underpinned email security and online banking for years), it provides a means of keeping track of data and linking subsequent versions together as they evolve over time. Leaving aside the hairy maths underneath it all, there are a few key building blocks to be aware of:

Digital signatures indicate that a person/entity signing a document endorses its content. In the real world we tend to only use one ‘unique’ physical signature to prove we signed something (unless we’re a celebrity), but digital signatures are different as they change according to the specific document they’re being applied to. Nobody can take your signature from one document and apply it to another, as that would invalidate the signature. Digital signatures work through a pair of keys: private keys should be kept secret and are effectively the ‘password’ needed to sign messages on behalf of their corresponding public key.

Anybody can verify that messages signed by a specific public key are valid, without knowing the associated private key. Thanks to this, public keys can be used as a form of pseudonymous identity – this is not a novel application but it forms an important basis for systems interaction.

Cryptographic hash functions take a digital input and turn it into a condensed, scrambled version of itself which is effectively unique (this isn’t actually the case, but to avoid getting bogged down let’s assume they’re unique enough for us mere mortals with modern computers to work with them). We call the input to a hash function a message, and its output a message digest (which is just a really big number). Today, even basic PCs are very good at the maths involved in these calculations – your average laptop could knock millions of them out per second if you ask it to.

If even one bit of the original message is altered then its digest will change completely, which makes these algorithms great for detecting whether data has been tampered with. You don’t need to keep hold of an extra copy of the original file to verify its contents as these are unchanged if you just store the digest instead, making them very storage efficient too. This is useful when we apply it to individual files but becomes even more powerful when we use hashing algorithms to reference and validate more complex data structures.

It’s possible to verify huge data sets with a single hash value through a binary tree structure known as Merkle Trees (named after their inventor Ralph Merkle; a bit of a legend in the world of cryptography). These recursively hash pairs of hashes all the way up to a single hash at the top of the structure, making it possible to not only identify changes in any part of the entire dataset by calculating that single hash, but also enable us to prove whether certain data was present in that original state.

We combine these technologies to ‘build’ a blockchain: Merkle Trees summarise the latest version of the entire dataset, public keys act as identities for tracking proposed changes and digital signatures securely link the two. By keeping track of the latest hash covering the entire blockchain, any attempts to change history can be efficiently identified and rejected and it’s possible to prove whether certain data existed within the chain at a given point in history without keeping the entire dataset stored locally.

That is still pretty verbose, so let’s simplify further and finally get to a definition we can work with:

A blockchain is a continuously growing list of records, which are linked and secured using cryptography.

That list of records is often referred to as an append-only ledger; new additions are timestamped and recorded at the end of the list and thanks to the embedded history, any attempts to change the past immediately invalidate all subsequent records, making it easy to see whether a proposed addition is valid or if someone’s trying to pull your leg. We add blocks of new data to the historical chain – hence the name.

You can have the blockchain equivalent of a lonely microwave meal; a ‘ledger for one’, if that’s your thing, but for most users that’s not going to add much business value – in order to start using the technology properly you need to get other people involved…

I’ll take a DLT please, but hold the mayo

DLT seems to be another of those fantastic abbreviations that has been adopted by politicians and businesses alike before anyone even knows what it stands for; but I’ll let you in on an industry secret; it stands for Distributed Ledger Technology, and DLT is what can make a blockchain very interesting from a business perspective.

Historically, data has existed in silos – sometimes intentionally, but often through a lack of integration into other systems that sit nearby but are just out of reach for one reason or another. In what we call a centralised system, everyone needed to go to that single silo to access the data; we must trust the owner of that system to protect it, and trust is not cheap.

Alternatively, we can take that data and distribute copies of it across a network of participants. We establish common rules about who can view and/or change the data, and we update all live copies of the data simultaneously according to those rules. Nobody can override the data on their own – all changes are agreed upon programmatically and carried out by consensus. Varying levels of decentralisation can be implemented, depending upon your requirements.

Moving away from data silos is the essence of DLT, and we’ll go into why this is so interesting shortly.

But hang on; where do all the Bitcoins come from?

It’s probably worth a quick detour to that sinister, mysterious land of cryptocurrencies at this point. Firstly, contrary to popular opinion, cryptocurrencies such as bitcoin are not blockchain. I hate to labour the point, but this is important, and there is a key distinction: 

Cryptocurrencies use blockchain and DLT to maintain their ledgers

To see bitcoin as blockchain is as incorrect as saying eBay is the internet; eBay makes use of the internet to provide the services it offers, but the internet can be used for far more than selling your old kettle. McKinsey released a great piece on blockchain earlier this year, which covers this in more detail, and I highly recommend giving it a read.

Cryptocurrencies are a great example of blockchain and DLT in action. Most cryptocurrency implementations use public, ‘permissionless’ ledgers; they allow anyone who wants to participate in the network to download a copy of the distributed ledger, verify incoming transactions and propose new ones. Protective measures are added to discourage malicious actors from attempting to abuse the system – this is where the term ‘mining’ comes in and is what necessitates the bitcoin network’s high energy consumption.

In terms of blockchain/DLT applications, cryptocurrencies are technically feasible because they track ownership of purely digital assets –no link to the ‘real world’ is needed to verify if someone sent someone else their bitcoin, for example, as there is nothing physical involved. Once we look towards other industries, which are concerned with locating, tracking or trading physical assets, then things become slightly more complicated, and this is where it becomes important to see these new technologies as enablers rather than solutions. Connecting digital systems to physical items is an entire industry in itself, and blockchain/DLT cannot fix that problem alone, but they can offer a means of validating and sharing data between the new generation of sensors and systems which do.

What does this all mean for me?

The sheer breadth of possible implementations will manifest themselves in different ways for different industries, but I think it is unlikely any industry, which involves people interacting with other people, will remain blockchain/DLT-free in the long term.

Few businesses operate in isolation; whether you primarily deal with suppliers, customers or both, there are often bottlenecks and points of friction at the interfaces. DLT offers the opportunity for trustable data to be shared widely and quickly across those interfaces; by providing a base layer of mutually agreed information you can all act sooner, saving money and time.

The nature of your industry will dictate the value and speed of adoption of these technologies to some extent. Do you work within the public sector and face scrutiny over the decisions that your business makes? If so, a public, permissioned network may improve visibility and accountability without giving away the rights to add new data to the ledger. Are you more concerned with B2B/B2C sales and need to keep your operational data private for commercial sensitivity? A private, permissioned network might make more sense if so, with relevant access rights granted to ensure your customers cannot pry into your transactions with their competitors.

But it’s not good for everything, right?

That old expression “to a hammer, everything looks like a nail” comes to mind here, and as with any other technology there are situations where the application of blockchain/DLT will be valuable and there are situations where other tools are better suited to achieve the desired result. It’s important to know when you don’t need blockchain as much as when you do, and once again the answer to that question often depends upon the person you’re asking.

In the business world there’s always a risk that new technologies are asked for because they’re new and exciting. It is important not to get caught up in the hype and instead to focus on defining the problems you face, and then appraising the tools which are available to you before getting started on creating a solution.

Permissioned blockchain and DLT implementations can operate much, much faster than the permissionless networks supporting cryptocurrencies, but if you are running an internal blockchain between people you already know and trust, then you’ve just created a complicated database. It’s become a bit of a cliché in the industry that “blockchain is a team sport” but the sentiment is valid; it’s hard to share information if you’re the only one who can see it!

On top of that, any data structure is only as good as the quality of the data it contains, so if your existing data is garbage then blockchain and DLT will do a great job of recording that garbage for you, but do not expect it to fix the underlying issue.

Conclusion

Blockchain and DLT boil down to a novel application of established cryptographic processes. They won’t fix the world in isolation, but they do offer us new methods of trusting and sharing information, and it’s going to take some time before we truly understand their full value. But please, don’t take this as a call to ‘blockchain all the things!’

Instead, I’ll leave you with an analogy:

Imagine you arrive home one evening and find water all over the hallway floor. You don your wellies and trace the leak to its origin, which narrows down your definition of the problem (“my floor is wetter than normal” becomes “there’s water gushing out from behind my washing machine”). Now you’ve gathered this information you act upon it, turning off the water at the mains rather than rushing to drain your heating system. With the problem under some semblance of control, you seek help. You call a plumber, rather than an electrician or a hairdresser. You’re not necessarily sure which tools the plumber needs to bring with them, but you do know they’ll have the tools and expertise needed to fix the problem.

I’d like you to view blockchain, DLT or any other new technology in the same way. Firstly, define your business problem – and your problem shouldn’t be “I don’t have a blockchain”. Narrow the problem down as far as possible, and then ask yourself what’s stopping you from solving it. Identify the changes needed (“I need better access to information from my suppliers”) and then you can begin to evaluate the suitability of potential technologies. Ultimately, blockchain and DLT are tools, and tools are only useful for specific problems – you need to know the problem you want to fix before you can chose the right tools for the job.

Tom Collingwood, Blockchain Technical Specialist, Hartree Centre
Image Credit: Zapp2Photo / Shutterstock