Blockchain’s Role in the Produce Supply Chain: Part Three – Specific Capabilities

Bill McBeath Bill McBeath
June 11, 2018 FinTech
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 and Part Two of this series, we discussed different approaches to achieving traceability, as well as the data and capabilities required for improving freshness and safety. Here in part three, we cover blockchain-specific capabilities and attributes.    

Blockchain’s Role

Blockchain-specific Capabilities

Everything that has been described above can be and is done today by a centralized cloud-based system without the need for blockchain. However, recording the various transactions, HACCP steps, and temperature readings onto a blockchain can add trust and additional capabilities to the system:
  • Increased Security and Higher Availability—With decentralization and embedded encryption, blockchain can be much harder to hack or bring down, provided there are a sufficiently large number of participating nodes executing the validation and storage. This strength comes at a cost, as there is now much more redundant storage and encryption processing required.
  • Tamper-resistance—Blockchains are virtually tamper-proof once the data is written and validated.
The confidence in the data thereby rests on the strength of the frontend consensus algorithms used and any protections in place to ensure valid data is being written in the first place. One approach is to have the data digitally signed by the edge devices originating them, and ensure those devices are fully secured1with secure boot and update mechanisms, trusted path/encrypted data streams, access controls, and anti-tampering mechanisms in place.2 Another is algorithms that detect malfeasance (as discussed earlier for tampering with temperature tags). These irregularity detection algorithms are critical to revealing potentially inaccurate readings caused by intentional gaming of the system (like putting a temperature sensor into cold water) or simply sloppy execution (like forgetting to turn on the temperature recorder as soon as a pallet has been built in the field) at any point in the chain. Without irregular­ity detection algorithms, you may know with confidence that the data on the blockchain was indeed written by an IoT device, but will miss indicators of physical tampering with the device.
  • Automation via Smart Contracts—Most blockchains have the ability to automatically execute smart contracts when certain conditions are met. While a centralized networked platform can also provide automated execution, smart contracts inherently provide transparency for all parties to see exactly what the rules of automation are. In contrast, the code that drives the automation provided by a centralized platform is typically hidden behind the scenes. Instead, the system normally exposes simple configuration rules to enable users to control the automation. Provided the UI is well designed, these configuration rules are likely to be more intuitive to understand by a non-programmer than the code executed by a smart contract.
  • Settlement—Blockchains offer the possibility for extremely low-cost payments to be made between buyers and sellers of produce and/or related services (such as transportation). Until cryptocurrencies become widely accepted, a blockchain will likely require the ability for participants to pay and receive payment in fiat currency, with some sort of guarantee or limit on the effect of fluctuations in cryptocurrency exchange rates.
  • Soft Claims—Soft claims can be a source of irritation between retailers and growers. Soft claims are often communicated and acknowledged informally with no requisite paper trail or system-of-record tracking them. Furthermore, retailers sometimes suspect the grower is not always shipping their best product and may be hiding a few bad pallets amongst the good ones. Conversely, growers may suspect the retailer is using some of their soft claims to cover up the retailer’s own inaccurate forecast or poor inventory management, when they simply ordered too many and can’t really use all of the pallets they ordered. With traditional methods, there is no easy way to methodically track soft claims, or to prove or disprove any of these suspicions. This makes disagreements and disputes all too common, thereby harming the relationship. With a system like Zest, the rejected pallet count is tracked and automatically communicated as a soft claim notification to the supplier. It can also be recorded on the blockchain, along with the objective measure of remaining freshness that both parties agree and rely on. By recording soft claims onto the blockchain, along with the ZIPR Code of any rejected pallets, it removes any ambiguity about how many pallets were rejected and the reason why, which can help soothe this sore spot in relationships.
  • Direct/Spot Market—A distributed ledger can be used to create Uber-like markets, matching buyers with sellers in near real time, without the need for a middleman. This can be done not only for produce, but also for the trucking services required to transport the produce. These types of direct markets can be done without blockchain, and in fact have already been done for both produce and trucking, although still accounting for only a small percent of total transactions. In both cases, the bulk of produce and transportation has continued to be bought via direct contracts, because such relationships help ensure continuity of supply and quality for the buyer and more reliable demand for the seller. However, direct markets can be useful for spot demand, balancing out last minute demand/supply mismatches. Blockchain has inherent characteristics to support these direct markets, namely transparency (full audit trail), consensus (key parties have agreed and digitally signed each transaction), immutability (people can’t tamper with the records), smart contracts (automation of payment when certain events occur, such as delivery and passed inspection), and settlement capabilities (with very low or no payment fees). It becomes even more useful when combined with a system like Zest that provides full transparency into processes and conditions. Retailers tend to use spot markets only as a last resort, since they are essentially flying blind, with no relationship and very limited ability to establish trust in the supplier and the quality of the product they are delivering. Freshness and safety data, stored on a blockchain, with the anti-tampering algorithms described above, can help bridge that gap of trust for spot market participants. This should not only make buyers more comfortable, but enable sellers to get full market price for their produce.
  • Auditability and Restricted Transparency—Most blockchains for commerce will be permissioned (see below), so it is not the case that there is full public transparency, where everyone can see everything. In practice, a centralized cloud provider may choose to provide the same level of data transparency as a blockchain, but the blockchain ensures that nothing has been tampered with, thereby increasing auditability.
    • Architectural decisions about what data and functionality to put on the blockchain vs. on the networked SaaS platform will be shaped by the much higher cost of storage and execution on blockchains. This tradeoff is explored further in the section On-chain Smart Contracts vs. Off-chain Automation in Part Four.

    Importance of a Blockchain Agnostic Architecture

    There are many different blockchain and distributed ledger technology stacks emerging,3 such as Hyperledger Fabric, Ethereum (various flavors), R3, Corda, and countless others. We are still in the early days of blockchain and it is too soon to tell who the winners and losers will be. That is especially true for the produce supply chain, where growers and retailers are just starting to learn about this technology and figure out what role it will play for them. They have not yet committed to a specific blockchain technology or implementation. It may turn out that the industry settles into two or three different camps over the long run.
    Furthermore, even if the same technology is used, there could still be multiple different permissioned blockchains used by different parts of the industry. We could very well end up with a separate blockchain being used by each major retailer, for example. Therefore, it is prudent for growers and retailers to select a solution that is blockchain agnostic; one that is architected to integrate with any of the existing blockchain technologies as well as potential future yet-to-be-developed ones. The platform should also be capable of supporting multiple blockchains integrated onto the same platform, to deal with the likely scenario that not everyone in the industry is using the same chain.

    Public vs. Permissioned Blockchains

    Assurance of the various trading parties’ identities and control over the privacy of transactions are required for most commercial uses of blockchains, including produce supply chains. For those reasons, a permissioned blockchain approach is needed, rather than a public blockchain. The precise definitions of these terms are currently up for dispute,4 but the table below shows the characteristics of public vs. permissioned blockchain as we are using the terms in this paper.
      Public Permissioned
    Participation Anyone can participate By invitation only, vetted either by a central authority, consensus, or other criteria
    Access control Anyone can read and anyone can write (subject to validation) Read and write access may be restricted to protect privacy of data
    Identity Pseudonymous Participants identified, preferably strongly
    Consensus Typically requires a majority of validator nodes May be done by a smaller set of nodes, such as stakeholders and/or knowledge-holders
    Control of code Anyone can make changes, but a majority of nodes decide which to keep May be centralized or controlled by a consortium

    Table 1 – Public vs. Permissioned Blockchain Characteristics

    For most transactions in a produce supply chain, the parties cannot be anonymous or pseudonymous. There is a need for ongoing communications about orders, logistics, quality, acceptance test results and rejection, settlements, and other problems. Therefore, the identity of the transacting participants needs to be known and verified. Furthermore, the data about orders, prices, transactions, shipments, and so forth needs to be kept private to the parties involved. For competitive and security reasons, these data cannot be made available to the general public.
    A scalable consensus algorithm is needed as well. Since participants have been identified and vetted, the heavyweight consensus approach of bitcoin or other public blockchains is not needed. Instead, digital signatures verifying acceptance of data by a few key stakeholder and knowledge-holder participants is sufficient. For example, a wireless tag reader may read the temperature history of a tag on a pallet, write the data into an off-chain database, and then create a record on the blockchain with a hash of the temperature data and pointer to the data. Ideally this should be done with full end-to-end security (as Zest does), with bi-directional authentication and strong encryption for all tag-to-reader and reader-to-cloud communications.
    A networked SaaS platform may then read that data, run machine learning-based algorithms to check for potential fraudulent data, and verify that everything appears to be legitimate, and then sign its verification of that data. Finally, the system may ask a worker at that location to visually verify5 that the specific pallet in question is at that specific location, with a certain number of cases of a specific type of produce.
    Thus, consensus may be met with just a small number of checks being made to validate the data being written on the blockchain, thereby taking minimal processing power and time, compared with the heavy requirements of say bitcoin’s blockchain. In designing a consensus algorithm, the cost of validation needs to be weighed against the likelihood and consequences of someone tampering with the data. The system could also be designed to let the end users configure the type of consensus required (in essence, defining who needs to sign off on a transaction).
    In Part Four of this series we look at automation and the role of smart contracts vs. off-chain automation.
    1 For example, Zest knows the location of every edge device it uses, including which subnet it should be on. If a piece of equipment, such as an IoT tag reader, gets unplugged, an alert is generated. Mobile equipment, such as devices used to take measurement in the field, use GPS to verify that the user is at the right location.  2 For more details on securing edge devices, see The IoT Security Imperative: Device Security Requirements. 
    3 Some of the major technology companies, notably IBM, Microsoft, and Amazon/AWS are offering various development tools and environments that leverage these various blockchain technologies. They all seem to be hedging their bets as well, offering ‘all of the above’ options for different blockchain technologies.  4 There is currently a lack of broad consensus on precise definitions for these terms (including also the terms ‘private’ and ‘consortium’ blockchains). That is not surprising given the early stage of discovery and experimentation we are at in deploying various flavors of blockchain, beyond cryptocurrencies. We expect that lack of consensus to diminish over the next year or two, as people start to settle on specific definitions. We saw a similar pattern when the term ‘cloud’ first started becoming popular. At first there was a lot of handwaving and no universally accepted definition of what cloud meant. Within a couple of years, reasonably precise definitions coalesced and became widely accepted for specific categories of cloud services, such as IaaS, PaaS, and SaaS. 5 In practice, this would likely be integrated into the existing receiving process, rather than creating a new extra step.