Immutability is one of the key characteristics of Blockchain. The ability to resist change and remain unaltered, indelible even in a decentralized, distributed environment is what makes Blockchain interesting for those who seek accountability and trust in the system. However, we should not forget that even with all the automation, there is still some “human” involved in Blockchain. For instance, it is a human who is the end user of apps running on Blockchain, it is a human who codifies the agreed upon terms and conditions into a “smart contract” which if not done correctly leaves the system vulnerable to misuse or mistakes. Improvements and more importantly corrections have to be routinely addressed and blockchain systems created, governed & used by humans are nothing different. Malicious content circulating in the network, an individual’s right to be forgotten, fraudulent transactions recorded on Blockchain leads us to a situation where immutable chains have to be circumstantially made mutable.
Before going into a deeper debate on why and how blockchain can be made editable, we need to understand some basics as to what constitutes a block and by-extension blockchain. A block generally includes
1. Transactions, essentially the data that needs to be recorded
2. Transaction root hash or Merkle root (hashes are created for every transaction considered for the block, which are then hashed multiple times till a single hash value remains)
3. Previous block’s hash
5. A random value to make the final block hash difficult to predict or replicate.
Every data or content recorded on blockchain is submitted as a “transaction” to the blockchain network and is verified by validator nodes / computers / servers which play the role of a trusted authority in a decentralized environment. These validators arrive at a consensus on the validity, order & timestamp of the transaction. All verified transactions are grouped as what is called a block which is “linked” using the previous block’s hash, thus forming chain of blocks a.k.a blockchain.
Immutability is one of essential features to maintain the integrity of blockchain and ensure no data is added or removed without being evident thereby making blockchain tamper resistant.
Why do we would need to then circumvent one of the strongest feature of blockchain and edit the non-editable chain?
Malicious Content Removal — Peer to peer networking, anonymity, lack of central auditing and censoring entity, basically lack of supervision will, at times give way to use blockchain based applications to upload and share malicious & libel content.
Data Privacy, Private Data Protection — Today, organizations are toying with the idea of using blockchain for storing sensitive information like healthcare records, criminal records. These records identifying an individual needs to be selectively available and need to be generally anonymized.
Data Access Control — In the era of GDPR or equivalent data protection regulations, it is quite vital to give the user total control of their data which means user has control & information over not only by whom, when & how their data gets used but also on what part of their data gets used. What this means for blockchain is that the data in the blocks need to be selectively given access to and more importantly some data should not be given access to.
Revert fraudulent transactions — Though not advised, if a situation thus occurs where a malicious attack on the network or loop holes in the codified contracts results is monetary loss, editing the chain can be considered as an option to revert the transactions .
Now that we have established editing blockchain can have a valid reason, we will proceed to the mechanisms being explored today.
One of the essentials to be included while designing mutability into any Blockchain platform is to have a strong redaction / mutation policy in place. This policy should clearly define who, under what circumstances can change the contents of an existing block and how to ascertain valid block edits as against attackers trying to tamper the data on the blockchain.
Some of the mechanisms which I have come across as follows-
Chameleon hash as the name suggested is a technically a hash which masks itself like a hash but is not really one. General definition of hash is that it is not reversible, i.e. you cannot get back the original content from the hash. However, the nature of the chameleon hash allows the retrieval of the original content while in possession of a secret key called as trapdoor key.
How does it work?
Let us take Matt and Sarah’s help in understanding this concept.
Matt is an attacker planning to post some abusive content on a website running on a blockchain platform. He submits the content as a transaction to the blockchain network. This transaction will be signed by Matt using his public key generated using the Chameleon hash function key generation algorithm. This algorithm generates another key called as “trapdoor” which is available with the validator nodes / miners. A unique hash of this transaction is created. The hash is calculated using the transaction, Matt’s public key and a random value. The resulting hash and the random value called as “check string” gets added to the new block. At this point, Matt has successfully posted the abusive content on the network.
Sarah comes across this abusive content on the web and determines to get the content deleted. To do so, she need to place a redaction request. She gets the information regarding the abusive content, such as the block which has this abusive content and the check string by querying from blockchain. She then submits a request by including the block identifier and the details of the transaction that needs to be redacted / removed. The request is validated by the miners or validators who then will use the trap door key corresponding to Matt’s public key to unlock the transaction hash, and generate a new random value using which even after removing the transaction, the transaction hash and by extension the block hash is not changed.
This mechanism comes handy in permissioned / consortium based blockchain network where the trapdoor key or parts of the trapdoor key can be shared between the known participants or in public network where either all the “miners” have the key or a subset of them.
One major drawback with chameleon hash is, since single key is used to encrypt all transactions of a particular user, once the key is available to others, it can be used any time to mutate any of that user’s transactions whether or not intended without leaving any proof. The original sender of the transactions has no way to prove that the transactions were mutated as there are no footprints left behind.
µchain overcomes this problem by enabling multi-key encryption. In this mechanism, multiple versions of the transactions exists as a part of a transaction set on the blockchain and each version is encrypted with a different key. The validators / miners of the network are custodians of the decryption keys. Only one of the versions is active and hence decrypted at any point in time. A mutation policy is defined with conditions under which a particular transaction is decided to be the active transaction.
How does it work?
Once again, Matt has posted the abusive content on to a blockchain platform, this time on a platform which enables blocks edits using µchains. Matt’s content is encrypted and stored as the first version of the transaction in a transaction set which along with the index of the current active transaction version (which is Matt’s version by default) and the transaction’s mutation policy is then included in the block. Matt’s post is now available for public consumption.
Sarah comes across this content, and she gets on her mission to get this content removed. To do so, Sarah follows 2 steps. First she submits a “extending” transaction in which she requests for creating an alternate version of the transaction in the same transaction set comprising of the abusive content. This transaction specifies the transaction set which contains the abusive content and a “Nope” transaction which is basically transaction with no or blank data (objective to redact the abusive content and not replace the content with another). This request is submitted to the validators who verify the request with the mutation policy. If satisfied, this transaction gets added as a new version in the transaction set specified in the request.
Sarah has her data (or the lack of) added to blockchain. She now needs to make this version active in order to be able to prevent the abusive content from being accessed. To do so, she submits a “mutant” transaction in which she requests for making her version of data active thereby theoretically redacting the abusive content. This transaction is submitted along with the information of the transaction set and the version to be made active. The validator nodes like earlier will verify the request against the mutation policy. On satisfying the policy, the active version is updated to the new one and this along with the transaction set is included in the subsequent block.
Then on, this new version will be deemed as the only information available and the previous version will be as good as never existed.
Another example where µchains are apt would be in Decentralized Identity domains. Various versions of identity information can be stored on Blockchain and depending on the point of use, the corresponding version can be made active.
Case in the point is that there is no actual block mutation, no existing block content is changed, no block integrity is broken. Instead, what changes is the view that the users & validators have once the mutant transaction is recorded in the chain. When a query is made for the Matt’s content, the latest active index of the transaction is checked and only that record in the transaction set is decrypted using the key available with the validators and hence not Matt’s, but Sarah’s version is what is returned as response.
These mutations are retroactive, i.e. once mutated, the validators read it as if the transactions were always that way. Each transaction in the set is encrypted with separate keys, and hence there is no single point in failure.
Voting based redaction
A drawback of µchains is since the mutations are retroactive, there is no accountability and verifiability in terms of how the transactions got updated.
The voting based redaction mechanism takes into account the necessity to retain the reference to the block which was edited thereby adding accountability to the whole process. This mechanism requires an edit to the current block structure and additionally capture old transaction root hash in addition to the current transaction root hash.
How does it work?
As earlier, Matt has uploaded abusive content which got recorded on a blockchain platform.
Sarah comes across this content; the good Samaritan she is, takes up the mission to redact this content. To do so, she submits a request to the validators or miners with the info on the content she wants to be redacted and the index of the block having this transaction. A redaction policy defined provides the guidelines to ensure no transaction other than the one in question is redacted, redaction does not change the votes garnered by the previous redactions and in cases where cryptocurrency is involved, does not involve spending already spent coins. The policy also defines the required number of votes and voting time period.
Once Sarah’s request reaches the validators, her request is verified against the redaction policy. If found valid, the nodes vote by adding the hash of the request as one of the transaction to the next block they create. The proposed block edit becomes a candidate in the voting process and is added to a candidate block pool. The voting process continues for the voting time period and nodes validate & add the same request hash to all the blocks created in this period. If the number of votes garnered exceeds the threshold set in the policy, Sarah has won and her request is executed. The block ID specified in her request is edited to remove the record, the block hash is recalculated.
However, the integrity of the chain is impacted and chain is broken as the next block in sequence after the modified block will not have the same parent hash as the newly calculated hash and will still have the old hash of the modified block. Now, when such a scenario is encountered, the validators can ensure that this is authorized edit and not a tampering attempt by verifying if the broken link has garnered sufficient votes to do so.
There is accountability in this method where at any point in time, the user can verify if the rules were followed while editing the transactions. However, since this mechanism involved breaking the chain, the block integrity is lost.
In addition to this, there are other forms of block edits such as hard forks to return the chain state to one of the earlier version but these can be proposed and edited only by certain entities with admin privileges which would mainly be a team of core developers or a governing council. This would however undermine the trust and most importantly result in splitting of the blockchain.
In summary, immutability is one of the key features which makes blockchain an attractive & appropriate technology to use especially where participating entities do not trust each other. Frequent editing of the chain requires additional governance overhead and would result in security issues if not handled properly. I would not recommend compromising this unique feature and go about editing the blockchain network. In my opinion each instance of a editing needs to be individually considered and chain editing should not be encouraged unless there is no alternative. This would also bring in new avenues for blockchain such as storing biometrics data in decentralized ledger which can then be used by a network of multiple banks for account opening, transaction authentication etc and with selective mutability, deletion of records as and when needed. These use cases were previously could not be considered.
- Chameleon Hashes with Ephemeral Trapdoors — https://eprint.iacr.org/2017/011.pdf
- Redactable Blockchain in the Permissionless Setting — https://bernardomagri.eu/wp-content/uploads/2018/12/redactable_premissionless.pdf
- µchain: How to forget without hard forks. — https://eprint.iacr.org/2017/106.pdf
- Redactable Blockchain -