Blockchain – A life saver?
Once in a while, Finaps receives a request to build software on top of a system of blockchains, or use blockchain technology. Especially around this topic, it is our job to ask “why blockchain?”. The problems our customers want to solve are real, and blockchain can be a solution. But often, there are better solutions our customers are just not aware of. In this article we will briefly explain another solution that we find more fitting in most of the requests we receive.
What is Blockchain?
A blockchain is a growing list of records, or chain of blocks (suitable name, right?). Once a block cannot contain any more data, it is converted into a unique hash (converted into a very big string of characters). A new block is created, with a reference to the hash of the previous block, creating the chain. As the references to the previous blocks are part of the blocks content, they will become part of the hash of the block itself. As this might be a bit too conceptual, we have visualised it on the right.
The ‘chain-of-blocks’ is managed in a distributed ledger. In a sense it is a big network of computers talking to each other. New transactions can only be added to the blockchain when there is consensus within the network. Consensus is reached through one of many complex automated algorithms. When consensus is reached, a new block can be created within the network.
NOTE: The complexity of the algorithm results in very high energy consumption and carbon emission.
Combining the idea of a ‘chain-of-blocks’ and the network it lives in, creates a sense of trust and safety in this concept. Remember the hash of a block? If we want to update data from an old block, we will have to update the hash. But this means that all newer blocks also need to be updated. Due the design of the network, this can only happen if you can get consensus, meaning you need to control most of the network.
For organisations, the appeal of blockchain comes when transactions or data is shared across many organisations and/or individuals.
One example could be within logistics, where freight companies can collectively add transactions about packages. This allows build a shared history about a package across freight companies.
This model is attractive, as no single source owns the data. It is not reliant on a Software-as-a-Service (SaaS) solution for all companies, and/or individuals to use the blockchain system. It is only needed to add themselves in the blockchain network.
Introducing event sourcing
Most blockchain requests Finaps gets do not fit this description. No collaboration happens with other organizations. When we dig deeper with our customers, we mostly find that transactional history and data immutability are core requirements. This concept should sound familiar to all of us. Just think about your bank account. It at one point started with a balance of €0, —. With each transaction, that balance changed, up to the point of your current balance. Your current balance is just a reflection of adding and subtracting all transactions from that initial balance.
Event sourcing, on a high level, works in a similar way. We start with an initial condition of the data aggregate. We call this the initial state of an aggregate. From there, we build an ‘append-only’ log of timestamped ’events’. These events can represent changes, status updates, transactions on the aggregate. They represent anything that might impact the shape of our initial state of the aggregate. Every time we want to have the current state of the aggregate, we take the initial state, and apply each of the events, in chronological order. Just like applying each transaction on the initial balance of your bank account.
This is a simplification of concept of event sourcing. The log of events holds great power in many applications. As we do not touch the initial data and the log is ‘append-only’, our data is safe from real changes. Just like with a bank account, if a mistake was made with a transaction, you must reverse it with a new transaction. Event sourcing works in a similar way. You are not allowed to remove or change existing events; you must add new events that reverse the faulty effect.
This immutable characteristic, combined with timestamped events enables you to build an audit trail or history log by default. Every change, every request is logged. When was an email sent? Who made the change? These types of questions can easily be answered when using event sourcing as a primary pattern in your solution.
Wrapping up
If you are looking for audit logs and immutable data patterns but are not collaborating with other organizations in the same network, blockchain is not for you. Blockchain has legitimate uses. Most of the requests Finaps get where an audit log and data immutability are required, can be fulfilled in a more efficient and maintainable way. Interested in more details, use cases and example cases for the use of event sourcing? Please reach out!
