Ready to learn Blockchain? Browse courses like Blockchain for Finance Professionals developed by industry thought leaders and Experfy in Harvard Innovation Lab.
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
|
Example Smart Contract: Retailer’s Acceptance A smart contract between the retailer and grower/ distributor might include one or more freshness thresholds specifying exactly how many days of shelf life are needed for each type of produce by time-of-year (potentially by location3 or other factors as well). For example, there may be an ‘auto-rejection level’ threshold; all pallets with shelf lives below that level are automatically rejected, and a higher ‘full-acceptance level’ threshold, above which all pallets are accepted (contingent on passing visual inspection). Pallets with shelf life in-between the auto-reject and full-accept thresholds might be automatically accepted, but with the retailer paying only 85% of the full-shelf-life price. Or for those ‘in-between pallets,’ the contract may be set up to check inventory and forecast levels and if that particular item is in short supply, then it may accept those shorter shelf-life pallets. Alternatively, for ‘in-between pallets’ the contract may request the off-chain system to send all the relevant information (e.g. shelf life of pallets, current inventory levels, forecasted demand, etc.) to the responsible buyer or inventory manager at the retailer to make the decision. These are just illustrative examples: the actual business rules in the contract can be customized to meet the needs of both parties, just as the clauses in a traditional contract may be customized by both parties to serve their interests. |
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.
|
Example Division of Labor A smart contract that executes upon receipt of pallets at the retailer, and possibly at other key handoff points in the supply chain, could include a check of safety-related information, in addition to the freshness and provenance data. This safety data check could include confirmation that all related HACCP processes were completed correctly, and all post-processing tests were negative. Updating the safety data about each pallet on the blockchain is best managed by off-chain analytics that evaluate the securely entered lab HACCP test results and correlate or link those results to all of the pallets processed during the time-period associated with the sample being tested. HAACP test results can take days to get back to the grower or processor, during which time all of the potentially affected pallets will have moved on, potentially through numerous transactions, far removed from the source. If there is an issue with a particular batch, the system needs to search and find all affected pallets. Blockchains are not set up for efficient searching, but the SaaS system’s database is. So, in this case, the association of test results and pallets should be done off-chain. Once those linkages have been found, then the results of the test and status of all those pallets can be updated on the blockchain. Then the smart contracts can execute properly, with simple logic, based on that updated status. The ability to broadcast a ‘hold’ for all pallets processed from a specific location on a set date is a necessary capability for food safety. A hybrid networked SaaS and blockchain solution elegantly bridges the process of correlating data off-chain, and then managing individual item status in the blockchain. Maintaining the current status in the blockchain enables independent smart contracts to automatically evaluate the item or pallet status. |
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.
___________________________________________________
Smart contracts are logic on a blockchain that can execute automatically when triggered by specific events. The contracts may transfer value
(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.
In the future, other sensor data and analytics may be added to check for additional issues. For example, machine learning photo or video analytics could check for incorrect color or visual imperfections and sort the produce accordingly.
