Join us for Code @ Think 2019 | San Francisco | February 12 – 15 Register now Limited availability
By Chris Tyler | Published November 30, 2018 - Updated November 30, 2018
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:
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.
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:
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.
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.
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:
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.
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.
Rules engines such as IBM Operational Decision Manager can be integrated with the blockchain platform.
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.
You can also find me on Twitter @ChrisATyler or interact with me on LinkedIn at https://www.linkedin.com/in/chrisatyler/.
To find out more about IBM Blockchain, you can check out the IBM Blockchain site and follow IBM Blockchain on Twitter @IBMBlockchain. You can also find me on Twitter @ChrisATyler or interact with me on LinkedIn.
Get the Code »
Back to top