Blockchain in Supplychain :)
Implementing an inspection Service in Supply chain using blockchain(Hedra service) and Trillian(a library to process real-time data).
So this blog discusses the idea of having an auditing service for sensible products in the cold chain industry. It provides the details for the end-to-end demo. It also talks about the benefits of using the technology, implementation details, and outcomes.
Cold Chain
It is a temperature-controlled supply chain. The term ‘cold chain’ (or) ‘cool chain’ refers the technology and behind process of maintaining the perishable products under specified low-temperature till it reaches the customers to prevent from spoiling (or) from any other side effects.
I ) A brief note on Problem statement
In the cold chain industry, products(eg, food or pharmaceutical products) containing cartons transport by the fleet operators to the customers. These products are maintaining under certain conditions until the end of the journey. Currently, the monitoring service is not available to track the health of the products.
II) Issues Involves In Existing Process
At the fleet operator side:
Having a surveillance camera or any similar technology makes fleet drivers uncomfortable due to its live monitoring feature. Moreover, the cost of implementing the BPO call center to support the monitoring activity is more. And the drivers have to act according to the support providers. Providing uninterrupted Online supporting services is difficult.
At the HVAC manufacturer side:
Generally, the fleet operators purchase refrigeration units from the HVAC (Heating, ventilation, and air conditioning) manufacturing company. The fleet operators do not share the equipment details with manufacturing companies as a notion of protecting end-users ' or customer’s privacy. The fleet operators complete the equipment service with the help of nearby third-party stores. This in turn makes the companies lose the market in the parts sales.
At the customer side:
The customer has no profit for sharing the equipment details. The ecosystem should build with an incentive mechanism to encourage sharing.
Focal Point: The solution should adapt offline mode rather than online mode to consider cost reduction. The critical point lies in maintaining the budget under 2 dollars per carton.
A solution is designed and implemented to address these issues.
III) Implementation details — Proposed Solution
The solution provides the below service for the products at no cost.
- Offline supervision
- Online verification
HVAC companies provide these free services for the equipment details and perform AI analytics to predict the desired results(eg. when the equipment needs service or replacement, etc.). Thereby the companies achieve the desired profits in the part sales market. The solution costs around $2 for a carton as per the business requirements.
Components Involved — Implemented solution
Merkle tree: It is a data structure. The data generation involves a hashing technique. The way of storing the data depicts a tree. For every new addition of data, the Merkle root hash(top node) changes. It is known for the features of immutable and efficient storage. Here is the link to know more about the Merkle tree.
- Sensor: The sensors capture the instant values of physical parameters.
- RF controller: Controller is responsible to collect the sensor values and creates a Merkle tree out of it. And share the tree details.
- Ocaml application, Irmin database & Chipcard: Chipcards are present on the cartons, it receives the Merkle root hashes and stores it in irmin. Ocaml application runs on the chipcard to store the Merkle root hashes. Ocaml and Irmin explained in detail in further discussion.
- Hedera: Hedera is a decentralized public network. It stores the Merkle trees and verifies the chipcards.
- Application: Mobile/web application as an interface to verify the cartons.
- Digital Identity: Module to provide the identities to trucks and other stakeholders involved in the process.
Architecture
There are three significant elements involves in the architecture solution,
1. Data Collection and processing at the controller side
2. ‘Processed data’ collection at the chipcard side
3. Hedera platform as verification service
Data Collection and processing at the controller side
The sensors present inside the truck. Each truck has its own RF controller. The controller gets the sensor values periodically and build the Merkle tree. Then it broadcasts the Merkle root hash at regular intervals to the chipcards. The sensor logs are storing offline and upload at the end of the trip. This reduces a large part of network infrastructure costs.
Data collection at chipcard
Each carton box comes with a chip card and an inbuilt irmin database locally. The chipcard receives the Merkle root hash and stores it in the database. These chip cards are likely to be disposable in nature to achieve low cost.
Hedera platform as verification service
Hedera service is an intermediate between the hedera platform and controller. It takes Merkle trees from the controller and uploads them into hedera. The customers use the chipcard to audit the carton (by plugging it into a device).
IV) How to set up the demo?
The GitHub repo’s “read me” file to know more about the project. It explains the project dependencies and the procedures to set up the demo.
Scenario 1:
Storyline: A truck delivers 100 cartons of pharmaceutical products to medical customers. The journey takes about a day. How to prove the 100 cartons are maintained at appropriate conditions for the whole day?
Note: “Developer Note” provides additional information for developers to understand at the backend level.
Developer Note
Generates the sensor values for the specified time period to simulate the sensor behavior.
Process
The sensor data send to the controller at regular intervals. The RF controller broadcasts the tree’s current root hash to the 100 cartons at periodic times. The processed sensor data tree maps the truck details. Controller uploads the tree to the hedera platform.
Auditing
The customer submits the carton’s root hashes to hedera service. The result processes based on the carton’s root hashes and hedera’s root hashes.
Scenario 2
Storyline:
* The controller is not present or malfunction at sometimes and chipcard records empty value. How to identify the ‘empty value’ recorded cartons ?
* The controller broadcasts the current root hash but the chipcard misses it. How to identify the cartons fail to record sensor data ?
Developer Note
The chip cards serves with an empty value or the chipcard stores an empty value at random time instances. The simulated data is shown below,
Chipcard’s data(recorded root hashes):
[ “empty”, “empty”, “empty”, “47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=”, “empty”, “empty”, “empty”, “47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=”, “empty”, “abu1rGkDv+mPOmNBU+rd3P/1wKkbhaCYLq8GO9EtT8E=” ]
There are 7 empty values out of 10 which is highlighted. These are the root hashes obtains from the controller.
Process
Chipcard stores the root hashes data locally(offline) in the irmin database. After the completion of the journey, the RF controller uploads the tree to the hedera platform with the help of the hedera service.
Auditing
The customer submits the root hashes to the hedera service. The output is processed based on the carton’s root hashes and hedera’s root hashes. The service also provides details about the untracked times.
Results
Four different scenarios explain through the selection of different kinds of chipcards. A webpage is created to demonstrate the same. The page shows 10 various trucks. Cartons select from these 10 different trucks.
The demo showcases the ‘tampered’, ‘misplaced’ (if the carton is carried in multiple trucks), ‘maintained’ and ‘not maintained cartons’.
Case1: Verification is successful.
Chipcard1 — The truck carries the carton within the specified sensor range. So it highlights in green color. Successfully verifies!
Case 2: Partial verification.
Chipcard2 — While transporting, the carton does not maintain under the desired temperature/humidity. The following pictures show the same. The tree structure image highlights the tree id based on the root hash.
The chipcard-2 involves multiple trucks.One of the trucks highlights in yellow color for ‘not maintained’ category and the other highlights in green color for the ‘maintained’ category .
Case-3 Verification fails.
Chipcard0 — The chipcard0 contains a tampered hash. Fails due to mismatch of the root hashes. It highlights in red color.
How a truck’s cartons track different tree’s root hashes?
All the 100 cartons of a truck stores a specific tree‘s root hahses. But sometimes the cartons have to be carried by more than one truck then the chipcard contains root hashes of other trucks too.
For example, a carton carried in truck1 and truck 2. So the trees of truck1’s and trcuk2’s root hashes present in the carton. Chipcard-2 /carton-2 shows two different trees’ hashes.
V) Technical Details (Code/flow in detail)
Trillian and Data structure
The Merkle tree is chosen as the data structure since it is immutable in structure and it could provide audit-proof. Trillian is a google product. It is a gRPC service to store data in Merkle tree format. It provides inclusion and consistency proofs. It needs an underlying storage layer(eg. Sql or maria db, etc..). It can be operated in two modes namely log mode and map mode. The major difference between the two modes is that in log mode, leaf data stores as a value but in map mode leaf data stores as key, value pairs.
The sensor data format is shown below,
The following shows a few implemented data formats. The sensor data structure is defined in the proto file which will be useful in serializing and deserializing. A go file is generated from a proto file using proto. buf package.
Merklenode structure created to copy the tree details and serve the Tree API request.
Each truck maps to a tree. RF controller contacts the Trillian service to create tree ids(log type) and stores sensor data in Merkle format. On every addition of new nodes, it collects the root hashes of the tree/truck. After the completion of the trip, the controller contacts the hedera service to upload it to the hedera platform.
Developer Note
There is no API to fetch the trees(leaves, intermediate nodes, and root hash). The tree is implemented using the existing APIs.This will help later in the verification process. The code written in Go lang to access Trillian’s API.
An instance of the Merkle node data structure is shown below, which is used to prepare the tree request. Treesize is the number of nodes present in the tree.
Each and every tree’s details write into a new file. These files later send to the hedera platform.
Chipcard — Ocaml and Irmin database
Ocaml is a multi-paradigm language. Irmin is an OCaml library for distributed data stores that inherits git properties such as merge, branch, etc. It is highly portable since it can run on Linux, web browsers even on Xen unikernels.
Chipcard programmed in Ocaml to store the broadcasted root hashes in irmin database. This app runs on unikernel. Mirage crypto library’s RSA algorithm is being used for encrypting and decrypting the root hash while storing and retrieving them from databases.
Hedera
It is used as a verification platform. A Javascript/Nodejs service is implemented to access the hedera SDK. FILE service, Smart contract are some highlighted services. File service is used to store the contents/data. An account with HBAR is required to execute the file service transaction.
The steps to access the file service are
- Need to provide account details and
- Call the functions “FileCreateTransaction” and “FileContentsQuery” to store the contents and query the stored contents respectively.
For every call to the function “FileCreateTransaction”, a unique file id will be created. The file id is needed to query the stored contents later. The transaction max size is 6.144 MB, this includes the signature size of about 100 bytes.
The following operations are allowed
1.append
2. update
3. delete.
If the tree size is larger than the file size, the append option can be used to add the contents. The file id receives as a receipt which is collected for the mapping function.
Two crucial mappings have to be done between
1. File ids and tree ids
2. Tree ids and its root hashes.
Auditing in detail:
When the customer is providing an array of root hashes, then it carries out a two-step verification process.
- Step 1: Given the root hashes, whether the uploaded trees contain the same root hash? If yes, then it goes to step-2. Otherwise, the hedera service will respond as “not verified ”.
- Step 2: It is fetching the whole tree using file id and checking the node/leaf values (sensor values) of that tree are within the desired range. Once the checking of sensor values also successful, then the service will respond with the message “verification successful”, if not it will reply as “not verified ”
The above code shows, case-1 “tampered” when the root hash is not matching.i.e, The data provided by the chipcard is not matching with hedera’s data. The below one shows the other cases “not in range” and “good”. The UI represents according to the below details,
Tampered — Red color
Not in the range — Yellow color
Good — Green color
AI Analytics
HVAC manufacturing companies perform AI analytics on the data that is been maintained on the hedera platform. This analytics is useful to predict equipment conditions.
Thoughts
- ESP32 series can replace the RF controller and chipcard.
2. A new data structure in OCaml can be the line of research.
Conclusion
This blog explained the cold chain industry problem and inspection service as the solution. Various scenarios have chosen and demonstrated in a graphical representation. The implemented system needs improvement in these areas “alternative for Merkle data structure — may be MPT”, an efficient algorithm for verifying thousands of sensor values, etc.
References
https://github.com/google/trillianhttps://github.com/google/trillian
https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf
https://godoc.org/github.com/google/trillian
RFC 6962 — Certificate Transparency
Hedera hashgraph white paper
