chorpiler v0.12.0

Chorpiler

• A compiler to transform BPMN 2.0 choreographies to efficient smart contract components, based on petri-net reductions.
• Current targets supported: Solidity Smart Contracts

Overview

Usage

Install and use through npm.

npm install chorpiler

Chorpiler offers two types of output that implement the process model: (i) a smart contract that can be used directly to execute the process, and performs conformance checks on each task. (ii) a state channel smart contract (see an example usage of channels in fstiehle/leafhopper).

See below example.

import chorpiler from 'chorpiler';

const parser = new chorpiler.Parser();

// to generate a smart contract implementing the process
const contractGenerator = new chorpiler
  .generators.sol.DefaultContractGenerator();

// (advanced) to generate a state channel  contract
const stateChannelGenerator = new chorpiler
  .generators.sol.StateChannelContractGenerator();

Complete example usage to parse and generate.

import * as fs from 'fs';
import chorpiler, { ProcessEncoding } from 'chorpiler';

const parser = new chorpiler.Parser();

const contractGenerator = new chorpiler
  .generators.sol.DefaultContractGenerator();

const bpmnXML = fs.readFileSync("yourBPMNXML.bpmn");   
// parse BPMN file into petri net
const iNet = await parser.fromXML(bpmnXML);

// compile to smart contract
contractGenerator.compile(iNet)
.then((gen) => {
  fs.writeFileSync(
    "Process.sol", 
    gen.target, 
    { flag: 'w+' }
  );
  console.log("Process.sol generated.");
  // log encoding of participants and tasks, 
  // can also be written to a .json file
  console.log(ProcessEncoding.toJSON(gen.encoding));
})
.catch(err => console.error(err));

For usage see also the tests defined in tests/compiler. For usage of the resulting smart contracts also see tests/output.

Run & Tests

If you have node installed, a simple npm install is enough. To confirm, you can execute tests using npm run test.

Two groups of tests exist:

• Testing the parser and compiler: By running npm run test/compiler, tests are executed confirming that the parser and compiler produce outputs from a range of correct and supported process models without reporting errors and rejects malformed and unsupported BPMN elements with reporting errors. These tests are found in tests/compiler.
• Testing the generated output: By running npm run test/output, tests are executed confirming that the produced outputs are valid artefacts, by replaying conforming logs (which must lead to a valid execution) and non-conforming logs (which must be rejected). Gas cost are also reported for the conforming logs. These tests are found in tests/output.

npm run test runs both test groups.

Architecture

!NOTE More on this soon.

Theory

Petri net generation

Our approach is based on the optimised translation technique presented in Garćıa-Bañuelos et al. 1: a process model is converted into a Petri net, and this net is reduced according to well-established equivalence rules. In the smart contract, the process state is then encoded as a bit array. Our approach is based on interaction Petri nets, which are a special kind of labelled Petri nets. Interaction Petri nets have been proposed as the formal basis for BPMN choreographies 2. As labels, they store the initiator and respondent information, which are essential for the channel construction. After conversion, we apply the same reduction rules as in 1.

In contrast to 1, we must restrict enforcement to certain roles: only initiators are allowed to enforce tasks.3 Thus, in our approach, we can differentiate between manual and autonomous transitions. Manual transitions correspond to tasks that are initiated by a participant; these must be explicitly executed. Autonomous transitions are the remaining silent transitions. Converting a process model into a Petri net creates silent transitions. While most of them can be deleted through reduction, some can not be removed without creating infinite-loops 1. These transitions must then be performed by the blockchain autonomously, given that the correct conditions are met. Consequently, these transitions are not bound to a role. The differentiation allows a more efficient execution: if the conditions for a manual task are met, it is fired and terminated; further autonomous transitions may be fired, without requiring further manual transitions.

1: Garćıa-Bañuelos, L., Ponomarev, A., Dumas, M., Weber, I.: Optimized Execution of Business Processes on Blockchain. In: BPM. Springer, Cham (2017) 130–146

2: Decker, G., Weske, M.: Local enforceability in interaction Petri nets. In: BPM. Volume 4714 of LNCS., Springer, Cham (2007) 305–319