Miracle Cure or Snake Oil?

By now, we’ve all heard about blockchain technology—or least its famous progenitor, Bitcoin. According to its evangelists, blockchain technology will secure our records, protect our privacy, democratize our technology, and probably fix us a cup of tea in the process. Blockchain’s detractors tend to agree with John Oliver’s takedown of Bitcoin and other cryptocurrencies as, “Everything you don’t understand about money combined with everything you don’t understand about computers.” So, what’s the real deal? Is blockchain technology the miracle cure that will soothe the aches and pains of digital Information Governance? Or is it just so much snake oil?

What is Blockchain?

That one guy who only wears t-shirts with memes told you that blockchain is the future. So why is it so hard to find out what blockchain actually is? In part, it’s because there’s no agreed-upon definition as to what constitutes a “blockchain,” and in part because there are actually a number of different kinds of “blockchains.” While academics can debate the nuances of exactly which technologies are and aren’t “blockchain” (and if that’s your thing, hit me up!), a blockchain can be understood as:

• A distributed ledger with a decentralized architecture
• Where transactions are:
  • Immutable
  • Secured through cryptography

“There’s no agreed-upon definition as to what constitutes a “blockchain,” and in part because there are actually a number of different kinds of “blockchains.”

Let’s break each of those down.

A distributed ledger, or distributed ledger technology (DLT), is its own technology—of which blockchain is a form. A distributed ledger is a database of transactions. The “distributed” part comes in from the fact that every computer or server running the ledger (every “node”) runs that ledger in its entirety; there is no master-slave or master-copy setup. With a decentralized architecture, there is no centralized control over who can participate in the ledger. Instead of a centralized authority—say, Janice in accounting—maintaining the ledger, each node can construct and record its own updates to the ledger. The nodes then all vote on whether each update is valid and what order they occurred in through a consensus mechanism. While different consensus mechanisms operate differently, they all trust math (instead of Janice in accounting). This is why blockchain is considered a “trust-less” technology: there is no human or institutional intervention necessary to verify transactions. If the nodes reach consensus that a transaction is valid, it stays. If the nodes find a transaction invalid, it must sashay away.

Transactions on the blockchain are made immutable and secured to the blockchain through a clever bit of math. With a blockchain, each transaction is cryptographically hashed—a cryptographic hashing algorithm makes an alphanumeric “fingerprint” of the transaction based on its exact content, down to the bit. A block of ten transactions will have ten hashes. Those hashes are then all hashed together to make the block hash. That block hash becomes the first hash of the next block, “chaining” all of the blocks together to make… a chain of blocks (or a “blockchain”).

See what I did there?

In the above illustration (which uses simple addition, as opposed to the incredibly complex math of a real hashing algorithm), Block 2’s hash value is dependent on Block 1’s value; Block 3, in turn, depends on both Block 1 and 2. Changing the hash of any transaction—which, remember, happens when any bit of that transaction is changed—destroys the entire chain of hashes going forward. Because every block is unbreakably chained to the previous block, the blockchain is considered immutable. Furthermore, the cryptographic hash function works in such a way that it is virtually impossible to reconstruct the original transaction from its hash (much like you can’t build a person from a fingerprint). This means that it’s impossible to tamper and then go back and hide the tampering.

So What Can Blockchain Do for Me?

So blockchain is a new technology that uses math to secure transactions on a ledger that anyone can read or write to without permission from a central authority. So why do you—a busy information professional—care? Blockchain is way up in the hype cycle; your team might well be asking whether a blockchain makes sense for your organization. A few benefits of the blockchain get touted pretty often: a blockchain will make our records more secure; a blockchain is more private; or a blockchain is auditable. To evaluate whether a blockchain makes sense for your organization, you need to know how true each of those claims is.

Claims that blockchains are secure (or at least, more secure than other databases) rely on a few things. The first is the distributed nature of the blockchain ledger; being able to falsify records on the blockchain typically requires a “51% attack”—or gaining control of 51% of the nodes running the ledger. However, each user controls his/her/their own account through use of a private key; if that key is comprised, just like when a password is compromised, an attacker can then do anything the user could do. This is a real threat when considering the complexity of private keys and the elevated privileges in designs where a trusted body holds users’ keys in escrow. People are always a security threat; blockchains are no exception to
that rule.

The second element of the blockchain that leads people to claim it is secure is its usage of cryptography (such as the cryptographic hashing). People sometimes think this means data on the blockchain is natively encrypted. It’s not. In a public blockchain, like Bitcoin, transaction data cannot be encrypted; if it were, nodes couldn’t validate the transaction without decrypting the data. If every node in a private blockchain is going to decrypt in order to validate transactions, then you have to ask why you’re spending the time and money to encrypt in the first place. So, even though blockchains use public key infrastructure (PKI) and cryptographic hashing, there’s a whole lot of unencrypted data (which, remember, anyone running a node can read) running around on a blockchain. Since encryption is pointed to as a reason that the blockchain is both more secure and more private, it’s difficult to overstate how important it is to understand exactly what data is, and isn’t, encrypted when considering a blockchain solution.

Finally, claims that the blockchain will make records more secure often point to the immutability of transactions secured to the blockchain. It’s true: This is an excellent tool for ensuring the integrity of records. It also makes auditability a native feature of the blockchain. However, for records to be trustworthy—for information assets to retain their strategic or, in the case of litigation, evidentiary value—they must be accurate, reliable, and authentic.

Integrity is only half of authenticity.

Blockchain cannot ensure the accuracy of a record; it’s entirely possible for a user to enter a false or incorrect record onto a blockchain. Reliability is a condition of how a record is created; if Bob enters, say, an employee record into the blockchain without complying with the company’s record’s procedures, then that will be an unreliable record. Nothing that happens after a record’s creation can make it reliable.

Lastly, authenticity—of which integrity is part—requires that a record is what it purports to be. There is nothing in the blockchain that instantiates the archival bond, which means a blockchain doesn’t ensure a record’s authenticity. Creating, managing, and preserving trustworthy records in a blockchain solution requires a lot of thought to build and integrate features that are not native to the blockchain.

When Is a Blockchain a Good Solution?

Are blockchains a complete write-off? A fad, doomed to the dustbin of history with Betamax and MySpace? No! Blockchains are still a technology in development, but they offer an excellent solution when you need a database with shared read/write permissions, have low trust between parties, need disintermediation, and have relationships between the transactions in the database.

The threshold question, then, is why do you need a blockchain (as opposed to simply a secure database)? The best answer is that you have parties who don’t particularly trust one another, and you have some reason not to use a trusted third-party intermediary: cost, time, or simply the struggle finding someone all the parties can agree to trust. Like Information Governance itself, blockchain technology integrates social considerations of trust with data and technical considerations.

As such, blockchains are rarely a good solution for information assets within an organization; the problems of trust and disintermediation (theoretically) shouldn’t be an intra-organizational problem. However, they can be very useful for interorganizational Information Governance. Some of the problem spaces in which blockchain are being explored include land registries, supply chain management, food provenance, healthcare, and financial services. Examples include:

• The Linux Foundation’s open-source collaborative blockchain, Hyperledger, is being used by IBM to develop a banking application
• Oracle is developing preassembled, cloud-based, enterprise blockchain networks and applications
• The National Association of Realtors is developing a member-engagement data blockchain that allows permission-based access

For those cases where a blockchain makes sense, design matters.

Implementing a successful blockchain requires asking in-depth technical questions:

• What consensus mechanisms?
• Permissioned or permission-less?
• What data will be encrypted?
• What kind of transaction speeds do we need?
• How scalable does this system need to be?

But it also requires asking a lot of people- and organization-oriented questions.

• Why do we need a trustless, disintermediated system?
• What are we trying to fix by implementing a blockchain?
• How do we make this accessible and useable to the end users, so that they trust the system where they didn’t trust the previous processes?
• What regulatory challenges arise from using such a new technology?
• What makes the blockchain worth the extra investment, and how do we leverage that investment to maximize our return?

Implementing a blockchain should be a strategic choice.

Conclusion

Blockchains are new and sexy. They combine distributed ledger technology and cryptography in a way that lets transactions be processed without human intervention—and thus no need to trust human fallibility. But new and sexy is often the wrong strategic choice, especially if old and dependable is sufficient to meet organizational needs. Before implementing a blockchain, an organization should ask itself: Why?

Blockchain is fundamentally a technology that addresses a social problem—trust. For those cases where low trust and intermediation are problems, blockchain can offer a real solution to serious data management problems, bringing efficiency and transparency to processes that have long challenged inter-organizational Information Governance. However, in cases where trust is not the fundamental problem, blockchain technology is not the best solution. The key is asking what organizational needs a blockchain can meet that can’t be met by its plainer ancestor, the database. Blockchain probably won’t get us a cup of tea (though who knows where the Internet of Things will go), but it is a very useful tool to have in the toolbox, as long as one remembers that a hammer does not make every problem into a nail.