Dieser Blogpost ist auch auf Deutsch verfügbar
But which opportunities and risks the new technologies harbor for software architecture is rarely a matter of debate. I would like to give a brief overview of this issue.
Blockchain, ledger, cryptocurrency?
In the jungle of terms of the continuously emerging technologies, the core idea of blockchains is blurred: the “distributed ledger”. A ledger is a very old invention. It is characterized by the fact that new data sets or “transactions” can only be appended. This is in contrast to the classic database models, where entries can also be changed or deleted. The advantage of such an “append-only” storage is obvious: subsequent manipulation – whether it is intentional or accidental – thus becomes more difficult, because changes to a past transaction affect all later transactions and it would be necessary to perform them identically on all nodes involved.
If this list of transactions is stored in a distributed manner on several independent nodes, it is now being referred to as a distributed ledger. The key aspect here is that the nodes should not only be independent technically, but also organizationally. Such a decentralized architecture now also puts a stop to intentional manipulation, since no party can change a transaction in its locally stored ledger without the others noticing. From a technical point of view, hash functions – similar to Git – are used to safeguard the procedure.
Now, a blockchain is nothing more than a distributed ledger wherein multiple transactions are combined as blocks. This is usually done to improve performance. Most cryptocurrencies are based on this method; they bundle a number of payments and form new blocks at regular intervals.
Blockchain or database
Blockchain technologies can be a helpful tool in many organizations to model business processes. However, the fact that only a few use cases are suitable for this must be considered. While blockchains are interesting from a technical point of view, they also pose operational challenges. The advantages and disadvantages of different architecture options must therefore be carefully weighed up. Roughly speaking, three such options are in competition with each other:
- public blockchains as application platforms (such as Ethereum),
- private blockchains with access control (such as Hyperledger Fabric or R3 Corda),
- classic database solutions (such as PostgreSQL).
The last option is usually well understood by both software architects and developers and is therefore particularly suitable for projects in which existing systems must be connected. Database systems also provide a high degree of flexibility.
However, it is a critical factor that the operation of databases is usually centralized. If several partner organizations are involved in a project, conflicts may occur. In this case, private blockchains (option 2) are an alternative since each party involved can operate nodes. The built-in consensus protocols ensure that there is always a globally consistent view on the stored data and discrepancies can be identified immediately. The clear advantage here is that no trust is required between the parties; contrary to the operation of distributed databases.
The last two options have in common that they require specifically operated infrastructure. That is not the case with public blockchains (option 1) because interested parties from all over the world participate in updating the system. However, this is where the greatest risk occurs because availability is by no means guaranteed. Transaction speed and its costs are also subject to wild fluctuations.
Cost factor operation
It is difficult to clearly rank which of the aforementioned options is the most cost-effective to operate. Let’s take a look at private blockchains, for example: Hyperledger Fabric is a complex system that consists of several node types. It can certainly be operated in common container infrastructure such as Kubernetes, but that requires experience in administration.
Various cloud providers also offer “managed blockchain”; however, this is a contradiction in terms, since blockchains can fully unfold their strengths in a decentralized architecture only. There is no way to avoid a dedicated infrastructure.
If a classic database is chosen as the persistence layer, additional effort is required to archive the entries in an audit-proof manner.
Transactions & Data privacy
The term “transaction” suggests that distributed ledgers are suitable for financial entries. These often involve a regulatory interest in permanently storing them in a tamper-proof manner.
But in many organizations, the data model does not primarily consist of such events. Techniques known from domain-driven design, such as event sourcing, can help to identify suitable events in a business domain that can be stored on a blockchain as atomic transactions.
Especially when personal data is involved, the main focus must be to ensure that the rights of the data subjects are protected: after all, it would not be GDPR-compliant to reject deletion requests per se because they are technically immutable. A common solution here is to store data fields such as names or addresses encrypted with individual keys and to store these keys separately. As an alternative, it is possible to maintain only hashes of datasets in the blockchain.
Architecture means compromise
The blockchain does not render architecture work redundant either because it is far from being the universal solution it is often praised as. Quite the contrary: Distributed ledgers as persistence – or even as platforms for smart contracts – have specific challenges, which is why it is often inadvisable to use them.
In any case, it is clear that a lot of innovation is happening in this field. Their development is comparable to that of NoSQL databases. Once ridiculed, they now occupy a permanent place in the software development toolbox. To achieve that, they first had to cure their teething troubles, such as poor transaction semantics. The situation is very similar with blockchain technologies, which still have some catching up to do, especially in terms of performance.
In practice
Business processes in the finance and insurance sector in particular are suitable for blockchain. In the “B3i” consortium, industry giants such as Allianz, Munich RE and Generali have joined forces to process risk transfers through a distributed ledger platform. The project manages so-called “Property Catastrophe Excess of Loss” agreements, from their negotiation to their accounting. Another example: Just recently, the European Investment Bank, together with the Banque de France, issued a 100-million-euro bond, the shares of which were sold via the Ethereum blockchain.
Conclusion
In distributed organizations, where multiple independent parties read and write data, it pays off to take a look at the various blockchain technologies. However, one should be aware that the architecture and the integration with peripheral systems require quite some rethinking.
This article originally appeared on isaqb.org. It is published with the kind permission of iSAQB.