Pith. sign in

REVIEW 4 major objections 5 minor 56 references

Transforming Automatically BPMN Models to Smart Contracts with Nested Collaborative Transactions (TABS+)

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A BPMN trade diagram can be compiled automatically into a smart contract whose nested collaborative transactions commit atomically and stay isolated.

desk verdict A solid incremental extension of the authors' TABS line that is worth refereeing despite overclaiming ACID enforcement for nested transactions. read the letter →

arxiv 2506.02727 v1 pith:5XUDCAXN submitted 2025-06-03 cs.SE

Christian Gang Liu , Peter Bodorik , Dawn Jutla This is my paper
classification cs.SE
keywords smartcontractgenerationBPMNnestedtransactionstwo-phasecommitSESEsubgraphsblockchaintradeDE-HSMmodelingautomatedsoftwaretransformation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

A multi-party trade workflow drawn in BPMN can be transformed automatically into a blockchain smart contract whose collaborative transactions—including nested sub-transactions—are enforced by generated coordination code rather than hand-written logic. The developer writes scripts only for individual, isolated tasks; synchronization, transaction boundaries, atomic commitment, and access control are supplied by the transformation. The method detects single-entry/single-exit regions of the workflow graph, lets the developer mark which regions are transactions, and generates one contract method per marked region, using a two-phase commit protocol to connect parent and child regions when they nest. A proof-of-concept tool and gas-cost estimates are presented, with the transaction mechanism roughly doubling base execution cost and nesting adding a linear overhead. If this holds, trade-and-finance smart contracts become largely model-driven artifacts rather than hand-crafted multi-method transaction programs.

What carries the argument

The load-bearing object is the SESE (single-entry/single-exit) subgraph of the DAG representation of the BPMN model: a connected region with one entry node and one exit node, so that once the flow of execution enters, it stays inside until it leaves through the exit. Three properties carry the argument: any two SESE subgraphs are either disjoint or one is properly nested inside the other; every non-entry/non-exit vertex has exactly one incoming and one outgoing edge; and each subgraph is acyclic, so it can be modeled with discrete-event concurrency and flattened state machines. The selected SESE subgraphs become separate smart-contract methods, and the pattern-augmentation machinery wraps them with a private workspace, begin/end transaction patterns, access control, and optional privacy; nesting is handled by a two-phase commit protocol in which each parent method is a coordinator and each child method is a participant.

What would settle it

Deploy a generated contract for a BPMN workflow that contains a loop or a data-based split inside a selected transaction region and check whether every ledger write inside that region commits or aborts together; also run a nested transaction in which one participant withholds its signed certification and observe whether the parent commits anyway, since the paper states that certification collection is not yet implemented.

Watch

Extended reading notes

Core claim

The central claim is that the localization property of single-entry/single-exit (SESE) subgraphs makes them the right units for multi-party transactions. From a well-formed BPMN model, the pipeline produces a DAG, then a discrete-event hierarchical state machine (DE-HSM) model, then a flattened discrete-event finite-state-machine (DE-FSM) model, and finally the methods of a smart contract; when the developer selects SESE subgraphs as transactions, each selected subgraph becomes a separate contract method that is isolated from non-transaction methods. Because any two SESE subgraphs are either disjoint or properly nested, the developer can compose transactions, and the generated mechanism coordinates a parent transaction with its children using a two-phase commit protocol, with the parent as coordinator and each child as participant. Transaction methods are augmented so that ledger reads and writes pass through a private workspace and are replayed to the ledger only at commit, with participants invited to certify results; three hosting options (single contract, separate contract on the same chain, separate contract on a sidechain) yield different privacy and cost profiles. The paper reports conformance testing of generated traces and cost estimates from the TABS+ proof-of-concept tool, concluding that supporting nested trade transactions is feasible but roughly doubles base execution cost.

Load-bearing premise

The pipeline assumes the BPMN model is well-formed, with no loops and no data-based splits or joins, so the workflow graph is a DAG and every selected SESE region truly contains its execution; if a real workflow breaks this, the generated transactions would not be isolated and the claimed all-or-nothing guarantees would not hold.

Editorial extensions

If this is right

  • Developers can generate transaction-aware smart contracts from BPMN models without decomposing workflows into multi-method transactions by hand; they supply scripts only for the isolated tasks inside BPMN elements.
  • A selected SESE region becomes its own contract method with its own private workspace, so transaction boundaries and isolation are enforced structurally rather than by developer convention.
  • Nested transactions commit atomically: a parent transaction acts as a two-phase commit coordinator, its child sub-transactions act as participants, and all units commit or abort together.
  • Supporting trade transactions costs roughly double the gas of the no-transaction baseline, because reads and writes are staged in a cache and replayed at commit; nested two-phase commit adds a further cost that grows linearly with the number of participants.
  • The three deployment options (single contract, separate contract on the same chain, separate contract on a sidechain) provide a concrete privacy-versus-cost trade-off, with the sidechain option also supporting cheaper execution.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Going beyond the paper: the containment order of SESE subgraphs could also drive automatic generation of compensation and rollback sequences, since the same structure that dictates two-phase commit order determines which activities must be undone first.
  • Going beyond the paper: the cost data suggest the practical ceiling is cache replay; moving the private workspace mostly off-chain, or using a cheap sidechain to host it, is the natural next experiment to make the approach viable at large data sizes.
  • Editorial note: the paper itself flags that the TABS+ tool does not yet collect the signed participant certifications it generates events for, so any deployment that relies on certification-backed commitment still needs that step completed.
  • A testable extension is to relax the well-formedness assumption by unrolling bounded loops or treating loop bodies as SESE sub-transactions; if the localization property survives that relaxation, the pipeline would cover substantially more real trade workflows.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper describes TABS+, an extension of the authors' earlier TABS approach for transforming BPMN process models into smart contract methods. The proposed method analyzes a DAG representation of a BPMN model, finds Single-Entry-Single-Exit (SESE) subgraphs, and lets the developer select which subgraphs should become collaborative trade transactions. Each selected SESE subgraph is turned into a separate smart contract method, and the paper describes a pattern-augmentation-based transaction mechanism, with nested transactions coordinated by a two-phase commit (2PC) protocol. The authors report a proof-of-concept tool, transformation delays, conformance testing, and gas-cost estimates for the transaction mechanism, including 2PC overhead. The central claim is that the automatically generated mechanism enforces the transactional properties of nested BPMN transactions.

Significance. If the claims were fully substantiated, the paper would address a real problem: reducing the developer effort in building multi-party blockchain applications by generating synchronization and transaction logic from BPMN models. The overall pipeline is clear, and the idea of using SESE subgraphs to find localizable collaborative transactions is a reasonable and potentially useful design principle. The paper also gives concrete gas-cost measurements for a benchmark transaction and for the 2PC protocol, which is useful information for practitioners. However, the strongest claim in the abstract and Section 3.2.4, that the mechanism 'enforces' ACID properties of nested transactions, is ahead of what the implementation and evaluation actually support. The paper's own limitations state that recovery is future work and that the collection of signed participant certifications is not implemented. No code or artifact is shipped, the validation is a single use case, and the transaction mechanism's failure behavior is not tested. These issues are central to the paper's contribution and require substantial revision.

major comments (4)
  1. [3.2.4, 4.5.2, 5.2] The central claim that the generated mechanism enforces ACID properties for nested transactions is not supported by the implementation described. Section 5.2 states that recovery is future work and that the TABS+ tool does not yet provide for the collection of signed certifications; Section 4.5.2 says that handling failures in blockchain applications remains an open problem for the approach. A 2PC protocol over an immutable ledger provides agreement on a commit decision, not atomic application of that decision: if the coordinator fails after some participants have committed, or if one participant's commit call reverts after another participant's writes have already been mined, there is no rollback mechanism for the already-applied ledger writes. The paper should either reframe the contribution as a best-effort optimistic commitment protocol or implement and evaluate the recovery and certification machinery that would be needed to substantiate the ACID claim.
  2. [3.2.4] The stated SESE property 2, that any non-entry/non-exit vertex has exactly one incoming and one outgoing edge, appears false for SESE subgraphs that contain fork or join gateways, which the paper's own use case contains in subgraphs such as S2 and S4. A diamond-shaped subgraph with a fork gateway and a join gateway has an interior gateway with multiple outgoing or incoming edges. Since this property is used in the discussion of why SESE subgraphs are suitable transaction patterns and in the classification of candidate transactions, the definition needs to be corrected or qualified, otherwise the SESE enumeration implemented in the tool is not well founded.
  3. [4.3, Table 2, Fig. 7] The reported cost-doubling result is essentially a consequence of the design rather than an empirical finding: because every ledger read and write is first stored in the cache and then replayed to the ledger at commit, the number of ledger accesses doubles by construction. Tables 2 and 3 therefore do not provide independent validation of the transaction mechanism; they should be presented as arithmetic consequences of the pattern augmentation together with measured per-access gas costs. In addition, Table 2's first column header reads '7KB' while the text of Section 4.3 says the smallest object is 75KB, and both tables are labeled 'CPU processing cost estimates' although the measurements are gas-cost estimates produced with the Remix compiler.
  4. [4.1, 4.5, 5.2] The feasibility claim rests on a single use case and on conformance testing that the paper itself characterizes as unsurprising because the transformations are direct mappings from BPMN to smart contract methods. The transaction mechanism's failure behavior is not tested at all: no experiments exercise aborts, participant crashes, coordinator failure, or the certification-collection path, and no code or artifact is provided. The proof-of-concept section should be reworded to state that the tool demonstrates the transformation pipeline and gas estimation only, and that the claimed transactional guarantees remain to be validated by failure-injection tests.
minor comments (5)
  1. [Throughout] The manuscript contains numerous typos and spelling errors, including 'PBMN', 'whrein', 'contins', 'byer', 'trnasactions', and 'transformation the smart contract'; these should be corrected in a careful copyedit.
  2. [Table 2 and Table 3] The header 'CPU processing cost estimates (in Gwei)' is misleading because the measurements are gas costs computed with the Remix compiler; the labels should be changed to 'estimated gas costs'.
  3. [Table 2 and Table 3] The first column header '7KB' is inconsistent with the text of Section 4.3, which lists 75KB as the smallest object size.
  4. [Section 4.4] The text says 'Fig. 13 shows the total cost estimates' for the 2PC protocol, but the supporting material is Table 4 and Fig. 12; the figure reference should be corrected.
  5. [Before Section 1] The ACM Reference Format block still contains the template placeholder text and should be replaced with the actual citation information for the paper.

Circularity Check

1 steps flagged · score 4.0 of 10

The ACID/nested-transaction enforcement claim rests on a load-bearing self-citation to the authors' prior Liu 2023 mm-transaction paper, while the paper's own limitations leave certification collection and recovery unimplemented; the SESE discovery, nested 2PC construction, and cost measurements are otherwise independent content.

  1. self citation load bearing [Section 3.2.4, 'Transactional Mechanism for Blockchain Multi-method Transactions'; Section 5.2, 'Limitations and Plans for Their Resolutions']
    "It is shown in (Liu 2023 [33]) that all the above options support the ACID properties."

    The paper's central claim is that TABS+ automatically enforces ACID/nested transactional properties. For the enforcement mechanism, the paper does not prove this claim here; it defers to Liu 2023, by the same authors, for pattern augmentation and for the statement that all cache/workspace options support ACID. This is a load-bearing self-citation: the core transactional-property result reduces to the prior authors' assertion. Section 5.2 then concedes that the current TABS+ tool 'does not yet provide for the collection of signed certifications' and that recovery is being 'currently researching this problem', so the present implementation cannot fully realize the cited ACID mechanism.

full rationale

The derivation chain from BPMN to DAG to DE-HSM/DE-FSM to smart-contract methods is a construction, not a prediction, and the cost measurements are experimental estimates rather than fitted quantities. The cost-doubling result is explicitly explained as a consequence of the cache-then-replay design, so it is not a hidden assumption dressed as an empirical finding. The SESE localization argument is presented with a graph-based rationale, and the nested 2PC coordination is a standard protocol implemented for the proof of concept. The main circularity concern is the ACID-enforcement claim, which is imported from the authors' prior Liu 2023 mm-transaction paper via self-citation and is further weakened by the paper's own limitations on certification collection and recovery. Because the nested-transaction construction and cost evaluation have independent content, this is partial circularity rather than a fully forced result.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

No new entities are postulated. The load-bearing assumptions are well-formed BPMN (no loops, no data-based gateways), SESE localization, availability of a persistent private workspace, and the applicability of two-phase commit on an immutable blockchain. The only numeric constant chosen by hand is the gas price used for cost estimates.

free parameters (1)
  • Gas price for cost estimates = 20 Gwei
    The authors standardized gas price to 20 Gwei to maintain consistency with the default Ganache price (Section 4.3). This hand-chosen assumption affects all absolute cost numbers, though relative costs (doubling, linear scaling) are largely insensitive.
assumptions (4)
  • domain assumption Any BPMN model can be transformed into an equivalent well-formed model with one start, one end, no data-based splits/joins, and no loops.
    Invoked in Section 3.1.2 to justify DAG construction; if this transformation is not semantics-preserving for the BPMN subset supported by TABS, the subsequent SESE analysis is invalid.
  • domain assumption SESE subgraphs of the DAG have the localization property: computation entering via the entry node remains inside until exiting via the exit node.
    Used in Section 3.2.3 to claim that a transaction method does not interfere with external methods, which is the basis for applying the multi-method transaction mechanism.
  • domain assumption A private cache/workspace can persist across smart contract method invocations and be shared by all transaction participants, either via a ledger-hosted location or a sidechain.
    Required by the optimistic transaction mechanism in Section 3.2.4; the paper provides no implementation details or proof that the cache is tamper-resistant or unavailable to non-participants.
  • domain assumption The two-phase commit protocol between parent and child transactions preserves atomicity on an immutable blockchain if all expected participant messages arrive.
    Section 3.3 assumes standard 2PC properties and does not address participant failure, timeout, or recovery; the paper later lists recovery as future work.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Transforming Automatically BPMN Models to Smart Contracts with Nested Collaborative Transactions (TABS+)." pith.science (2026). https://pith.science/paper/5XUDCAXN

@misc{pith2026250602727,
  author       = {Pith},
  title        = {Pith review of: Transforming Automatically BPMN Models to Smart Contracts with Nested Collaborative Transactions (TABS+)},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5XUDCAXN}},
  note         = {Machine review of arXiv:2506.02727}
}
read the original abstract

Development of blockchain smart contracts is more difficult than mainstream software development because the underlying blockchain infrastructure poses additional complexity. To ease the developer's task of writing smart contract, as other research efforts, we also use Business Process Model and Notation BPMN modeling to describe application requirements for trade of goods and services and then transform automatically the BPMN model into the methods of a smart contract. In our previous research we described our approach and a tool to Transform Automatically BPMN models into Smart contracts TABS. In this paper, we describe how the TABS approach is augmented with the support for a BPMN collaborative transaction by several actors. Our approach analyzes the BPMN model to determine which patterns in the BPMN model are suitable for use as collaborative transactions. The found BPMN patterns that are suitable as transactions are shown to the developer who decides which ones should be deployed as collaborative transactions. We describe how our approach automatically transform the BPMN model into smart contract the provides a transaction mechanism to enforce the transactional properties of the nested transactions. Our approach greatly reduces the developers task as synchronization of collaborative activities is provided by our approach, so that the developer needs to code only independent tasks with well-defined inputs and outputs. We also overview the TABS+ tool we built as a proof of concept to show that our approach is feasible. Finally, we provide estimates on the cost of supporting the nested BPMN collaborative transactions.

Figures

Figures reproduced from arXiv: 2506.02727 by the authors.

Figure 1
Figure 1. Inclusive fork gate resulting in a control FSM and one FSM for each concurrent process streams (adopted from (Liu 2021 [30]) 2.3.2 Transforming a DE-FSM Model into the Methods of a Smart Contract So how are the smart contract methods formed? Each actor has a smart contract method that acts as an interpreter and provides the execution environment for an actor as represented using the DE-FSM modeling. In other words, … view at source ↗
Figure 2
Figure 2. Architecture Overview (adopted from (Bodorik 2023 [4])) The following subsections describe the overall process of transforming a BPMN model into the methods of a smart contract under the developer’s guidance with the support for specifying nested BPMN trade transactions together with the description how the transactional support for the BPMN trade transactions, even when nested to support sub-transactions, is achiev… view at source ↗
Figure 3
Figure 3. BPMN model and found subgraphs mapped back to the BPMN model. (Adopted from (Bodorik 2023 [4])) [PITH_FULL_IMAGE:figures/full_fig_p014_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: SESE subgraph S5 contains SESE subgraphs S1 and S2. When a developer selects a transaction with nested sub-transaction, the construction of the transactional mechanism for the nested transaction proceeds bottoms up, starting with creating the mechanism for the innermos…
Figure 5
Figure 5. Figure 5: shows two screenshots of the tool for the use case shown in [PITH_FULL_IMAGE:figures/full_fig_p023_5.png]
Figure 6
Figure 6. Figure 6: is a partial screen of the tool showing the SESE subgraphs for selection to be treated as trade transactions. All SESE subgraphs are listed, while the first four subgraphs, S1, S2, S3, and S4, are the four SESE subgraphs shown in [PITH_FULL_IMAGE:figures/full_fig_p024…
Figure 7
Figure 7. Figure 7: Estimated CPU processing costs (in Gwei) as a function of data size [PITH_FULL_IMAGE:figures/full_fig_p026_7.png]
Figure 8
Figure 8. Figure 8: Estimated CPU processing costs (in Gwei) for cases labeled as “no-xa”, “sc-2s”, and “sc-2s-crypto” [PITH_FULL_IMAGE:figures/full_fig_p027_8.png]
Figure 9
Figure 9. Figure 9: User selecting subgraphs S3, S4, and S5, wherein S5 contins SESE subgraphs S1 and S2. The graphical representation of the methods for the smart contracts are shown in [PITH_FULL_IMAGE:figures/full_fig_p028_9.png]
Figure 10
Figure 10. Figure 10: Methods for trade transaction S4, S4, and S5, whrein S5 has sub-trnasactions S1 and S2. Recall that to support the atomicity of the parent transaction with its sub-transactions, a 2PC protocol is used, with each parent transaction acting as a coordinator of the 2PC pr…
Figure 11
Figure 11. Figure 11: Sequence Diagram Illustrating the 2-Phase Commit Protocol for Nested Transactions. During the commitment stage of nested transactions within the parent transaction, the coordinator initiates the 2-phase commit by triggering the 'event' of the smart contracts, which se…
Figure 12
Figure 12. Figure 12: Gas Utilization by the 2-Phase Commit Protocol for Nested Transactions. 4.5 Benefits and Drawbacks of Supporting Trade Transactions with Nesting 4.5.1 Benefits Similar to supporting nested transactions in DB systems, there are numerous benefits gained if their support…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

56 extracted references · 35 canonical work pages

  1. [1]

    About the Business Process Model and Notation Specification 2.0. (2010). Retr. 2024/02/15 https://www.omg.org/spec/bpmn/2.0/About- 40 BPMN

    work page 2010

  2. [2]

    Belchior, R., Vasconcelos, A., Guerreiro, S., & Correia, M. (2021). A Survey on Blockchain Interoperability: Past, Present, and Future Trends. ACM Computing Surveys, Vol. 4, Issue 8. Article No. 168, pp 1–41. Retr. 2024/02/15 https://doi.org/10.1145/3471140

    doi:10.1145/3471140 2021

  3. [3]

    Simplify Contract Management with Bitregalo' sSmart Contract as a Service (SCaaS)

    Bitregalo (n.d.). Simplify Contract Management with Bitregalo' sSmart Contract as a Service (SCaaS). Retr. 2023/20/30 https://www.bitregalo.com/scaas

    work page 2023

  4. [4]

    Liu, C., & Julta, D

    Bodorik, P., G. Liu, C., & Julta, D. (2021). Using FSMs to Find Patterns for Off-Chain Computing. Proc. 3rd Int. Conf. on B lockchain Technology, 2021, 28–34. Retr. 2024/02/15 https://doi.org/10.1145/3460537.3460565

    arXiv 2021

  5. [5]

    G., & B Jutla, D

    Bodorik, P., Liu, C. G., & B Jutla, D. (2023). TABS: Transfo rming automatically BPMN models into blockchain smart contracts. Elsevier Journal of Blockchain: Research and Applications, 100115, pp. 1-26. Retr. 2024/02/15 https://doi.org/10.1016/j.bcra.2022.100115

    arXiv 2023

  6. [6]

    Bostock, M., Ogievetsky, V., and Heer, J. (2011). Data-Driven Documents. In IEEE Transactions on Visualization and Computer Graphics, Vol 17, Issue 12. pp. 2301-2309

    work page 2011

  7. [7]

    BPMN 2.0 Introduction - Flowable Open-Source Documentation. (n.d.). Retrieved Oct. 3, 2023, Retr. Oct 30, 2023, from: https://flowable.com/open-source/docs/

    work page 2023

  8. [8]

    BPMN 2.0 Symbols—A complete guide with examples. (n.d.). Camunda. Retr. 2024/02/15 https://camunda.com/bpmn/reference/

    work page 2024

Show all 56 references
  1. [9]

    Business Process Model and Notation (BPMN), Version 2.0.2. (n.d.). Retr. 2024/02/15 https://www.omg.org/spec/BPMN/2.0.2/PDF

    2024

  2. [10]

    Buterin, V. (2015). Ethereum White Paper: A Next Generati on Smart Contract & Decentralized Application Platform. Retr. 2024/02/15 https://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf

    2015

  3. [11]

    Process Orchestration for end-to-end automation

    Camunda (n.d.). Process Orchestration for end-to-end automation. Retr. 2024/02/15 https://camunda.com

    2024

  4. [12]

    Cassandras, C. (1993). Discrete event systems: Modeling and performance analysis. CRC Press. 1st ed. ISBN 10: 0256112126

    1993

  5. [13]

    Chaum, D. (1983). Blind Signatures for Untraceable Payments. In D. Chaum, R. L. Rivest, & A. T. Sherman (Eds.), Advances in Cryptology. Springer US. pp. 199–203. Retr. 2024/02/15 https://doi.org/10.1007/978-1-4757-0602-4_18

    1983 doi

  6. [14]

    Deehan, N. (2021). How Developing Java Apps is Ea sier with a Process Engine. Camunda. Retr. 2024/02/15 https://camunda.com/blog/2021/11/how-developing-java-apps-is-easier-with-a-process-engine/

    2021

  7. [15]

    and We ber I

    Di Ciccio C., Cecconi A., Dumas M., García-Bañuelos L., López-Pintado O., Lu Q., Mendling J., Ponomarev A., Tran A. and We ber I. (2019). Blockchain Support for Collaborative Business Processes. Informatik Spektrum Journal, Vol. 42, pages 182–190

    2019

  8. [16]

    Dijkman, R., Du mas, M., & Ouyang, C. (2008). Semantics and Analysis of Business Process Models in BPMN. Elsevier Journal on Information and Software Technology, Vol. 50, Issue 12, pp. 1281–1294. Retr. 2024/02/15 https://doi.org/10.1016/j.infsof.2008.02.006

    2008 doi

  9. [17]

    Ethereum Average Block Size. (n.d.). Retr. 2024/02/15 https://ycharts.com/indicators/ethereum_average_block_size

    2024

  10. [18]

    Ethereum Virtual Machine (EVM). (2023). Retr. 2024/02/15 https://ethereum.org/developers/docs/evm

    2023

  11. [19]

    A., Sánchez-Gómez, N., Lizcano, D., Escalona, M

    Garcia-Garcia, J. A., Sánchez-Gómez, N., Lizcano, D., Escalona, M. J., & Wojdyński, T. (2020). Using Blockchain to Improve Collaborative Business Process Management: Systematic Literature Review. IEEE Access, Vol. 8, pp. 142312–142336. Retr. 2024/02/15 https://doi.org/10.1109/...

    2020

  12. [20]

    Girault, A., Lee, B., & Lee, E. A. (1999). Hierarchical finite state machines with multiple concurrency models. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 18(6), 742–760. Retr. 2024/02/15 https://doi.org/10.1109/43.766725

    1999 doi

  13. [21]

    Graph Visualization Software Documentation

    Graphviz (n.d.). Graph Visualization Software Documentation. Retr. 2024/02/15 https://graphviz.org/documentation/

    2024

  14. [22]

    Harel, D. (1987). Statecharts: A visual formalism for complex systems. Elsevier Journal of Science of Computer Programming, Vol. 8, Issue 3, pp. 231–274. Retr. 2024/02/15 https://doi.org/10.1016/0167-6423(87)90035-9

    1987 doi

  15. [23]

    Hoare, C. A. R. (1978). Communicati ng sequential processes. Communications of the ACM, Vol. 21, Issue 8, pp. 666–677. Retr. 2024/02/15 https://doi.org/10.1145/359576.359585

    1978

  16. [24]

    Hyperledger. (n.d.). Hyperledger Composer. Retr. 2024/02/15 https://hyperledger.github.io/composer/latest/

    2024

  17. [25]

    Ismael. (2019). Gas cost of a sha256 has h. Ethereum Stack Exchange. Retr. 2024/02/15 https://ethereum.stackexchange.com/a/76114

    2019

  18. [26]

    N., Loukil, F., Ghedira-Guega n, C., Benkhelifa, E., & Bani-Hani, A

    Khan, S. N., Loukil, F., Ghedira-Guega n, C., Benkhelifa, E., & Bani-Hani, A. (2021). Blockchain smart contracts: Applications, challenges, and future trends. Peer-to-Peer Networking and Applications, 14(5), pp. 2901–2925. Retr. 2024/02/16 https://doi.org/10.1007/s12083-021-01127-0

    2021 doi

  19. [27]

    Lauster, C., Klinger, P., Schwab, N., & Bodendorf, F. (2020). Literature Review Linking Blockchain and Business Process Management. Smart Cities 6(3), 2023, pp. 1254-1278. Retr. 2024/02/16 https://www.mdpi.com/2624-6511/6/3/61

    2020

  20. [28]

    Levasseur, O., Iqbal, M., & Matulevi čius, R. (2021). Survey of Model-Driven Engineering Techniques for Blockchain-Based Applications. Proc. 14th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modelling, 2021. Retr. 2024/02/16 https://ceur-ws.org/Vol- 3045/paper02.pdf

    2021

  21. [29]

    Liu, C., Bodorik, P., & Jutla, D. (2021a). A Tool for Moving Blockchain Computations Off-Chain. Proc. 3rd ACM Int. Symp. on Blockchain and Secure Critical Infrastructure, 103–109. Retr. 2024/02/16 https://doi.org/10.1145/3457337.3457848

    2021

  22. [30]

    (20 21b)

    Liu, C., Bodorik, P., & Jutla, D. (20 21b). BPMN to smart contracts on blockchains: Transforming BPMN to DE-HSM multi-modal model. Proc. 2021 Int. Conf. on Engineering and Emerging Technologies (ICEET), 1–7. Retr. 2024/02/16 https://doi.org/10.1109/ICEET53442.2021.9659771

    2021

  23. [31]

    G., Bodorik, P., & Jutla, D

    Liu, C. G., Bodorik, P., & Jutla, D. (2021c). Automating Smart Contract Generation on Blockchains Using Multi-modal Modeling. Journal of Advances on information Technology (JAIT), Vol. 13(3), pp. 213–223. Retr. 2024/02/16 https://doi.org/10.12720/jait.13.3.213-223. 41

    2021 doi

  24. [32]

    G., Bodorik , P., & Jutla, D

    Liu, C. G., Bodorik , P., & Jutla, D. (2022). Supporting Long-term Transactions in Smart Contracts. Proc. Int. Conf. on Blockchain Computing and Applications (BCCA), pp. 11–19. Retr. 2024/02/16 https://doi.org/10.1109/BCCA55292.2022.9922193

    2022

  25. [33]

    Liu, C., Bodorik, P., & Jutla, D. (2 023). Long-Term Blockchain Transactions Spanning Multiplicity of Smart Contract Methods. Proc. int. Conf. on Blockchain and Trustworthy Systems (BlockSys’2023), Springer, pp. 141–155. Retr. 2024/02/16 https://doi.org/10.1007/978- 981-99-8104-5

    2023 doi

  26. [34]

    López-Pintado, O., Dumas, M., García-Bañuelos, L., & Weber, I. (2019). Giorgini, P., Weber, B. (eds) Advanced Information Systems Engineering. Proc. CAiSE 2019. Lecture Notes in Computer Science(), vol 11483. Springer, Cham. Retr. 2024/02/a6 https://doi.org/10.1007/978-3-030-2...

    2019 doi

  27. [35]

    López-Pintado, O., García-Bañuelos, L., Dumas, M., Weber, I., & Ponomarev, A. (2019). CATERPILLAR: A Business Process Execution Engine on the Ethereum Blockchain. Software: Practice and Experience, Vol. 49, Issue 7, pp. 1162-1193. Retr. 2024/02/16 https://doi.org/10.48550/arXi...

    2019 doi arXiv

  28. [36]

    Loukil, F., Boukadi, K., A bed, M., & Ghedira-Guegan, C. (2021). Decentralized collaborative business process execution using blockchain. World Wide Web, 24(5), 1645–1663

    2021

  29. [37]

    Marr, B. (2017). A Short History of Bitcoin and Crypto Currency Everyone Should Read. Forbes Newsletter. Retr. 2024/02/16 https://www.forbes.com/sites/bernardmarr/2017/12/06/a-short-history-of-bitcoin-and-crypto-currency-everyone-should-read/

    2017

  30. [38]

    Mavridou, A., & Laszka, A. (2018a). De signing Secure Ethereum Smart Contracts: A Finite State Machine Based Approach. Proc . Int. Conf. Financial Cryptography and Data Security. Springer LNCS, Vol. 109 57, pp. 523-540. Retr. 2024/02/16 https://doi.org/10.48550/arXiv.1711.09327

    2018 doi arXiv

  31. [39]

    Mavridou, A., & Laszka, A. (2018b). Tool Demonstration: FS olidM for Designing Secure Ethereum Smart Contracts. Proc. Principles of Security and Trust (POST 2018). Springer LNCS, Vol. 10804, pp. pp. 217-277. Retr. https://link.springer.com/book/10.1007/978-3-319- 89722-6 https...

    2018 doi

  32. [40]

    Mendling, J., Webe r, I., Aalst, W. V. D., Brocke, J. V., Cabanillas, C., Daniel, F., Debois, S., Ciccio, C. D., Dumas, M., Dustdar, S., Gal, A., García-Bañuelos, L., Governatori, G., Hull, R., Rosa, M. L., Leopold, H., Leymann, F., Recker, J., Reichert, M., … Zhu, L. (2018). ...

    2018 doi

  33. [41]

    Nabben, K. (2022). Decentralized Technology in Practice: Social and technical resilience. Proc. 42nd Int. Conf. on Distributed Computing Systems Workshops (ICDCSW), pp. 66–72. Retr. 2024/10/16 https://ieeexplore.ieee.org/document/9951370

    2022

  34. [42]

    Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. Originally published as a white paper on a mailing list metzdowd.com on Oct. 31, 2008. Retr. 2024/10/16 https://bitcoin.org/bitcoin.pdf

    2008

  35. [43]

    Node.js – Open-source, cross-platform Java Script runtime environment. (n.d.). Retr. 2024/10/16 https://nodejs.org/en

    2024

  36. [44]

    InterPlanetary File System (IPFS): Concepts. (n.d.) . Retr. 2024/02/16 https://docs.ipfs.tech/concepts/

    2024

  37. [45]

    Ethereum’s New 1MB Blocksiz e Limit. (2021). In Bitmex Research Blog. Retr. 2024/10/16 https://blog.bitmex.com/ethereums-new-1mb- blocksize-limit/

    2021

  38. [46]

    Saito, K., & Yamada, H. (2016). What’s So Different about Blockchain? — Blockchain is a Probabilistic State Machine. Proc. 36th Int. Conf. on Distributed Computing Systems Workshops (ICDCSW), pp. 168–175. Retr. 2024/10/16 https://doi.org/10.1109/ICDCSW.2016.28

    2016 doi

  39. [47]

    Simba: Smart-Contract-as-a-Service User Guide

    Simbachian.com (n.d.). Simba: Smart-Contract-as-a-Service User Guide. Retr. 2024/10/16 https://simbachain.com/wp- content/uploads/2019/08/SIMBA-SCaaS-User-Guide-v1.0.2.pdf

    2024

  40. [48]

    Steichen, M., Fiz Pont iveros, B., Norvill, R., Shbair, W., & State, R. (2018). Blockchain-Based, Decentralized Access Control for IPFS. Proc. 2018 IEEE Int. Conf. on iThings and GreenCom and CPSCom and SmartData, pp. 1499-1506. Retr. 2024/02/16 https://doi.org/10.1109/Cyberma...

    2018

  41. [49]

    Szabo, N. (1996). Smart Contracts: Bu ilding Blocks for Digital Free Markets. Extropy Journal of Transhuman Thought, 16

    1996

  42. [50]

    J., Dargahi, T

    Taylor, P. J., Dargahi, T. , Dehghantanha, A., Parizi, R. M., & Choo, K.-K. R. (2020). A systematic literature review of blockchain cyber security. Digital Communications and Networks, 6(2), 147–156. Retr. 2024/10/16 http://doi.org/10.1016/j.dcan.2019.01.005

    2020 doi

  43. [51]

    Tran, A., Lu, Q., & Weber I. (2018). Lorikeet: A Model-Dri ven Engineering Tool for Blockchain-Based Business Process Execution and Asset Management. Proc. 2018 Int. Conf. on Business Process Management, pp. 1-5. Retr. 2024/02/16 https://api.semanticscholar.org/CorpusID:52195200

    2018

  44. [52]

    Dikmans, L. (2008). Transforming BPMN into BPEL: Why and How. Oracle Middleware/Technical Details/Technical Article. Retr. 2024/10/16 https://www.oracle.com/technical-resources/articles/dikmans-bpm.html

    2008

  45. [53]

    Truffle: The most comprehensive suite of tools for smart c ontract development. (n.d.). Truffle Suite Documentation. Retr. 2024/10/16 https://trufflesuite.com

    2024

  46. [54]

    A., & Canfora, G

    Vacca, A., Di Sorbo, A., Visaggio, C. A., & Canfora, G. (2021). A systematic literature review of blockchain and smart contract development: Techniques, tools, and open challenges. Journal of Systems and Software, Vol. 174, 110891. Retr. 2024/10/16 https://doi.org/10.1016/j.js...

    2021

  47. [55]

    Weber, I., Xu, X., Riveret, R., Governatori, G., Ponomare v, A., & Mendling, J. (2016). Untrusted Business Process Monitoring and Execution Using Blockchain. Proc. Int. Conf. 2016 on Business Process Management, pp. 329–347, M. La Rosa, P. Loos, & O. Pastor (Eds.), Springer In...

    2016 doi

  48. [56]

    Yannakakis, M. (2000). Hierarchical State Machines. Proc. IF IP Int. Conf. on Theoretical Computer Science, Exploring New Frontiers of 42 Theoretical Informatics, pp. 315–330, ACM

    2000

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.