Dalhousie Blockchain Lab Logo

Dalhousie Blockchain Lab

Smart Contract as a Service – SCaaS

Investigators: Drs. C. Liu & P. Bodorik, Dalhousie University, and Dr. D. Jutla, Saint Mary’s University

SCaaS – Research in Publications

Publications are organized around research topics/themes. Below each research topic, relevant publications are listed, and then main contributions are described. For detailed references and downloads, please see People-pubs page.


Transforming FSMs to smart contracts with sidechain processing

The first paper presents a methodology for transforming computation represented using an FSM into a smart contract. Furhtermore, a method is presented for analyzing the smart contract to find patterns in the smart contract that are suitable for computation on a sidechain. The paper describes how to package the pattern as a separate smart contract that is deployed on a cheaper sidechain. The methodology provides for the necessary interaction protocol between the main and the sidechain.

The second paper elaborates on the tool to provide automated transformation of the FSM model into the methods a smart contract. For Ehereum blockchain, a method is provided to estimate the cost of (i) executing the patterm on the mainchain and then (ii) on a sidechain, while also including the overhead cost due to interaction between the main and side chains. If the cost, including the overhead cost, of executing the pattern on the sidechain is cheaper, then the pattern is deployed on the sidechain.

However, FSMs are limited in their expressiveness to support trade and goods and services applications, and hence other Model Driven Engineering (MDE) need to be explored for applicability. We use Business Process Model Notation (BPMN) modeling to express the blockchain application requirements and then transform the BPMN model to smart contracts. Unlike other approaches that transform a BPMN model directly into smart contract methods, we use interpretive approach based on multi-modal modeling, in which time is represented using Discrete Event (DE) modeling while functionality is represented using Hierarchical State Machines (HSMs), i.e., using DE-HSM modeling, which is described next.


Using Multi-modal modeling to transform a BPMN model to smart contracts

A blockchain application, expressed using a Business Process Model Notation (BPMN) model, is transformed into a multi-modal model, more specifically DE-HSM model in which time is represented using Discrete Event (DE) modeling while functionality is represented using Hierarchical State Machines (HSMs).

The DE-HSM model is transformed into the methods of a smart contract(s). The smart contract contains a data structure representing the DE-HSM model wherein such a data structure is independent of the blockchain infrastructure. It also includes one main method that, given input from an actor, checks the current state of computation and determines the state transition while also producing outputs associated with the transition. The transition output and the new state represent the synchronization activities. However, if the transition indicates that a particular BPMN task element is to be executed, then a method associated with that task element is executed.

We present a method and a tool to transform a BPMN model to DE-HSM model, and then to smart contracts, automatically. The business logic for each actor is represented as a script contained within a BPMN-task element that is created either by a developer, or by a BA using a graphical DMN modeling tool. The script for the BPMN element method execution has well-defined input and oupput parameters and its execution and its execution has only laccess to its local vand blockchain state variables (in addition to the parameters). Con Consequently, it is well-defined and thus:


Supporting collaborative multi-step transactions

A blockchain transaction is a result of updates performed by an execution of a smart contract method. However, once a smart contract method is invoked, it runs to completion, and hence it is a single-step transaction that is insufficient to support the long-term collaborative activities executed by several actors that are multi-step.

Our approach enables a BA to a define a multi-step (long-term) transaction as an execution of several methods, wherein the transformation tool automatically provides a transaction mechanism to enforce the ACID transactional properties of Atomicity, Consistency, Isolation, and Durability that are defined similarly as in DB systems.

Furthermore, we also support nesting of multi-step (long-term) transactions with sub-transaction semantics defined as for DB systems.

Sub-transactions can be packaged as separate smart contracts deployable on different blockchains, each one with its transaction mechanism. This is exploited in providing privacy, in that information used for processing of a sub-transaction is only accessible to actors participating in that activity.


Recent Research – SCaaS: Usability, Software Life Cycle Support, and Compliance

Our recent research has been addressing usability issues that hamper adoption. We show that (i) SCaaS can be used not only by a large company with ITS support, but also by an SME; (ii) SCaaS approach supports the Software Life Cycle, namely that the smart contracts can be upgradable and repairable, and (iii) SCaaS can be used to support (some of the) compliance requirements.

SCaaS for large companies and SMEs

  • Smart Contracts for SMEs and Large Companies. Liu, C. G.; Bodorik, P.; and Jutla, D. In 2024 IEEE Virtual Conference on Communications (IEEE VCC), 2024.

    We show that the SCaaS is simple enough that it can be used not only by large software companies with sophisticated IT support, but also by SMEs.

  • BPMN to Smart Contract by Business Analyst. Liu, C. G.; Bodorik, P.; and Jutla, D. In 5th Intelligent Cybersecurity Conference (ICSC 2025), IEEE Library (8 pages).

    We show how a Business Analyst (BA) in an SME, with a familiarity of BPMN modeling and basic understanding of file management and creating text of JSON files, can use the SCaaS tool to generate and deploy the smart, and interact with the smart contract execution.

SCaaS - support for the Software Life Cycle

A Smart contract is software, and it has been shown that software needs to be upgradable to stay relevant. We also address the issue of repairing a partially executed smart contracts that cannot complete its execution due to conditions in the external environment.

  • Automated Mechanism to Support Trade Transactions in Smart Contracts with Upgrade and Repair. Liu, C. G.; Bodorik, P.; and Jutla, D. In Elsevier Journal of Blockchain: Research and Applications, 2025.

    We present a methodology for upgrades of smart condtracts and for their repair when they fail due to unanticipated events. For instance, a smart contract that includes rail transport, may fail to complete due to a rail bridge being washed out by flood. The smart contract needs to be amended/repaired, to represent transport by road instead of by rail. The repair process begins by identifying the inner most transaction and its corresponding BPMN model fragment that caused the issue. The modeler amends the BPMN pattern, building on the successful completion of previous activities. If the fix requires changes outside the inner transaction, the BPMN model of the parent transaction is used instead. The corrected BPMN model is then transformed into a new smart contract to ensure consistent transitions while including the previously successfully completed activities. We describe TABS+R, a new tool for repairing smart contracts, which was developed by extending our previous tool, TABS+, a proof of concept for transforming BPMN models into smart contracts with nested transactions.

Support for Compliance and Reporting Requirements

Smart contracts deal with trade activities that need to comply with various regulations and reporting requirements. Trade activities may be subject to (i) Regulatory compliance, such as GDPR (EU), SOX (U.S.), and HIPPA (U.S.); (ii) Internal / Corporate Policy Compliance, such as internal policies on travel expenses or signing authority over expenses; (iii) Standards Compliance, such as PCI DSS (Payment Data); (iv) Contractual Compliance; (v) Environmental Compliance; (vi) Health and Safety Compliance; (vii) Data and Cybersecurity Compliance; and (viii) Financial Compliance. As the compliance requirements are subject to change, compliance of smart contracts to the various regulatory requirements causes difficulties with smart contracts due to smart contracts being deployed on blockchains that are immutable. We are investigating how upgradability and repair of smart contracts, provided by our SCaaS approach, can be exploited to support (some of the) regulatory requirements. We are currently preparing a publication describing our progress on this topic.