Audits through Merkle Root Hashes
Blockchain - The good partsPosted: 2023-06-09
When in doubt, sell shovels!
They say that during the gold rush only people who sold shovels made a fortune. We at Happi Hacking spent some time in the world of blockchains, learning how to build some pretty solid shovels. We took part in developing a blockchain (æternity) from scratch, including a smart contract language (Sophia), a VM (FATE), and all other infrastructure needed for running a public blockchain.
So, where should we dig?
The underlying math and cryptography used for blockchains are pretty solid. The foundation didn't originate in the blockchain world. Blockchain technology is merely an application of algorithms that can be found elsewhere in cryptography, for example in SSL/TLS where it is used for encrypting internet traffic (the padlock in your browser). It is also used in GIT, in distributed databases etc.
Merkle tries at a glance
We implemented Patricia Merkle Tries for æternity, and I personally got a bit of a crush on this data structure. I won't even try to explain how they work, but for this story the important bit is that the contents of a Merkle tree can be represented by the Merkle hash (or root hash) in a way that is unfeasible to fake (because of cryptography). The Merkle trie can in turn contain a huge amount of data, making the root hash represent all this data.
One way of thinking of blockchains is that it is a distributed database, whose state is represented by the root hash of its content along with the history of transactions. The only way of changing the state of this database is to add blocks of transactions to the database, yielding a new root hash that represents the new state and the new history. This is not the whole truth, but it is a reasonable abstraction.
Merkle tries and accounts
So what is the content of the database? This is up to the blockchain, but in the case of crypto currencies, there will be balances in some representation included in the database. Are there other domains where this setup is applicable? Obviously in banks, but also for ledgers in accounting.
Accountability and audits
Imagine that a company stores all its customer-related transactions in a Merkle trie. It is not necessary to use this trie as the actual database for the application, e.g., if it becomes too slow for operational purposes, but as crucial events happens (e.g., Alice sends Bob some money) the events could be imported into the Merkle trie, yielding a new root hash.
It is a property of Merkle hashes that they do not expose the content of the trie, at least unless you happen to guess the content of the entire trie. This means that the root hashes can be published to authorities, customers or even to the general public, without exposing the actual balances.
So, what good is publishing the Merkle hashes if it doesn't tell us what is in the database?
Proof of Inclusion
A proof of inclusion is a cryptographically safe way of proving that some part of the Merkle trie looks in a certain way given a specific Merkle hash. For example, given a root hash, you can provide a proof of inclusion that shows that a specific account had a certain balance in the underlying Merkle trie. And this without exposing the balances of any other account.
If an external entity collects the published root hashes, they can be used in a later audit to follow flows of money between certain accounts without compromising the privacy of other account holders, and since the root hashes were published at the time they were constructed, there is no way for the auditee to change the history of its database.
While public blockchains in general might or might not have a future, the underlying technology is alive and kicking. We have hinted towards one solid use case, but there are others. To name a few:
- Chain of custody applications
- Auditing election results
- Origin tracking of natural resources
If this blog post gave you some ideas, go ahead and contact us. We are always ready to build some new shovels!