Recently, decentralised (on-blockchain) platforms have emerged to complement centralised (off-blockchain) platforms for the implementation of automated, digital ("smart") contracts. However, neither alternative can individually satisfy the requirements of a large class of applications. On-blockchain platforms suffer from scalability, performance, transaction costs and other limitations. Off-blockchain platforms are afflicted by drawbacks due to their dependence on single trusted third parties. We argue that in several application areas, hybrid platforms composed from the integration of on-and off-blockchain platforms are more able to support smart contracts that deliver the desired quality of service (QoS). Hybrid architectures are largely unexplored. To help cover the gap, in this paper we discuss the implementation of smart contracts on hybrid architectures. As a proof of concept, we show how a smart contract can be split and executed partially on an off-blockchain contract compliance checker and partially on the Rinkeby Ethereum network. To test the solution, we expose it to sequences of contractual operations generated mechanically by a contract validator tool.

In this paper we discuss how conventional business contracts can be converted into smart contracts-their electronic equivalents that can be used to systematically monitor and enforce contractual rights, obligations and prohibitions at run time. We explain that emerging blockchain technology is certainly a promising platform for implementing smart contracts but argue that there is a large class of applications, where blockchain is inadequate due to performance, scalability, and consistency requirements, and also due to language expressiveness and cost issues that are hard to solve. We explain that in some situations a centralised approach that does not rely on blockchain is a better alternative due to its simplicity, scalability, and performance. We suggest that in applications where decentralisation and transparency are essential, developers can advantageously combine the two approaches into hybrid solutions where some operations are enforced by enforcers deployed on-blockchains and the rest by enforcers deployed on trusted third parties.

Summary Smart contracts can be implemented using either centralized or decentralized (blockchain) platforms. However, for a large class of applications, neither of these two alternatives on its own can provide adequate scalability, performance, quality of service, security, and trust requirements. We argue that for many applications, hybrid solutions that combine both on and off‐blockchain components are more adequate. In this article, we introduce the design and implementation of a novel hybrid smart contract architecture built using the Ethereum blockchain connected to a centralized smart contract management system developed by us. We then compare and evaluate the implementation of an asset tracking service using three different architectures: on‐chain, off‐chain, and hybrid. We demonstrate that using a hybrid architecture, we can substantially improve performance of applications while retaining security and trust for critical tasks.

Internet, Cloud, and IoT (Internet of Things) based business relationships involve electronic interactions that are normally regulated using Service Level Agreements (SLAs), and contracts that specify the rights, obligations, and prohibitions of the entities involved in the interactions. After a contract has been negotiated and agreed, all parties will need assurances that the service interactions comply with the clauses of the agreements between the parties, and that any violations are detected, prevented, and their causes identified. Because of the dynamic nature of emerging IoT and Cloud based relationships, there is a need for automated support for the monitoring and enforcement of service agreement policies. This paper develops a novel model for representing contract clauses using business rules that is specifically designed for contract compliance checking and enforcement. We identify what events need to be generated and captured from the underlying messaging middleware, and describe key design issues for a state aware contract monitoring and enforcement service.

No abstract