Permissioned blockchain – A decentralized computation and information sharing platform that enables multiple authoritative domains which do not trust each other to cooperate, coordinate, and collaborate in a rational decision-making process under a closed environment with the enablement of security services such as authentication and authorization.
In the permissioned blockchain architecture, the users have to register and authenticate themself to use the system. In this system, the users know each other. However, users may not trust each other, assuming that certain users in the blockchain network may behave maliciously. Although, they got authenticated to use the system. The objective is to run the blockchain among this known and identified set of participants, but security and consensus are still required for the smooth functioning of the entire ecosystem.
The permissioned environment consists of a closed environment, and the individual users knew each other. They try to come to a common platform with no centralized database or data server rather a completely decentralized architecture. Having a set of users known each other a priory, but they may not trust each other. So in this particular setting, users cannot join the blockchain network anytime. Rather, they have to go through the authentication mechanism to authenticate themselves before accessing the permissioned blockchain network.
Provenance Tracking of Assets (Supply Chain System)
To ensure that whenever a certain asset moves from one particular supplier to the distributors, distributor to the vendors, and at the end, to the market via retailers. At every stage, tracking information must be maintained by different authoritative domains. Every authoritative domain has complete control over the tracking information that they are providing. However, other authoritative domains can verify the tracking information but can’t tamper. Here authoritative domains represent Supplier, Distributor, and Vendor as these are independent organizations with different policies to work. In this type of use case, we can use premissioned blockchain architecture.
The interesting fact is that why not use a centralized server to have these tracking entries? And anyone can look into that centralized tracking entries and verify indeed. The problem is who will maintain the centralized server. Suppose if a party, say Distributor, maintains a centralized server, then why Vendor or Supplier trust the data uploaded by the distributor. In the other case, suppose they are using a third-party solution—having high maintenance charges and difficulty building a trust relationship among individuals.
Provenance Tracking of Assets (International Postal Services)
Let us understand how it works in the centralized environment.
National Postal Service
The single-party setup, such as sending or receiving goods within the same country and the same service provider, is easy, and a centralized system solves this problem. They can maintain tracking information in their centralized server, and with tracking IDs, the users can easily track the status of consignments.
International Postal Service
Maintaining the tracking information for international goods services is difficult. For example, A typical use case can be like sending postal mail from India to the USA. The India Post is the one authoritative domain, and basically, they transfer the post up to their border gateway, and from there, they will send it to some international agency. Who will take the courier to USA post, and then USA post will take it and transfer it internally.
The first problem is that whenever we have multiple authorities, it is difficult, or there is a kind of trust issue whenever they rely on a centralized server. So the question comes who will host that server? If India post will host the server, then the question comes that why the USA post will trust or believe the data which is there in the India Post server and vice versa.
The second problem is that if none of the India or USA posts will host that particular service, they may purchase the service from some third-party agent. It is like take the service of a third-party cloud. They have to pay a significant amount of money for that third-party cloud. As there are multiple authoritative domains, they require a certain kind of access to that central server, and the question comes that system provides a guarantee that the data which is entered by the USA post is not getting tampered with by the data which is being entered by India post or vice versa.
Whenever there are multiple authoritative domains in the loop, there is a trust relationship problem. That is why people do not go for any centralized server.
Premissioned Blockchain Architecture
For this kind of provenance tracking of assets, it is more beneficial to use the permissioned blockchain environment and the beauty of the permissioned blockchain environment is that it does not require to host any centralized server. The individual would maintain the data, but everyone will be able to validate other’s data.
The first typical use case was from the Supply Chain System, where goods are transferred between the suppliers and distributors, distributors and vendors, and vendors and retailers. In this scenario, we have multiple suppliers, distributors, and vendors. Like every individual supplier, distributor, and the vendor has its individual authoritative domain and follows its own policy of entering data. Still, a third-party auditor should have access to this entire data. They should reliably verify the correctness of data that is being passed through supplier distributor vendor and the final in the market.
The second typical use case was from Postal services, where we know that the posts/goods/couriers will either go from India to USA post or vise versa. So we have a closed set of participants who are participating in the entire blockchain environment. But still, the trust relationship is not there. To maintain a certain kind of security or ensure that the data is not getting tampered with while transferring from one authoritative domain to another authoritative domain.
However, why not permissionless architecture? We can also use the permissionless model, but there are certain disadvantages of using the permissionless model because we are going for an open environment. Whenever we are going for an open environment, the network or system becomes more complex. It has to handle many things all together, which is why we want to move from a permissionless to a permissioned model.
Summary
We have seen permissioned blockchain architecture and different use cases from Supply Chain System and another from International Postal Service. Studies permissionless blockchain architecture is not suitable for these use cases.
References
- NPTEL lecture series on Blockchains Architecture, Design and Use Cases by Prof. Sandip Chakraborty, IIT Kharagpur.
527 total views, 1 views today
