There seems to be a lack of — ahem — *consensus* around blockchain’s definition.

While the philosophical spectrum ranges from satoshi minimalists to mass enterprise adopters, it is important to first understand the technical componentry of blockchain in order to deploy it as a useful application. Here is a “feature-first” definition that may be useful in understanding these technical underpinnings:

Today, we’ll dive into immutability, a core defining feature of blockchain.

Across the hundreds of articles and conversations around Blockchain, you’ll find the term “immutable” almost always present. Immutability — the ability for a blockchain ledger to remain a permanent, indelible, and unalterable history of transactions — is a definitive feature that blockchain evangelists highlight as a key benefit. Immutability has the potential to transform the auditing process into a quick, efficient, and cost-effective procedure, and bring more trust and integrity to the data businesses use and share every day.

We spend trillions of dollars on cybersecurity solutions meant to keep outside prying eyes from accessing our sensitive data. But rarely do we fight the internal cybersecurity battle: ensuring that our data has not been manipulated, replaced, or falsified by a company or its employees. In many cases, we have come to simply trust that the data is correct by methods like private keys and user permissions. But in reality, we cannot prove — methodically or mathematically — that information in a standard application database is unequivocally tamper-free. Auditing becomes our next (and expensive) line of defense.

Blockchain implementation can bring an unprecedented level of trust to the data enterprises use on a daily basis — immutability provides integrity (both in its technical and primary definition). With blockchain, we can prove to our stakeholders that the information we present and use has not been tampered with, while simultaneously transforming the audit process into an efficient, sensible, and cost-effective procedure.

How Immutability is Achieved

A Brief Introduction to Cryptography and Hashing

Before we dive into blockchain immutability, we’ll need to understand cryptographic hashing. Here are the basics:

• A hash function takes existing data (an input like “Blockchain is Disruptive” in the example below…) and outputs a “checksum” — a string of numbers and letters that serve as a digital signature.
  
• The checksum is guaranteed to point to your exact data input — if just one byte is different between two files, the outputs after hashing will be two complete strings. One can liken this to an avalanche effect — a small change in your input can drastically change your output.
  
• Probably the most famous hashing algorithm, SHA-2 (and its variants: SHA-256 is the most popular in the blockchain world) was created by the NSA.
  
• The key utility in the hashing process is that you can’t reverse-engineer a hash. In other words, you won’t be able to work backward from an output string to determine the input data.
  

Want to test out some basic hashing? Here is a free Sha-256 hash calculator: http://www.xorbin.com/tools/sha256-hash-calculator

Cryptography + Blockchain Hashing Process = Immutability

Each transaction that is verified by the blockchain network is timestamped and embedded into a “block” of information, cryptographically secured by a hashing process that links to and incorporates the hash of the previous block, and joins the chain as the next chronological update.

The hashing process of a new block always includes meta-data from the previous block’s hash output. This link in the hashing process makes the chain “unbreakable” — it’s impossible to manipulate or delete data after it has been validated and placed in the blockchain because if attempted, the subsequent blocks in the chain would reject the attempted modification (as their hashes wouldn’t be valid). 

In other words, if data is tampered with, the blockchain will break, and the reason could be readily identified. This characteristic is not found in traditional databases, where information can be modified or deleted with ease.

The blockchain is essentially a ledger of facts at a specific point in time. For Bitcoin, those facts involve information about Bitcoin transfers between addresses. The below image shows how the checksum of transaction data is added as part of the header, which, in turn, is hashed into and becomes that entire block’s checksum.

Benefits, Explained

Why does immutability matter? For the enterprise, immutability as a result of blockchain implementation presents a serious overhead saver as well as simplified auditing efforts & fraud prevention. We’ll break these concepts down:

Complete Data Integrity — Ledgers that deploy blockchain technology can guarantee the full history and data trail of an application: once a transaction joins the blockchain, it stays there as a representation of the ledger up to that point in time. The integrity of the chain can be validated at any time by simply re-calculating the block hashes — if a discrepancy exists between block data and its corresponding hash, that means the transactions are not valid. This allows organizations and its industry regulators to quickly detect data tinkering.

Simplified Auditing — Being able to produce the complete, indisputable history of a transactional ledger allows for an easy and efficient auditing process. Proving that data has not been tampered with is a major benefit for companies that need to comply with industry regulations. Some common use cases include supply chain management, finance (for example, Sarbanes-Oxley disclosures), and identity management.

Increase in efficiencies — Maintaining a full historical record is not only a boon to auditing, but also provides new opportunities in query, analytics, and overall business processes. FlureeDB, for instance, takes advantage of the concept of time travel for business applications — where queries can be specified as of any block — or point in time — and reproduce that time’s version of the database, immediately.

This capability allows for a host of time and cost savings — including tracking the provenance of major bugs, auditing specific application data, and backup and restoring database state changes to retrieve information. Immutability can make the most modern-day data problems that plague enterprise applications irrelevant.

Proof of Fault — Disputes over fault in business are all too common. The construction industry accounts for $1 Trillion dollars in losses as a result of unresolved disputes. While blockchain won’t wholly dissolve this massive category of legal proceedings, it could be leveraged to prevent a majority of disputes related to data provenance and integrity (essentially proving who did what and at what time).

Blockchain finality allows us — and a jury — to fully trust every piece of information.

Fluree secures every transaction — proving who initiated it, when it was completed, and that it is free of tampering.

It even tracks the changes a SaaS vendor makes to your transaction before it reaches the data storage tier, meaning you can trust your SaaS data without fully trusting your SaaS vendor:

The Asterisk to Immutability

Immutability ≠ Perfect, Truthful Data

Blockchain is a mechanism for detecting mathematical untruths, not a magical lie detector.

Blockchain doesn’t inherently, automatically, or magically make data truthful — its implementation merely cryptographically secures it so that it will never be altered or deleted without consequence. Measures such as sharing your hash outputs directly with stakeholders (customers, auditors, etc.) or setting up a decentralized network of validation nodes are a good complement to the historical immutability the blockchain hashing process provides, to ensure an often-needed validation component.

In addition: the stronger the enforcement rules, the more reliable the data on the blockchain (Exhibit A: Bitcoin’s proof of work).

FAQs on Immutability

What are the disadvantages of immutability? How can they be avoided?

Having an unalterable history of transactions seems like the answer to many modern business problems — and it is, in many ways. But what happens when sensitive data — like employee’s home addresses — is accidentally published to a blockchain? Hopefully, this wouldn’t be an issue, as standard design decisions in building blockchain environments necessitate a separation between sensitive and personally-identifying information.

If running a private, federated blockchain, your company would have to convince the other parties to agree to a “fork” in the blockchain — where a blockchain splits into two paths and the new designated database continues on. All or most parties involved in this blockchain will have to agree on the terms including which block to fork at and any additional rules of the new database. If this blockchain is truly public, it is next to impossible to have this information removed (a hard fork is also required here, but you are much more unlikely to convince the other parties in the network to comply).

In terms of Databases and Infrastructure, isn’t holding the entire transaction history very costly with regard to space?

Holding every database state might have been costly in the 90s, but current storage costs (1GB in AWS = $.023) are incredibly cheap. And the benefits (data integrity, ability to issue queries against any point in time) far outweigh the slight cost difference.

Fluree offers an ACID-compliant blockchain distributed ledger that records every state change in history as an immutable changelog entry. It allows for powerful query capability with FlureeDB, a graph query engine. By bringing blockchain to the data tier, Fluree is a practical and powerful infrastructure on which to build, distribute, and scale custom blockchains.