Looking at Blockchain as Architecture

Seeing beyond the hype in blockchain, given the level of disruption and its game-changing potential, is not easy.

One way to answer is to look at blockchain, and other distributed ledger technologies (DLT), as a possible architecture for solving a non-trivial problem.

What problem? Creating a shared state (which includes ordering all the changes to this state) for several distributed entities which rely on asynchronous, potentially fallible communications only. Asynchrony means that there will be noticeable communication delays between participants and fallibility refers to the fact that messages (intentionally or not) may be altered or corrupted. Both factors make it quite difficult for all participants to agree on a shared truth.

As always in IT, there are several architectures that can satisfy this functional requirement. The key observation here is that – from an architectural point of view – one has to look at the non-functional requirements (NFRs) to be able to select the “best” solution for a given client context. The higher the degree to which an architecture option fulfills the set of (typically customer-specific) non-functional requirements, the more suited it will be in this situation.

I have depicted four possible architectures addressing the aforementioned problem, together with those NFRs that are most critical for selecting a blockchain solution (note that there are several other highly important NFRs for any IT solution, like availability, modifiability, usability, testability, security, which I have deliberately omitted here).

• Central system, run by a trusted 3^rd party. In general, having a central system run by a trusted (3rd) party is the simplest and most efficient solution you can ever get. Every entity easily connects to the central system that holds the shared state in a database (today that would be a cloud/SaaS solution). The first fundamental criterion separating this approach from the three others is trust. Basically, how difficult and costly it is to establish and enforce (!) trust over the lifetime of the solution
• Distributed system, where all entities would basically install the same (special) software. In the case of only a few (10 or so) participants you might want to think about deploying a distributed system where all entities would basically install the same (special) software. The takes care of the synchronization of the database holding the shared state. The European Union is doing that for some of their systems distributed among their member states – also because there is still a moderate level of trust between the entities (e.g., they are not malicious).
• A shared (communication) network, where the participants just send messages informing the others of certain changes. For more participants, albeit with noteworthy downsides, you can plainly adopt a shared communication protocol. Think of EDI (electronic data interchange) — where the participants just send messages informing the others of certain changes. Note that here the notion of a “shared state” including transaction (TX) transparency, TX finality (the time it takes to complete it) and auditability is maximally diluted.

Observe that, typically, none of these three architectures support the concept of “smart contracts” – i.e. the capability where entities develop, deploy, and run arbitrary (potentially shared) business logic on top of the solution.

• Blockchain and DLT are currently the only technologies available that allow a large number of non-trusting (even malicious) participants to reach consensus on a shared state without any trusted intermediary.

Hence, to the extent that your context does, indeed, ask for these specific NFRs to be satisfied, blockchain can be the optimal solution.

If you were able to relinquish even a few of the NFRs cited, then another solution could be better suited, especially considering that also blockchains come with some difficulties: Specifically change management in an immutable database and the difficulties in designing and operating very fast blockchains.

Architectures are selected by the degree to which they are able to economically fulfill a certain set of non-functional requirements. Forgetting this fundamental truth is, in my view, a major reason why we haven’t seen more really productive blockchain solutions.

Everyone is showing off what else blockchain is able to do — when the real question for a business is: For which problem do I really have to use blockchain. In other words, for which type of problems is blockchain the ONLY solution available?

As long as we don’t have a compelling answer to this one, blockchain will not be able to leave its current (early) state of pilots and proof-of-concepts.

One possible answer is the Internet of Things (IoT) (with IOTA as technology) – but that’s another post.

For more information on Cumulocity IoT please click below.