Decen­tralized Architecture: What’s Behind Blockchains?

Fueled by ever new highs in cryptocur­rency prices, there is currently a lively debate about blockchains. Some praise the “self-sustaining” currencies as saviors in times of crisis, while others see their excessive power consumption as a climate killer.

But which oppor­tu­nities 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 contin­u­ously emerging technologies, the core idea of blockchains is blurred: the “distributed ledger”. A ledger is a very old invention. It is charac­terized by the fact that new data sets or “trans­ac­tions” 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: subse­quent manip­u­lation – whether it is inten­tional or accidental – thus becomes more difficult, because changes to a past trans­action affect all later trans­ac­tions and it would be necessary to perform them identi­cally on all nodes involved.

If this list of trans­ac­tions 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 techni­cally, but also organi­za­tionally. Such a decen­tralized architecture now also puts a stop to inten­tional manip­u­lation, since no party can change a trans­action 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 trans­ac­tions are combined as blocks. This is usually done to improve perfor­mance. Most cryptocur­rencies 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 organi­za­tions to model business processes. However, the fact that only a few use cases are suitable for this must be considered. While blockchains are inter­esting from a technical point of view, they also pose opera­tional challenges. The advan­tages and disad­van­tages of different architecture options must therefore be carefully weighed up. Roughly speaking, three such options are in compe­tition with each other:

1. public blockchains as appli­cation platforms (such as Ethereum),
2. private blockchains with access control (such as Hyper­ledger Fabric or R3 Corda),
3. classic database solutions (such as PostgreSQL).

The last option is usually well under­stood by both software archi­tects and devel­opers and is therefore partic­u­larly 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 organi­za­tions are involved in a project, conflicts may occur. In this case, private blockchains (option 2) are an alter­native 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 discrep­ancies can be identified immedi­ately. 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 specif­i­cally operated infrastructure. That is not the case with public blockchains (option 1) because inter­ested parties from all over the world partic­ipate in updating the system. However, this is where the greatest risk occurs because avail­ability is by no means guaranteed. Trans­action speed and its costs are also subject to wild fluctuations.

Cost factor operation

It is difficult to clearly rank which of the afore­men­tioned options is the most cost-effective to operate. Let’s take a look at private blockchains, for example: Hyper­ledger Fabric is a complex system that consists of several node types. It can certainly be operated in common container infrastructure such as Kuber­netes, but that requires experience in administration.

Various cloud providers also offer “managed blockchain”; however, this is a contra­diction in terms, since blockchains can fully unfold their strengths in a decen­tralized architecture only. There is no way to avoid a dedicated infrastructure.

If a classic database is chosen as the persis­tence layer, additional effort is required to archive the entries in an audit-proof manner.

Trans­ac­tions & Data privacy

The term “trans­action” suggests that distributed ledgers are suitable for financial entries. These often involve a regulatory interest in perma­nently storing them in a tamper-proof manner.

But in many organi­za­tions, 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 techni­cally 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 alter­native, 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 persis­tence – 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 devel­opment is compa­rable to that of NoSQL databases. Once ridiculed, they now occupy a permanent place in the software devel­opment toolbox. To achieve that, they first had to cure their teething troubles, such as poor trans­action 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” agree­ments, from their negoti­ation 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 organi­za­tions, 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.