IBM Developer Day | Bengaluru | March 14th Register now
By Luc Desrosiers, Ricardo Olivieri | Published May 31, 2018
This tutorial presents two ways to bolster your smart contracts with logic obtained outside the typical boundaries of the blockchain, while still preserving the trust and transparency that define a blockchain network.
Learn how to combine business process management and blockchain.
And then see how you can make your blockchain smart contracts smarter with business rules.
Before smart contracts are deployed and instantiated, they go through the same vetting and endorsement processes that regular transactions go through before they are committed to the shared ledger. Through code reviews, participants in the network who own and administer peer nodes validate and verify that the business rules and logic in a smart contract are indeed valid before the smart contract becomes part of the blockchain network.
The validation and verification of smart contracts creates transparency and increases visibility into the processes and rules that govern the transactions that execute in the network. Hence, all transactional logic should ideally be encapsulated in smart contracts to guarantee that all peers participating in the endorsement process of transactions execute the same code.
However, there are scenarios where a smart contract may not have all the knowledge required to complete the processing of a transaction. For example, a smart contract may need to obtain volatile information (such as a stock price) at runtime from an external system. Or the business rules that govern a transaction may be so intricate and complex that externalizing them is more appropriate. Situations like these bring us to the following question:
Just how feasible is it to extend smart contracts with off-chain logic?
In this tutorial, we present two mechanisms for implementing off-chain logic that maintain trust, visibility, and transparency as qualities of service for a blockchain network:
Considerations for both models are covered in the next sections.
How? By implementing them using a rule engine supported by a decision management platform.
With IBM Operational Decision Manager (ODM), you can add trust at the smart contract definition level. This approach enables business stakeholders to contribute to the smart contract decision logic.
Learn more about using ODM to implement smart contracts.
Let’s assume that an organization leverages IBM Operational Decision Manager (ODM) to implement and host many complex business rules. Let’s also say that this organization plans to create a new blockchain network that will include participants from other enterprises.
One option for this organization is to re-implement the business rules that currently live and execute inside IBM ODM as multiple smart contracts and deploy them to the blockchain runtime platform.
From a pure technical standpoint, this seems to be the ideal solution. But is it feasible to re-implement hundreds or thousands of rules that have been tested and validated and that are known to work as expected? Doing so could be costly to the organization, and errors could be easily be introduced in the re-implementation of these rules as smart contracts. Another possible drawback from re-implementing and deploying such rules as smart contracts is that if business folks are accustomed to updating and validating the rules through the IBM ODM user interface, they would lose this flexibility.
A more viable option for this organization is to leverage the existing rules implemented in IBM ODM from the context of smart contracts:
The above architectural approach allows organizations to leverage existing artifacts from a blockchain network solution while at the same time ensuring that those artifacts are tamper-proof and can be validated and vetted whenever they are installed or updated.
And though we focused on IBM ODM, this architectural approach is applicable to other components that hold business logic that resides off-chain. For instance, a similar approach could be taken to leverage, from a blockchain runtime, the logic defined and executed inside a business process that runs within the context of IBM Business Process Manager.
Note that while this architectural approach maintains the trust that you’d expect in a blockchain network, it carries additional costs and operational concerns. These are mainly due to the configuration and ongoing maintenance required of the third-party system that coexists with the smart contracts on the network peers.
The architectural approach described in the previous section provides a reliable mean to externalize complex decision rules. However, in the case of volatile information (such as interest rate), how can we reliably enrich a smart contract with such information?
One possibility is to delegate this responsibility to the client application: The client application retrieves the current interest rate and includes it in its payload to the smart contract. But why would the network trust the client application to always provide such information reliably and accurately? Hence, instead of delegating this responsibility to the client application, a better option is to:
Deterministically agree on the value to use for a volatile piece of information
In a blockchain context, oracles find, verify, and provide real-world data for use in smart contracts. Learn more about the oracle’s role in a blockchain network:
In order for an oracle to work in a blockchain network, a few necessary conditions must be met:
The following diagram shows the architecture and sequence of events for leveraging an oracle component from a multi-participant blockchain network:
In the above diagram:
Each endorsing peer in each organization, in parallel, issues a request to the oracle with sufficient information so that the oracle can correlate the various requests from the different endorsing peers. This transaction structure shows a potential approach for doing so:
Learn more about the typical transactional mechanics that take place during a standard asset exchange, and how binding strings are used in Hyperledger Fabric.
The transaction data structure above uses a Merkle tree that includes all inputs sent to the smart contract, though it exposes only those fields that must be shared with the oracle. Using a Merkle tree allows for traceability between the input parameters and the oracle’s response. Note that the binding field is used as a unique way to identify the transaction and the requester. Now, creating this linkage could be optional since the verification and execution phase in Hyperledger Fabric will address the case where a peer is compromised.
The oracle uses the binding field (as shown in the diagram below) to correlate common requests and ensure consistency in the response. The response should also be signed by the oracle to avoid any potential tampering. Also, an Apache Kafka topic could be used to ensure ordering of those requests.
The oracle’s response structure could look like the one above, which includes a link between the request hash and the response and also a signature from the oracle.
In this section, we’ve assumed a specific mechanism for interacting with an oracle, but a business network may choose to integrate with a commercial oracle. If so, the oracle provider may dictate the approach. Nevertheless, the conditions listed at the beginning of this section still apply.
You now know about two approaches for implementing off-chain logic while at the same time preserving the trust and transparency that blockchain networks require.
The first approach requires installing third-party components in the peers of the network. These third-party components contain intricate and complex business logic that is easier to maintain if externalized. Installations and updates to the artifacts that execute on these components are performed as network transactions.
The second approach shows one way to use an oracle component to extend smart contracts and requires a durable link between the inputs to the smart contract and the response from the oracle. As some may notice, this is a different implementation than other technologies in use. In the next tutorial in this series, we will dive into the additional considerations for integrating an oracle into a business network and look at various alternatives.
As with any solution, introducing additional components must be weighed against the non-functional impact it can have. For example, because the availability of a service is the product of the availability of all its components, adding more components to the transaction chain will directly affect the service up-time. Similar concerns apply to the overall transaction latency. With that in mind, the externalization of the smart contract must be carefully considered.
The process for installing and updating smart contracts and any extension points that exist off-chain should be vetted by the members of the network to ensure that everyone properly understands its terms and conditions. Doing so must be part of the governance process of the network. It requires a level of collaboration that goes beyond the traditional boundary of a single organization, as well as information technology skills, plus business and legal skills. The decision to externalize business rules outside smart contracts can have many positive benefits, but it must align with the maturity of the consortium processes.
Stay tuned for the second tutorial in this series, where we examine additional considerations and alternatives for integrating an oracle into your business network.
February 28, 2019
Get the Code »
Think is IBM's flagship technology conference. This year, one of our leading containers dev advocates will be live streaming on…
Back to top