Trust is the 5th Coupling in a Distributed Systems: Blockchain is poised to loosen it
by Frank Leymann & Srinath Perera
Four Aspects of Coupling
Systems we build change. A system in active use undergoes changes to keep up with a changing world. The primary goal of architecture is to build systems that ease this process of change.
To ease this change, we divide and conquer. We break the system into loosely coupled parts so that we can develop, analyze, understand, and change each part as independently as possible. Modules, functions, objects, components, services, and microservices are examples of efforts to break systems into such independent parts.
We want to reduce coupling breaking systems into parts. Yet, the different parts must work together. Hence, it is impossible to decouple a system completely. So we strive for loose coupling. The degree of which is measured in terms of four aspects of autonomy (the more autonomy the better):
- Time autonomy — it allows a constituent to react at unpredictable points in time. E.g. because a constituent realizes changing workload; or it crashes and must recover, etc. etc.
- Reference autonomy — a request is not sent to a specific constituent. E.g. because several constituents implement overlapping functionality; or because a new version of a constituent is installed, etc. etc.
- Format autonomy — it allows that the sender of information and the receiver of information don’t have to agree on upfront on the exact syntax of the information. E.g. because different versions of the sender or receiver produce or expect different kinds of information; or because different representations of the information are used (CSV vs JSON,…), etc
- Platform autonomy — it allows interacting constituents to be implemented based on very different technologies. E.g. because the constituents are developed at different points in time, with the technology being fashionable then; or the constituents have been developed based on the technology most appropriate for their purpose, etc.
In this article, we argue that trust can be also considered as another form of coupling, the fifth aspect of coupling.
Understanding Trust
Constituents of distributed systems communicate through a potentially untrusted network. Therefore, each such communication is untrusted. Communication may take place before trust is established: each participant may decide to trust a party or not once it receives a message from another participant. Trust between each participant is established as needed.
What is “trust”? Oxford dictionary defines trust as “firm belief in the reliability, truth, or ability of someone or something.” In systems, it is the firm belief that a system, subsystem, or a participant in the system will behave according to its/ his/ her role.
Trust is based on an authenticated identity. Such identity is the basis for authorization; authorization is meant in a broad sense, e.g. authorization to debit my account and send the corresponding money to somebody else. The authorization includes the strong assumption that the authorized subject will behave according to established rules, e.g. that in a funds-transfer the sum of debited amount and the credited amount is the same.
Most of our systems establish trust through out-of-band means. In some cases, the designer makes sure everyone in the system is trusted by the use of firewalls. In other cases, DevOps people configure the credentials to use. In the second case, not everyone is trusted, but some trust links are already established. It is important to note that credentials do not represent trust established, rather they are the mechanism to convey trust. Trust is established when the credential is shared.
Fifth Coupling
Today’s enterprise integration solutions assume a set of participants with correct credentials are already in the system. Once they are inside the system, they have broad access to the system, and their trust levels stay mostly constant. By assuming such kind of “trusted participants” the resulting integration solution is very flexible: one can exchange, evolve, add constituents without having the be concerned about trust. Thus, we can argue that trust is a “hidden” autonomy aspect of loose coupling. Because trust between participants is already established, we argue that they are coupled. For example, they can’t change their trust behaviors in the middle of interactions.
Today’s integration solutions are mostly “closed” in the sense, that the interacting constituents are known in advance. Thus, trust is no explicit concern but implicitly assumed (otherwise a constituent is not added to the system). Other autonomy aspects must be explicitly dealt with, e.g. a mediator must be added to adopt the format requirements of the new component.
In contrast, in an “open” environment, trust cannot be implicit, it must be folded in explicitly to support flexibility in adding new constituents to the system that are not known in advance. We can envision systems where the trust relationship is not assumed and as part of the operation, trust is established. For example, technologies like blockchain make it possible to implement such use cases. Using a decentralized identity a system may verify some property of the user as part of the transaction without human involvement.
An Example
Let us take an example. If you consider a bank, to be part of the system, you need to go through a registration process where they collect information about you, get your signature, check your documents. After these checks, if you pass, trust is established and you are allowed to participate in the system. However, as long as the software system is concerned, trust was established by a separate process, not the system. We argue that participants, in this case, are coupled by the pre-established trust. The coupling is often expensive as they need complex offline processes.
In contrast, with a system such as “blockchain verifiable claims”, the system can interact with untrusted individuals and establish trust on-demand. Also, the system may provide different levels of capabilities based on the level of trust possible. In this setting, trust is a dynamic entity in contrast to pre-establish static entry in our systems. For example, if the participant is missing a payment on a loan, that may be a signal that his trust levels should be adjusted.
However, it is worth noting that although due to its distributed nature, blockchain is a natural choice to build systems loosely coupled in trust. Similar ideas can also be implemented using other means. For example, a system can adjust the access levels of a user based on his behavior.
Conclusion
In conclusion, we argue that trust is also a coupling dimension. Systems that have autonomy in this dimension can work with untrusted parties and evolve trust with time.
