Extend your blockchain smart contracts with off-chain logic
Install a cloud service such as IBM Operational Decision Manager vs. asking a trusted oracle
This article 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.
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.
When smart contracts aren’t as smart as they need to be
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?
Two ways to use off-chain logic
In this article, we present two mechanisms for implementing off-chain logic that maintain trust, visibility, and transparency as qualities of service for a blockchain network:
- Extend the operational boundary of a smart contract to a third-party system (for example, IBM Operational Decision Manager, ODM). In this model, peers in the blockchain network invoke a third-party service co-located with them. The underlying assumption is that the outcome of the invocation is deterministic.
Figure 1. Extend the operational boundary of a smart contract to a third-party system, such as ODM
- Introduce an oracle that smart contracts can invoke. In this model, the oracle is a trusted third party that answers questions in a deterministic fashion without knowing the full context of the transaction. In other words, privacy and confidentiality are preserved.
Figure 2. Introduce a trusted oracle
Considerations for both models are covered in the next sections.
Extending the operational boundary of the smart contract
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 purely 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.
Avoiding reinventing the wheel
A more viable option for this organization is to leverage the existing rules implemented in IBM ODM from the context of smart contracts:
- Each organization in the business network has, along with each peer, its own private IBM ODM instance.
- Smart contracts invoke the business rules that live in IBM ODM. Output returned from IBM ODM is then used in smart contracts to perform additional computations and/or to update the shared ledger.
- Each organization in the network deploys the same version of the business rules code to their IBM ODM instances to ensure that when smart contracts run, the network can achieve consensus.
- The process for installing and updating the code that runs on the IBM ODM instances does not follow the typical deployment process used for IBM ODM. (If the typical deployment process were used, potential trust issues could arise between the organizations in the network. For instance, how would they know for sure that each IBM ODM instance invoked from smart contracts in the blockchain network is running the exact same code?) Just as the smart contract code is tamper-proof inside the blockchain, no one should be able to tamper with the business rules logic that runs inside IBM ODM.
- Installing and updating the code running on IBM ODM occurs in the context of a transaction in the blockchain network. This ensures that all IBM ODM instances across the network have the same version of the logic/business rules. The binary of the ruleset archive (this is the IBM ODM artifact that contains the business rules/logic), as well as its version number, is submitted to the blockchain network through a transaction, which is then handled by a smart contract that:
- Stores the ruleset archive in the world state database
- Stores the version of the ruleset
- Deploys the ruleset to the IBM ODM instance running on the local peer
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.
Introducing a trusted oracle
The architectural approach described in the previous section provides a reliable means to externalize complex decision rules. However, in the case of volatile information (such as interest rate), how can you 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:
- Delegate the processing for obtaining volatile information to a third-party known as the oracle
Deterministically agree on the value to use for a volatile piece of information
In order for an oracle to work in a blockchain network, a few necessary conditions must be met:
- Multiple endorsers must be able to obtain, from the oracle, the same answer to preserve the deterministic aspect of a smart contract.
- A durable link must be established between the execution of a smart contract and the response from the oracle.
- The confidentiality of the data must be preserved where required.
The architecture for this scenario
The following diagram shows the architecture and sequence of events for leveraging an oracle component from a multi-participant blockchain network:
Figure 3. How an oracle component works with a blockchain network
In the above diagram:
- A client application submits the transaction to each organization that needs to endorse the transaction (as specified in the endorsement policy). The client application is completely unaware that the smart contract will delegate a portion of the execution to an external system.
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:
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.
- The endorser peers validate the signature of the oracle. The signature and the response data should all be preserved on the ledger to provide auditability.
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.
Summary and recommendations
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 article 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.
In the second article in this series, we examine additional considerations and alternatives for integrating an oracle into your business network.