( This article is excerpted from the complimentary report
Blockchain’s Role in the Produce Supply Chain, available here. )
In Part One, Part Two, and Part Three of this series, we described approaches to traceability, the data and capabilities required for improving freshness and safety, and blockchain-specific capabilities. In this article, we talk about which automation belongs in a smart contract vs. being executed off-chain.
Automation and Smart Contracts
On-chain Smart Contracts vs. Off-chain Automation
A blockchain may contain smart contracts1 that trigger and execute at key handoffs and decision points for each pallet or case of produce flowing throughout the end-to-end supply chain from farm to consumer. These can be used to automate key transactions and decisions. However, it is important to understand that storing data and running smart contracts on a blockchain is many orders of magnitude more expensive than using conventional computing resources.2 Therefore, business applications will usually store most of the data and automation off-chain, using the blockchain only where it makes sense. Smart contracts will typically be used to encode mutually-agreed, high-level business rules and transactions, where multiple parties want full visibility and the ability to mutually validate the execution of transactions. Lower-level or ‘behind-the-scenes’ automation and algorithms will likely be executed off-chain. Thereby, the automation described below is likely to involve a hybrid of networked SaaS systems working in tandem with blockchain technology and smart contracts, rather than just blockchain-based smart contracts alone.
As we are in the early days of development and deployment of full scale blockchain applications in the supply chain, people are still experimenting and discovering what data and logic belongs on the blockchain vs. off-chain. The picture will become much clearer over time. In the meantime, below we describe hypothetical divisions of labor (i.e. execution) between blockchain-based smart contracts and off-chain automation logic, based on what might make sense today and in the near future.
Freshness-related Smart Contract and Off-chain Automation Logic
At the retailer, smart contracts can semi-automate the acceptance process, assuring that only produce with adequate remaining freshness and safety is accepted. For determining freshness, a smart contract needs access to the data and capabilities described in the section above on Data/Capabilities Required for Improving Freshness. In this case, the calculations of remaining days of freshness would be done off-chain by the networked platform, while the smart contract on the blockchain might contain the specific terms of acceptance, such as minimum days of freshness required. Such a smart contract could be triggered, for example, when a pallet is received by the retailer for acceptance or rejection (see sidebar at right).
Smart contracts do not eliminate the need for physical inspection for damage, as the temperature history does not reveal mechanical damage to the produce, nor discoloration4 or other visual defects. Nevertheless, this type of semi-automation does accomplish several things:
- Allows QA people to focus on what they do best, inspecting for visible physical damage.
- Automates freshness assessment based on temperature history, thereby providing a much higher confidence in remaining freshness compared to visual inspection alone.
- Provides scalability and notification for acceptance/rejection processes.
- Reduces disputes, paperwork, and errors.
- Speeds up payments.
Further back in the chain, off-chain automation may be used to implement intelligent routing, and decide where to send each pallet of produce to match its shelf life with each destination’s requirements. Intelligent routing is described in Pallet-level Monitoring: Maximizing Delivered Shelf life in the End-to-End Fresh Food Supply Chain.
Safety-related Smart Contract Logic
Goals for safety in the produce supply include:
1) ensure the proper execution of safety and cleanliness processes and procedures,
2) detect any contamination and stop its distribution at the earliest possible point in time. For the first goal (ensuring proper execution of safety processes), it is best if the SaaS system is prescriptive for each process step, such as telling the workers at a packhouse which order to cool the pallets in, providing reminders and checklists to clean specific pieces of equipment, providing reminders and labels for samples to be taken and sent to the lab, and so forth. Monitoring can be accomplished via a combination of human inputs to the systems (such as checking off a checklist or filling out a form or taking pictures) and sensor data such as temperature history data to tell whether each pallet was properly cooled or video analytics that recognizes when someone is cleaning a machine. While most of this would be performed off-chain by the networked SaaS system, in some cases, the blockchain might be used to record evidence that safety procedures were followed.
In order to catch tainted produce as early as possible (the second goal above), we could envision the SaaS system doing an automated check of HACCP test results (e.g. microbial sample testing) as soon as the results are securely entered into the system by the labs. As well, at each step in the supply chain, the temperature history of the pallet could be checked to see if it has been exposed too long to elevated temperatures and thereby potentially be unsafe or unfit to be shipped or accepted. With the microbial sample results, a certain level of microbes may trigger a halt to production on the affected line and a ‘hold’ order for all associated produce in the supply chain.
Then, when each pallet is about to be shipped or has just been received, an automated check is made on whether that pallet is on hold or clear to proceed. For a discussion of which portions of this should be executed on-chain vs. off-chain (see sidebar at right).
In Part Five, the final installment of this series, we explore the role of hybrid systems, combining blockchain with off-chain functionality, to achieve produce traceability, freshness, and safety.
(in fiat currency or cryptocurrency) between trading partners.
The cost of storing data and executing smart contracts on a public blockchain like bitcoin can be thousands of times more than what it costs to store and execute the same data and logic on a regular computer, largely due to the highly redundant nature of the execution and storage, but also to the amount of encryption logic being executed. A permissioned supply chain can reduce those costs by orders of magnitude, and eventually may get to within 10X or so of the cost of running on a single local machine.
For example, one location may consume some types of produce faster than another, and thereby be willing and able to accept shorter-shelf-life produce, as reflected in the smart contract for that location. We don’t necessarily expect this level of sophistication in early implementations, but over time we envision smart contracts that factor in location-specific criteria, current demand and inventory levels, or other relevant factors.
To view other articles from this issue of the brief, click here.