Make your blockchain smart contracts smarter with analytics

Supply chain use case illustrates how you can get the most out of your smart contracts

By now, you’ve probably been inundated with information about blockchain and have at least some understanding of its key concepts. (For some basics, check out my two-part post on building my first blockchain network). I’ve been working with blockchain for a little over a year now, and that’s in addition to my 25+ years working in data and analytics. Recently, I was challenged to demonstrate how analytics and blockchain can mutually benefit each other. In this article, I’ll share the fruits of those efforts, along with other examples of how analytics and blockchain converge. I think there are a lot of opportunities to improve analytics with blockchain and vice versa.

One of the key concepts of blockchain is the smart contract, an electronic representation of the terms and conditions that facilitate transactions between multiple parties. In a blockchain, this is generally built with a combination of code and data. Blockchain developers can build these to be as smart as they’d like, but the principles of blockchain require that the code should be kept in the blockchain and only use data that is visible in the blockchain. This helps maintain trust and transparency between all parties to the transactions.

So, how can you make your smart contracts smarter? There are a few ways I can think of:

Use assets to represent the data for the contract terms and conditions

Enhance the data with advanced analytics

Use machine learning

Augment with decision optimization for complex rules

For this article, I will use a common supply chain use case to illustrate how the above approaches can help make the smart contracts smarter. In this use case, a grower ships merchandise to a retailer. The retailer receives the shipment and then pays the grower. The diagram below illustrates the process and the participants, assets, and transactions involved.

In this example, the Ships To transaction references the Grower and Retailer participants, the Product(s) being shipped, and potentially some additional information such as shipment date, quantity, or transaction amount. The Ships To transaction smart contract verifies that the Grower, Retailer, Product and the shipment date are valid, and the transaction amount is greater than zero, or something very basic.

This smart contract example is very simple, but it’s enough to illustrate my point — and it is a typical starting point for blockchain developers.

Use assets to represent contract terms and conditions

All of the smart contract logic is housed in the Ships To transaction code. This is a fine starting point, but it can limit your flexibility. The first pattern for improving this solution would be to create a Contract asset type that references all of the terms and conditions for acceptance of the shipment between the Grower and the Retailer, and may also include some other information for later use. The Ships To transaction references the Contract.

This allows all of the terms and conditions to be maintained as attributes of the Contract, as opposed to being in code in the transaction. An application can be used to allow the Grower and the Retailer to agree on the terms and conditions, which can then be used to create a Contract asset. When the Grower initiates a Ships To transaction, it just refers to the Contract asset for all of the variables to validate the smart contract.

Here are a few other smart contract features you might want to include:

Number of days to deliver the products from Grower to Retailer — when the Retailer receives the shipment, the smart contract can verify that the date of arrival is within the expected timeframe from the date of shipment

Temperature thresholds (upper and lower) — used to determine that the proper temperature is maintained throughout the shipping process

Accelerometer thresholds — used to ensure that the container is not dropped or handled improperly

Geo-fence boundaries — used to limit the movement of the containers

Penalty amounts — used to affect the payout for violating any of the limits set on the contract

The point to all this is that you should build flexibility into a contract asset, which is more easy to modify than the chaincode. You may still have to modify the chaincode occasionally as you add terms and conditions, but if you build parameters into the Contract asset, you can allow the parties involved in the transaction to mutually agree on the terms and conditions, and then store those terms and conditions as an asset in the blockchain. And any modifications will be tracked by the ledger.

Enhance the data with advanced analytics

Over time, the blockchain will gather lots of historical data that can then be leveraged. One way to leverage it is to use data mining and predictive analytics to detect anomalies or outliers of the incoming contracts and transactions. Continuing with our supply chain use case, we can start to identify patterns of behavior, such as:

Continuously training anomaly or clustering models against the historical data and then running those models against incoming transactions can help you identify potential supply chain issues before they happen.

When a Contract asset is proposed by Grower A for Products A, B, and C, but Grower A typically only ships Products A and B, that could trigger an alert to the retailer to take a second look at the Contract. Or, if Growers A, B, and C typically charge $2 per pound for a particular quality of coffee, but Grower D tries to charge $5 per pound, that might trigger further review of the Contract.

To implement this, you might need to store some additional data on the Contract asset such as an Anomaly score and an Anomaly Reason description. You also need to make sure that everyone involved in the process is aware of the training of the model so that you maintain transparency.

Use machine learning models

When Grower A ships some bananas, the process could require that samples of the product be photographed and submitted as part of the transaction. Machine Learning Visual Recognition models can be used to detect certain bits of information that could be added to the blockchain, such as:

Degree of ripeness at time of shipment

Degree of ripeness at time of receipt

Type of banana

Quality of banana

Bunch size

This added information can be used in the smart contract for a number of reasons. For example, you could use it to determine conformity to Service Level Agreements in the contract. If the bananas are supposed to be green at the time of shipment and green with a faint hint of yellow at delivery but they are clearly yellow at the time of delivery, the shipment could be declined or potentially discounted. If it’s detected that the bunch sizes appear to be 2-4 bananas and you are expecting 6-8, that may impact the agreement between the Grower and the Retailer.

Augment with decision optimization for complex rules

For our last scenario, let’s assume that the rules governing the shipment of bananas are different depending on factors like point of origin, destination, or how they are shipped. These complex rules can sometimes be difficult to implement in chaincode. Rules engines can be used to determine acceptable next steps and approval processes.

If Grower A attempts to ship bananas from Brazil to Europe, that may be allowed only if they provide specific documentation and the shipment quantity is within an acceptable range. Growers shipping from the Philippines to North America may only be allowed to ship at certain times of the year. While these examples are simple, you can start to see that the rules can get very difficult to implement in code and may need to change frequently.

Conclusion

As you can see, there are many ways to add smarts to a smart contract. You should always remember that you need to have transparency to maintain trust. Participants in transactions affected by particular models need to have access to those models, and need to understand how to train them. Rules governing the transactions need to be visible to all parties. Applications and processes built on blockchain seek to keep transparency and trust. Even if the models are run off-chain and only create additional data points, how that data was derived needs to be fully understood by all participants.