Blockchain Trust Patterns You Need to Know
Everybody talks about how blockchain is crucial for trust. But ask five people what exactly blockchain “does” with trust, you will get five different answers. Is blockchain is trust-less, trust-enhancing, or trust-replacing?
The wording does not matter as long as you know how to use it and how it solves trust issues. This article will equip you with a toolbox of three blockchain trust patterns that you can use in your own business processes to mitigate trust issues and make the process better.
When thinking about blockchain and trust, we need to about the business process. Real-life innovation always needs to stand in the context of a process. When we have a process, we can describe how and when a blockchain can improve trust issues. In a nutshell: a blockchain can help to improve trust issues in a collaborative business process where independent organizations have to work towards a common goal while they only trust each other to a limited extend. (You can learn more about collaborative business processes in the first part of this series and about a classification of trust issues in them in the second part)
When we dig deeper into a process, we have to answer the following questions:
- Where in the process are uncertainties?
- Who is responsible for the uncertainties?
- What are the uncertainties concerned with?
Uncertainties are a concept related to trust. Whenever there are uncertainties, there is a need for trust.
Based on these three questions we can classify now three blockchain-based trust patterns that help us in our processes.
Pattern 1: Tamper-proof Hashed Data Storage
In collaborative processes, different companies often use shared data. In many cases, the integrity of such a common piece of data is a crucial trust concern. When data can be altered and manipulated, this might lead to anomalies and malicious behavior. For collaborators, it is hard to verify the integrity of the data and trace its provenance. Data integrity is an uncertainty where collaborators have to rely on the organization providing data. The blockchain technology can mitigate this uncertainty by storing data hashes to ensure data integrity.
Where it can help
For this pattern, we can answer the questions as follows:
- Where in the process are uncertainties? → At every point where data is consumed by one organization that another organization produces.
- Who is responsible for the uncertainties? → The company that creates or modifies the data initially.
- What are the uncertainties concerned with? → There is uncertainty regarding the integrity of data objects being used in the process.
How it works
In the tamper-proof hashed data storage pattern, the collaborator who acts as the data origin hashes the file. The hash is submitted through a transaction to the blockchain. A message with the hash is sent to data consumers. At any point in time, data consumers can verify the file’s integrity by comparing the hash of the received file with the hash on the blockchain. If the hashes do not match up, data has been changed. Based on this principle, many different applications have utilized the blockchain as a tamper-proof hashed data storage, for instance, to track data provenance in cloud computing or IoT-based collaborations. The verification of data integrity needs to be executed within the activity that consumes the data. Therefore, all interfaces to the blockchain need to be available to the activity.
With the hashed data storage pattern, the organization that is consuming the data within an activity can verify data integrity. However, how the organization processes the data within the activity cannot be influenced by this pattern.
Example
Think of the following situation: You got in a small car accident. Nobody got hurt, but you damaged the right part of the fender of another car. The car’s owner comes, sees the damage, and you agree to pay him 300€ to fix the fender. But later, the car owner thinks this is a good opportunity to get a completely new front for his car. So he intentionally damages the other parts of the car, takes a picture, goes to the police, and blames you. The police sees the picture and thinks you are the one responsible.
If you would use the tamper-proof hash data storage pattern, you could take a picture, hash it, and store it on the blockchain with a time stamp. In that way, you can always prove that you did not damage the whole front, but only the fender.
Pattern 2: Blockchain as a Transparent Event Log
Non-repudiation of event occurrences is a trust concern in collaborative business processes. When several companies work together, incidents like failures or errors in the process might imply following different workflows. One instance of this is the error event. It is essential that organizations cannot deny the occurrence of an event afterward to avoid compensation claims from other stakeholders. The blockchain technology can be used to ensure non-repudiation.
Where it can help
For this pattern, we can answer the questions as follows:
- Where in the process are uncertainties? → At any point where an event occurs that is important for the following workflow.
- Who is responsible for the uncertainties? → A company that might want to deny the occurrence of the event later.
- What are the uncertainties concerned with? → There is uncertainty regarding the non-repudiation of the event occurrence.
How it works
This pattern stores the occurrence of events and data related to them immutably on a shared distributed ledger. Technically, this pattern works similar to the blockchain hashed data storage trust pattern. The data related to the event occurrence gets hashed and submitted with a transaction to the ledger. This pattern also introduces a timestamp of the event. The raw text is shared with the relevant persons off-chain. By comparing the on-chain hash with the hash of the data received off-chain they can ensure the integrity of the event. Hashing the data provides data privacy to a certain extent.
Similar to the first pattern, this pattern comes with limitations. If the organization who caused the event also has the power to decide to keep the occurrence of an event concealed and not write it to the blockchain, the trust pattern remains ineffective.
Example
As an example, think about a supply chain. You ordered a valuable chinese vase online. Imagine, that the post man is coming to you and shortly before he reaches our house, he drops the package and the vase breaks. The post man feels guilty, records the incident in their internal system, and tells you that they will pay for the price of the vase.
Later, his supervisor realizes that the vase is worth 5000€. When you ask for compensation, he denies that the event has ever been recorded in their system. If the post man would have gathered the event data (time and what happened) and stored in on the blockchain, nobody could deny that the event has been reported.
Pattern 3: Smart Contract Activities
In an inter-organizational process, companies are solely responsible for certain activities. The execution of activities of one organization can be seen as a black box for other organizations. Without any modifications, collaborators in a shared process cannot verify the correct execution of the activities of other collaborators. Further, it is also not traceable to them if even the resources to execute the activity at a certain point in time are available. The use of blockchain technology can mitigate this as a highly available and transparent computing environment.
Where it can help
For this pattern, we can answer the questions as follows:
- Where in the process are uncertainties? → At any point in a collaborative process, where a company executes an activity that another independent party relies on.
- Who is responsible for the uncertainties? → A company that might want to change how they are executing an activity.
- What are the uncertainties concerned with? → There is uncertainty regarding the integrity of the activity execution.
How it works
In this trust pattern, the business logic of an activity is encoded in a smart contract and deployed on the blockchain. This helps to ensure that exactly the desired logic is executed and nothing else. As another benefit besides the integrity of the activity execution and its traceability, also availability is improved. As an execution environment, many different peers participate in a blockchain network, which all can execute smart contracts. Depending on the network configuration and the peers, blockchain can be seen as a highly-available computing environment with smart contracts.
Example
Imagine a situation where a doctor needs to generate a certificate saying that a certain patient is vaccinated. The patient needs to be sure that the activity of creating the certificate is done correctly. Otherwise, the patient would come into trouble when proving the vaccination status. We can encode the programming logic as a smart contract and verify to logs to see that exactly the specified logic was executed.
Final Thoughts
This collection showed three prominent blockchain trust patterns. Everybody who wants to use blockchain to improve trust in inter-organizational processes should have a framework in mind for how to classify their trust issues. This article provided a simple method that can be used in any business process.
Previous part of this series: 3 Key Aspects to Consider When Analyzing Trust in Business Collaborations
About this series: This series is based on the scientific paper
Müller, Marcel, Nadine Ostern, and Michael Rosemann. “Silver bullet for all trust issues? Blockchain-based trust patterns for collaborative business processes.” International Conference on Business Process Management. Springer, Cham, 2020. Download it for free here.
About the author: Marcel Müller is a German deep tech entrepreneur and researcher with a passion for bringing innovations from research to the market. He is the CEO of JadenX, a company that develops deep tech innovations together with partners. Marcel is also the founder of KnowledgeX, a paradigm-changing data science marketplace that uses blockchain and trusted execution environments for trusted collaboration. Furthermore, Marcel is a researcher at SNET at TU Berlin.
