Immutability

Another day another flood of articles, blogs, PR pieces and opinions about Blockchain.

I am no blockchain expert – but I do have a bit of an idea what it is all about and why people are so excited about it. Having said that blockchain is clearly still in the realms of a solution looking for a problem – if you exclude crypto-currency as the problem.

My BS detector goes off big time when this “peer-to-peer network” of “independently controlled nodes” where “every participant is equal to all others” and “there is no central authority” is being flogged by the very same central authorities it was designed to bypass.

However one attribute of blockchain is very interesting. Immutability.

Immutability means that once a block is created and inserted into the blockchain it cannot be modified without the consensus of the blockchain participants.

This is a very useful characteristic. Take, for example, a bank account as shown in this sample statement. (Source)

Immutability means we can’t go back and modify a transaction, nor can we insert a new transaction into the sequence of transactions.

Double entry book keeping principles mean that for each transaction posted to this account there has to be at least one other countering transaction to balance it. For example each “DEPOSIT” appears in this account as a Credit – so there would be a corresponding Debit transaction in another account called something like “Money Bank Owes Customers”. And for each “WITHDRAWAL” that appears here as a Debit there will be a corresponding Credit – possibly also to the “Money Bank Owes Customers” account.

A single business transaction means there are at least two transactions created and posted to two different accounts which must never be changed. Reversals and adjustments require reversal and adjustment transactions – not changing the original transactions. This provides a clear and verifiable audit trail of everything.

Before computers came along white collar crime could take the form of a creative accountant with some liquid paper and an array of coloured pens. These days financial systems have strict controls around data security but technically you could bypass these controls – if you knew how – and adjust the data to present “alternative facts”.

So immutability is important.

Guess what other technology provides immutability? SAP HANA.

That’s right the column store in SAP HANA is “insert-only”. You cannot modify any data once it is inserted. You have to insert new data that supersedes the old data. Essentially each record as a “start-of-life” and “end-of-life” timestamp that defines it’s relevance. Similarly you can’t delete data either.

Of course this characteristic is hidden from everyone by Structured Query Language (SQL) – the lingua franca of the database management system. When a developer says …

UPDATE Customers
SET ContactName = 'Alfred Schmidt', City= 'Frankfurt'
WHERE CustomerID = 1;

… HANA inserts new records for Alfred Schmidt and Frankfurt and starts their lives while ending the lives of their predecessors.

But those predecessors are still in the HANA database and to my mind could be used to fully reconstruct an audit trail of the customer records for CustomerID 1 at any time. As it stands good old SQL abstracts this “expired” data from the database consumer – but I don’t see why it couldn’t be used to provide an immutable audit trail of all changes to a record or a complete dataset.

It could even be represented as a linked chain of blocks showing each update to the dataset. Sort of a block chain. 😉 #seewhatIdidthere

You could even time travel back and forth through your dataset. Fascinating!