Minimum Viable Blockchain
--
I am currently on a bootcamp (hosted by Tech Educators) learning all things web3.
I am documenting some basic principles here, so I can check I have grasped the concepts correctly with my fellow bootcampees.
First up is the blockchain, a fundamental building block of the web3 tech stack. I am a Web 1.0 and Web 2.0 guy, so in the past when I have heard blockchain mentioned, I hear voodoo talk. This is because I find people often mix in many other web3 technologies and concepts when talking about blockchains, so it’s hard to know what’s going on (e.g protocols, cryptocurrencies, wallets, cryptography, mining, proof of work, politics, NFTs etc..). Usually, a simple question quickly becomes convoluted and confusing.
So I am trying to clear my decks, strip things back to first principles, and learn one concept at a time.
Goal of Blockchain
When Satoshi Nakamoto invented Bitcoin cryptocurrency, he also needed a very secure database to store the balances and transactions of users.
Traditional databases enable you to Create, Read, Update and Delete (CRUD) database records. Satoshi had a problem with the last 2 operations (Update and Delete), as this opens the door for bad actors to change the truth.
An example that perfectly illustrates this is when Puerto Rico Lottery was mysteriously losing money. In 2014 investigators analysed all aspects of the lottery operation, even down to how the lottery balls were manufactured, stored, moved and used. They could not find a fault anywhere. After viewing some CCTV footage, they accidentally noticed the irregular movements of the chief systems administrator (outside office hours). They discovered the chief was running 2 update statements every month, one to enable an accomplice to win, and one to cover up his tracks.
Blockchain databases only allow you to create and read data. You can only append data, all previous data is permanently stored and cannot be altered. If you change the past, then the whole database ceases to function, it breaks.
I understand there are many criticisms of blockchain technology, but perhaps this is because people do not understand that the goal of blockchain is to provide a tamper-proof audit trail of data.
To achieve this, many tradeoffs have been made that you would not otherwise be accepted in a traditional high-performance computing environment.
The super-simple explanation of a blockchain
Source of data
Currently, blockchains only store text-based data (so no images, video, binaries etc..). I never realised this before.
Secondly, due to the resource requirements to write data to the blockchain, you would only store data that is very sensitive to risks associated with data integrity. Otherwise, the tradeoffs (speed versus quality) would not be worth it, and you would stick with a traditional database and internal governance.
Blockchain databases are particularly suitable for storing transactional data which gets frequently updated. You would not store static data, like the names of all the cities and towns in the UK. You would also not store weather events, although it is transactional, it is not sensitive to risks associated with integrity (in most cases). You would store data related to ownership, in particular digital assets, such as cryptocurrencies.
Data does not get added to the blockchain as individual records like in traditional databases. All records are added to a queue and prioritised for processing into a package of records (a “block”), which is appended to the blockchain.
Writing blocks
The blockchain configuration will specify when data from the queue is persisted to a block (never to be changed again). This is usually when a specific threshold is reached, such as time (every ~10mins) or space (~1MB), or a combination of both. The data is written to a block in one batch, and removed from the data queue.
The data is usually encrypted or compressed into different data structures, so your original data will not be human-readable.
Each block is connected in a “link-list” to the previous block, so you can get a full history of all changes over time (note the arrows pointing backwards).
TIME — — — — — — — — — — — — — — — →
block 1 ← block 2 ← block 3 ← block 4 ← …
Change history
This basic construct provides the first use case of blockchain. It gives you a historic record of the state, making it very easy to go back in time, to check what was the state of the data in the past. Much like a version history within a word document, you can have an organised audit trail of unstructured data.
But, that does not sound very revolutionary, right? You could obviously store this data in traditional databases, relational, graph or NoSQL. In fact, blockchains are a type of NoSQL database, in that they store unstructured data.
Connecting the blocks
What is unique about a blockchain database is the backlinks [←]
TIME — — — — — — — — — — — — — — — →
block 1 [←] block 2 [←] block 3 [←] block 4 …
Each block links to the previous block using a very long string (call it a block id).
b7c4e74a39e2dded77f109befa46aafffc194835746015dd713c9fb727de72d1
This string is called a hash and is generated via a hash function using a cryptographic encryption algorithm, such as SHA256. A hash can take unstructured text, and generate a random string of a specified length. Moreover, it will always generate the same random string with the same input text every time.
Tamper proofing
Still does not sound impressive, right?
Hold on. The magic is the input to the hash function is all the data within the block (e.g. weather events in the last 10mins) AND the hash of the previous block.
TIME — — — — — — — — — — — — — — — →
block 0 [←] block 1 [←] block 2 [←] block 3 …[0] — — — [1]
[0] — — — [1] — — — — [2]
[0] — — — [1] — — — — [2] — - — — — [3]
With this structure, it creates a hardwired link from any block to all its ancestors. So the link from the current block to the previous block is reliant on all the links with all the blocks back to the first block (the genesis block). This means if you changed data in block 1, then all the links break.
TIME — — — — — — — — — — — — — — — →
block 0 [←] block 1 [←] block 2 [←] block 3…[0] — — — [X]
[0] — — — [X] — — — — [X]
[0] — — — [X] — — — — [X] — — — — — [X]
This core construct makes it hard to change history, as it requires you to delete all the blocks and recompute them. Not only is this computationally intensive, but it’s also hard to do without anyone noticing.
Conclusion
In summary, blockchains have a very simple data structure, they store data in blocks, each block is linked using magic links that make it impossible to change previous blocks without breaking the entire blockchain thereafter.
The blockchain represents truth, so if you change the past, the present is no longer the truth.
Technically you could run your own blockchain database, on a single node (“centralised” server). I don’t know why (and if) organisations actually do this. It would make sense as you would have a robust system to capture nightly snapshots of activity from your classic databases, giving you a tamper-proof audit trail of the most important activities within your org. A great infosec tool. There are solutions to do this.
Hyperledger is an open-source project that aims to create a suite of tools for enterprises to deploy Blockchain technologies quickly and effectively. The protocol is commonly used in Blockchain software solutions because it comes with its libraries that help to speed up development. The Linux Foundation is a strong supporter of Hyperledger, and it has supplied significant expertise to accelerate the creation of the protocol. Hyperledger is also highly compatible with Linux, so it is designed to work effectively on the same servers that are widely used in today’s business world.
However, because there is a centralised deployment, it is still not 100% tamper-proof, as you are the owner of the node that writes data to the blockchain.
The next blog posts will talk about the power of decentralisation and making blockchains 100% tamper-proof.
