Any blockchain project is only as useful as the solution it provides to a real world problem. This series will be looking at different industries and how the aelf platform can be applied to make a real change. Each use case will go into depth by giving real examples taken directly from real companies.
The supply chain is an industry plagued by some large scale issues costing billions of dollars annually. The two largest issues are ‘isolated data silos’ and ‘untraceable, poorly documented and manipulatable data’. In a previous post, these issues were discussed in more detail with an explanation of how the industry currently is approaching the solution. Building a supply chain product trace ecosystem app on aelf will resolve these issues for those involved.
Below is a hypothetical application built on the aelf platform demonstrating how existing supply chain systems can be implemented on blockchain with added benefits. This takes a number of existing aspects and applies them to a blockchain solution.
App Overview
In order to develop the app with the correct framework to ensure enterprises, retailers and others within the industry will utilize the app, we need to approach this with a hybrid web mindset rather than a simple blockchain solution. The app needs to connect to and interact with multiple blockchains, both private and public.
When a company starts using the app, it will create an account for them, type dependant on their role within the industry. For example, a freight forwarder will be given a freight account while a retailer will receive a retail account, a manufacturer will receive their own type of account and a warehouse, different again. Each account will have a private blockchain created for them for internal data management. Each individual private blockchain will be a sub chain of the parent public/hybrid chain for each account type. Each parent chain will then be connected to the app’s public main chain which oversees the security of the entire network. It is important that the main chain is public to ensure easy accessibility for other companies within the industry that would like to connect without using this app, in addition to providing a much more transparent and secure network.
Since each account will have a unique private chain, they will have full control of their data visibility, although they will not be able to alter it maliciously due to it still being recorded on the parent chain. Each block in a given period from the private chain will be hashed using the merkle tree concept until a single hash (merkle root) is produced and submitted to be recorded on the parent chain. Depending on the type of data and app design, this could be further compressed, resulting in a single hash for blocks from multiple private chains within a specific account type.
The app will need a simple and easy to use interface for the account holders to easily input data on a regular basis. Ideally the app will have certain APIs which allow the data input processes to be integrated with existing data recording equipment used, resulting in minimal adjustments required. Due to the merkle roots being recorded on the parent chain, the app will have enough information to verify the data with that uploaded from the next stage within the supply chain, if it exists within the ecosystem.
Example 1: a manufacturer records 100 units of product A produced with XX weight and YY colour. Each unit has a unique identifier which is included in the blocks, and thus the merkle root. The shipping company also records the same data which means the merkle roots submitted to both parent chains share the unique identifiers, showing that they are about the same set of products, and they also match the data ensuring both parties are recording accurately. Then the warehouse at the destination records only 80 units of product A and 20 units of Product B. This is added to the blockchain which is automatically flagged, as it includes the unique identifiers, but different data. A resolution process is then put in place, if required, the same day the warehouse logs the good. This minimizes the risk of errors in stock levels and product types.
The above example is automatic only if each party are either in the app ecosystem or at least have an API installed to allow the data to be read by the network.
By having the main chain access all the data from each parent chain and from external data providers through the set of APIs, an account holder can access all information regarding a particular product in the one location, regardless of where it is currently in the supply chain.
Example 2: A retailer has just received an order for 100 units of Product A and 200 units of Product B. They do not have stock in store, so they login into their account and check the warehouse that provides these products. In the warehouse they are still short 50 Units of Product B. They can then search other warehouses that are not normally on their supply chain by simply asking the main chain to search for other merkle roots within the warehouse parent chain that have the corresponding identifier for Product B. From here they can see that there are only 2 warehouses that have stock but they are in another country, so will take some time to get to the retailer. They then ask the main chain to check in the shipping parent chain, specifically for any that are being delivered to their local warehouse. From here they can see there is enough stock, and that it will take XX amount of days to arrive. Using this application, they can confirm the order in minutes without having to rely on third parties checking stock levels or records. They are also able to confirm the order with 100% certainty that the stock is exactly what they need and is accurate.
The reason this can be done so simply is due to the ability for the main chain to communicate with all other blockchains, both in the ecosystem and outside it.
So far we have mainly discussed how the app will improve processes and data management. But traces and recalls are another example that is extremely costly for any company within this industry.
When a product is found to be faulty, dangerous or misproduced, a recall needs to occur. There is currently no method which allows a retailer, supplier or distributor to efficiently access all the data required to assess where the problem occurred, and which products are affected. The current process requires the cooperation of many parties from the whole supply chain to work together and hopefully, each company will do their part properly and efficiently.
With the app, similarly to example 2, the ability of the main chain to read from multiple parent chains and other blockchains allows an account holder to run a trace using a product’s unique identifier within minutes. There is no delay, waiting for other parties to respond with their own data, nor is there any concern over the authenticity or accuracy of data received.
Example 3: An electrical supplier has found that any car with computer Unit A installed is at risk of an electrical fire. They use the app to track to identify all car manufacturers that have purchased their Unit A since the latest update resulting in the risk. They send a recall request through the app which automatically then tracks every car that has Unit A installed and the dealerships where these vehicles are or have been sold. This information is then sent to both the dealer and the car manufacturer who confirm the trace request. By confirming it, the system then connects to their private blockchains, obtains the data and sends out recall requests to each individual who owns the cars. Through this method, the recall requests have been sent out within 24 hours of the issue being identified.
This example demonstrates the benefit of not only cross chain readability, but also cross chain interoperability, where one action on blockchain A, can initiate an action on Blockchain B, C and D. The initiator can be confident that urgent action is occurring even without the need for human confirmation, drastically reducing the speed and inaccuracy of these requests.
For the purpose of this article we will use the rough cost estimates provided by IBM research for their value assessment tool.
Note: IBM’s Value Assessment Tool is designed for perishable goods and products.
A manufacturer that has an annual revenue of $1 billion can have a single recall cost over $38 million, with the cost of a recall execution alone costing over $4 million in some cases.
These costs can be drastically reduced through the use of the blockchain ecosystem app. Over half a million dollars could be saved annually simply through supply chain inefficiencies.
The last thing that needs to be touched upon, is why the app builds individual private blockchains for each account holder. By doing this, the company does not need to worry about who can or can’t see their data that is uploaded, they have the ability to select how much of their data and which aspects are available to be searched by the parent chain or main chain. In addition to this, should they decide that they needed to leave the current ecosystem and join another network, they do so simply by removing their account to the network and connecting their chain to the new network. But taking this a step further, there is no need to disconnect from the original as they can simply have their data shared on the two networks with no detrimental impact.
This use case for blockchain is only available due to aelf’s unique ability to scale, and create hybrid ecosystems with a tree like structure, mixing both public and private chains with the core ability to employ cross chain interoperability.
· aelf Telegram community: English, Türkçe, Español, 한국, 日本語, 中文，русский, العربية, Deutsch, Italiano, Français, हिन्दी, and Tiếng Việt,
· aelf Twitter
· aelf Facebook
· aelf YouTube
· aelf Instagram
· aelf Reddit
· aelf Medium (for the latest update and articles)
· aelf Github (complete aelf project codes)
For more information, visit aelf.io
