Pith. sign in

REVIEW 4 major objections 4 minor 71 references

Automated Mechanism to Support Trade Transactions in Smart Contracts with Upgrade and Repair

T0 review · 4 major / 4 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 The paper claims that a failed multi-step trade transaction in a smart contract can be repaired by amending only the innermost failing BPMN pattern, regenerating that sub-contract, and redirecting the application API, while keeping…

desk verdict A clearly described but unvalidated extension of the authors' own TABS+ line: the repair idea is new and plausible, but the paper never explains how state survives the swap from old contract to new one. read the letter →

arxiv 2506.03877 v1 pith:RVIM6GOJ submitted 2025-06-04 cs.SE

Christian Gang Liu , Peter Bodorik , Dawn Jutla This is my paper
classification cs.SE
keywords smartcontractsBPMNnestedtradetransactionstransactionrepaircontractupgrademodel-drivendevelopmentTABS+Rblockchain
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

The paper tries to establish a repair methodology for smart contracts that model multi-step trade transactions: when an unanticipated failure stops a trade, the developer can repair the contract at the level of the smallest nested transaction that failed, rather than rebuilding the whole contract. The method identifies the BPMN pattern corresponding to the failed subtransaction, replaces that pattern with an amended one that uses at most the same inputs and produces at least the same outputs, and then regenerates a new smart contract for the repaired pattern. Because each trade subtransaction is packaged as its own smart contract and applications invoke it through an API layer, the repaired contract can be swapped in by updating the API, leaving previously completed activities untouched. A proof-of-concept tool, TABS+R, demonstrates the repair flow on a transport-insurance example. The approach matters because blockchain immutability otherwise makes adapting a stuck contract to changed real-world arrangements expensive and risky.

What carries the argument

The load-bearing object is the nested trade transaction, realized by packaging each BPMN single-entry/single-exit (SESE) subgraph selected by the developer as a separate smart contract. The transformation pipeline converts a BPMN model into a DAG, identifies SESE subgraphs, builds a discrete-event hierarchical state machine model, and generates smart contract methods whose transactions commit ledger writes only at commit time. Repair works by regenerating the smart contract for the amended BPMN pattern and using the application API indirection to redirect invocations to the new version, so the ledger and the execution engine see the repaired pattern as a fresh transaction that reuses earlier completed work.

What would settle it

Set up the running example: a doTransport subtransaction fails when rail transport is impossible, and repair using road transport is attempted while the existing insurance covers rail only. If TABS+R accepts the repaired pattern without escalating to the parent, and the subsequent receive-and-finalize activity completes using road-transport objects the original contract never supplied, then the claimed localization guarantee is refuted. A static counterexample would be a repaired BPMN pattern whose declared input set is not a subset of the failed pattern's inputs yet the tool generates and deploys a contract for it.

Watch

Extended reading notes

Core claim

The central claim is that a failed trade (sub)transaction can be repaired locally: identify the innermost BPMN pattern that failed, amend it so its inputs are a subset of the original inputs and its outputs a superset of the original outputs, generate a new smart contract for the repaired pattern, and replace the old contract invocation via the dApp API update. Completed activities and data consistency are preserved because the repaired pattern is constrained to consume no information the preceding activities did not already produce and to emit at least the information the succeeding activities expect. If the constraints cannot be satisfied within the innermost pattern, repair escalates to the parent transaction's BPMN pattern, and the same procedure restarts at that wider scope.

Load-bearing premise

The repair stays correct only if the developer's manual judgment that the repaired pattern consumes no new inputs and emits all required outputs is right; nothing in the tool checks that judgment, and a wrong call lets the repaired contract consume unavailable information or produce insufficient outputs.

Editorial extensions

If this is right

  • Repairs can be localized to the failed subtransaction; if the pre- and post-repair conditions hold, preceding and succeeding trade activities need no amendment.
  • If the pre-repair condition fails, such as rail insurance not covering road transport, repair escalates to the parent transaction, making the repair scope exactly the smallest pattern whose input and output contract can be satisfied.
  • Completed activities from the failed version are reused because the regenerated contract is deployed alongside the old one and invocation is switched via an API update, not by rewriting ledger history.
  • The approach lowers the cost of adapting smart contracts to unanticipated events, since the developer amends a model fragment instead of writing a full replacement contract.
  • The same pattern-replacement mechanism can support contract customization beyond repair, such as swapping subtransaction patterns to suit a different business context.

Reading between the lines

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

  • Editorial inference: If the pre- and post-repair conditions were checked automatically by data-flow analysis or formal object typing, the repair guarantee could become machine-verifiable; the paper leaves that judgment to the developer.
  • Editorial inference: The repair-as-pattern-replacement idea generalizes beyond failure repair to proactive contract evolution, where any upgrade that preserves a subtransaction's input and output envelope can be hot-swapped without disturbing neighboring activities.
  • Editorial inference: The same nested-transaction structure could support rollback-free compensation, since a repaired pattern can be treated as a new subtransaction that carries the trade forward instead of compensating completed activities.
  • Editorial inference: A testable extension is to run the tool on failing BPMN models where the developer deliberately makes a wrong repair judgment; a runtime type or consistency check on subsequent activities would then reveal how much the guarantee depends on human accuracy.
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 / 4 minor

Summary. This paper extends the authors' earlier BPMN-to-smart-contract transformation work (TABS/TABS+) with a methodology for repairing failed multi-step nested trade transactions. When an unhandled exception prevents completion, TABS+R identifies the BPMN pattern of the innermost failed trade transaction, the developer amends that pattern under stated pre- and post-repair conditions, TABS+R generates and deploys a new smart contract, and the dApp's API is updated to invoke the new contract instead of the old one. The paper claims that completed activities can be retained and that the repaired contract ensures consistent data and logic transitions. It also describes recovery procedures for failed trade transactions and presents the TABS+R tool as a proof of concept, illustrated with a rail-transport repair scenario.

Significance. If the repair methodology worked as claimed, it would be a useful contribution to smart-contract upgradeability in BPMN-driven collaborative business processes, because nesting transactions and packaging each subtransaction as a separate contract could localize repairs. The paper's conceptual chain from BPMN through SESE subgraphs and DE-HSM models to smart contracts is clear, and the pre/post-repair constraints are a sensible way to reason about localizing a repair. The TABS+R proof of concept with a realistic rail/road transport scenario is a concrete demonstration of the workflow. However, the central claim that completed activities are preserved and consistency is ensured is not established: the only replacement step described is an API redirect, no state-handover mechanism is specified, the pre/post condition check is explicitly left to the developer, and the paper acknowledges in Sections 5.3 and 6.2.2 that formal evaluation and verification are future work. These gaps make the contribution conditional on a concrete and validated repair mechanism.

major comments (4)
  1. [§4.2.3(ii), §5.2] The described replacement mechanism does not transfer any state from the failed contract to the repaired contract. Section 4.2.3(ii) states that the upgrade is accomplished by updating the dApp API to point to the new smart contract, and Section 5.2 repeats that an API update plus deployment is the whole replacement step. Because Section 2.3 says ledger writes are cached and committed only at trade-transaction commit, and because each trade (sub)transaction is packaged in a separate smart contract, a newly deployed replacement contract has no access to the storage of the old contract or to the outputs of previously completed activities in that transaction. The claim that completed activities are retained and that the repaired contract can continue the workflow is therefore not supported by the described mechanism. The paper needs to specify how state is handed over: for example, by inheriting the old contract's storage, by reading the old contract through a proxy, or by requiring the caller to re-supply the outputs of completed subtransactions, together with a precise statement of which activities are considered committed at the time of repair.
  2. [§4.3.1, §4.2.2] The repair-localization guarantee depends on the pre-repair condition that the repaired pattern's inputs match or are a subset of the original inputs, and the post-repair condition that its outputs match or are a superset of the original outputs. Section 4.3.1 states explicitly that the decision whether these conditions hold is left to the developer without tool assistance, using the example of deciding whether rail insurance covers road transport. If this manual judgment is wrong, the repaired pattern can consume inputs that were not produced by preceding activities or emit insufficient outputs for succeeding activities, breaking consistency. Because these conditions are the only mechanism connecting the repaired pattern to the rest of the workflow, the central consistency claim is contingent on an unvalidated human step. The paper should either provide tool support for checking the conditions or weaken the stated guarantee accordingly.
  3. [§5.3, §6.2.2] The paper's central claim that the repaired smart contract ensures 'consistent data and logic transitions' is not demonstrated by proof or evaluation. Section 5.3 states that the current version of TABS+R is not ready for formal evaluation and reports only informal demonstrations, and Section 6.2.2 lists formal verification of the generated contracts as future work. For a journal paper making a consistency guarantee about a repair mechanism, the authors should provide at least a correctness argument relating the pre/post conditions and the state-handover mechanism to the preservation of completed activities, or an evaluation with concrete execution traces showing that repaired contracts continue correctly from prior state.
  4. [§3.1, §4.3.2] The transaction semantics are ambiguous about whether subtransactions commit independently or atomically with their parent, and this ambiguity directly affects what 'completed activities' means for repair. Section 3.1 says ledger writes are committed only at trade-transaction commit and that recovery of subtransactions runs before parent recovery, which suggests that a failed parent rolls back its subtransactions. Section 4.3.2 then says atomic commitment of subtransactions is coordinated via 2PC. If subtransactions do not commit before the parent commits, then when doTransport_tx fails, earlier subtransactions such as GetRailInsurance and GetRailTransporter have not committed, so their outputs cannot be preserved for a repaired parent contract. If instead they commit independently, the recovery and 2PC discussion in Sections 3.1 and 4.3.2 needs to be revised. The paper should state exactly which activities are committed and available when a repair begins.
minor comments (4)
  1. [§4.3.2] The paper states that 2PC 'requires the order of n^2 messages for n participants'; the standard two-phase commit protocol uses O(n) messages for n participants, so this overhead claim should be corrected or justified.
  2. [§1, References [9] and [11]] The sentence citing 'López-Pintado (2019) [9, 11]' appears to misassign reference [9] (Levasseur et al.) to López-Pintado; the citation should be checked and corrected.
  3. [Fig. 1 caption] The caption reads 'created using Camunda platform [11]', but reference [11] is the Caterpillar paper; the Camunda reference is [28] in the text.
  4. [§4.1, §7] There are typos in the text: 'BPNM' appears where 'BPMN' is intended in Section 4.1, and 'PBMN' appears in Section 7 where 'BPMN' is intended.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the repair mechanism is a constructive pipeline; reliance on prior TABS+/TABS work is normal self-extension, not a derivation that reduces to its own inputs.

full rationale

The paper does not fit parameters, invert an equation into its own conclusion, or rename a known result. The repair method is a specified procedure: identify the innermost failed BPMN pattern, have the developer amend the pattern under stated pre- and post-repair constraints, regenerate a smart contract from the amended BPMN model, and redirect the dApp API to the new contract. Each step is defined operationally, not as a quantity that is fitted to the outcome it is then said to predict. The pre- and post-repair conditions in Section 4.2.2 are constraints on the repaired pattern, and the paper explicitly acknowledges in Section 4.3.1 that deciding whether they hold is left to the developer without tool assistance; this is a manual validation gap, not a circular derivation. The paper does build on the authors' prior TABS and TABS+ transformation work, especially the DAG/SESE/DE-HSM pipeline and pattern-augmented transaction mechanism, but those are external prior tool/code results used as the regeneration substrate, and the repair claim is not asserted as the conclusion of those citations. The manuscript itself flags missing support: Section 5.3 states the tool is not yet ready for formal evaluation, and Section 4.2.3 describes only an API update without a concrete state-migration mechanism for completed activities. Those are correctness and evidence limitations, not circularity. Overall, no self-referential reduction or fitted-input-as-prediction pattern is present.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The paper does not fit any numeric free parameters. Its central claim rests on the correctness of the authors' prior BPMN-to-DE-HSM-to-smart-contract transformation, on the assumption that separately packaged trade transactions can be replaced independently, and on manual developer judgments about pre- and post-repair conditions. No new physical or theoretical entities are introduced.

assumptions (5)
  • domain assumption The BPMN-to-DE-HSM-to-smart-contract transformation is correct and preserves the business logic.
    Invoked throughout Sections 2.3 and 4.2; inherited from prior work [15,22], not proven here.
  • domain assumption Each trade (sub)transaction encapsulated in a separate smart contract can be replaced independently without affecting other contracts.
    Section 4 states packaging each trade (sub)transaction as a separate smart contract localizes the repair.
  • domain assumption The pre-repair and post-repair conditions (input subset, output superset) guarantee localization of repair effects.
    Section 4.2.2 asserts these conditions ensure preceding and succeeding activities are unaffected, but no proof is given and the decision is manual.
  • domain assumption 2-Phase Commit coordinates atomic commitment of subtransactions within a parent transaction.
    Section 4.3.2 mentions 2PC as the coordination protocol; it is a standard distributed systems protocol but is not formally analyzed here.
  • domain assumption Recovery procedures invoked in reverse order of method invocation restore participant local resources.
    Section 3.1 assumes notifying participants in reverse order lets them release resources correctly; no formal proof is offered.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Automated Mechanism to Support Trade Transactions in Smart Contracts with Upgrade and Repair." pith.science (2026). https://pith.science/paper/RVIM6GOJ

@misc{pith2026250603877,
  author       = {Pith},
  title        = {Pith review of: Automated Mechanism to Support Trade Transactions in Smart Contracts with Upgrade and Repair},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RVIM6GOJ}},
  note         = {Machine review of arXiv:2506.03877}
}
read the original abstract

In our previous research, we addressed the problem of automated transformation of models, represented using the business process model and notation (BPMN) standard, into the methods of a smart contract. The transformation supports BPMN models that contain complex multi-step activities that are supported using our concept of multi-step nested trade transactions, wherein the transactional properties are enforced by a mechanism generated automatically by the transformation process from a BPMN model to a smart contract. In this paper, we present a methodology for repairing a smart contract that cannot be completed due to events that were not anticipated by the developer and thus prevent the completion of the smart contract. The repair process starts with the original BPMN model fragment causing the issue, providing the modeler with the innermost transaction fragment containing the failed activity. The modeler amends the BPMN pattern on the basis of successful completion of previous activities. If repairs exceed the inner transaction's scope, they are addressed using the parent transaction's BPMN model. The amended BPMN model is then transformed into a new smart contract, ensuring consistent data and logic transitions. We previously developed a tool, called TABS+, as a proof of concept (PoC) to transform BPMN models into smart contracts for nested transactions. This paper describes the tool TABS+R, developed by extending the TABS+ tool, to allow the repair of smart contracts.

Figures

Figures reproduced from arXiv: 2506.03877 by the authors.

Figure 1
Figure 1. Block diagram of trade activities represented using a [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. BPMN model of trade activities as nested trade transactions. In addition to the transactions shown in [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Repair steps. Consider a scenario where the doTransport_tx fails due to a washed-out rail line. The BPMN model shows to the developer information that insurance and a transporter had been arranged, but the transport could not occur. If an alternative route is available with the same transporter and insurance, the constraints are satisfied, and the repair remains within the doTransport_tx context. However, if the tra… view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Identified single-entry single-exit (SESE) subgraphs and their selection [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]
Figure 5
Figure 5. Figure 5: Monitoring execution of trade (sub)transa [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]
Figure 7
Figure 7. Figure 7: Repair of the trade transaction transportProduct_tx, parent transaction of the failed doTransport_tx [PITH_FULL_IMAGE:figures/full_fig_p014_7.png]
Figure 8
Figure 8. Figure 8: BPMN diagram after the repair of the trade transaction [PITH_FULL_IMAGE:figures/full_fig_p015_8.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

71 extracted references · 62 canonical work pages

  1. [1]

    The ledger state remains unaffected by the failed (sub)transaction

    work page

  2. [2]

    Recovery procedures for transaction pa rticipants are triggered to release lo cal resources allocated for the failed (sub)transaction. To address real-life scenarios where a trade activity failure, represented by a trade transaction, which requires amendments, Section 4 describes our approach to repairing trade transactions on the basis of the structure o...

    work page

  3. [3]

    We also review transactions in database and blockchain systems, comparing their properties with our concept of trade transactions

    Background This section first provides an overview of BPMN modeling and then discusses modeling with finite state machines (FSMs), hierarchical state machines (HSMs), and multimodal modeling. We also review transactions in database and blockchain systems, comparing their properties with our concept of trade transactions. These concepts are foundational fo...

    work page 1999

  4. [4]

    The mapping ensures that for any DAG vertex or edge, the corresponding BPMN element can be identified, and vice versa

    Transformation of the BPMN model to directed acyclic graph (DAG) representation: The BPMN is pre-processed and is converted into a DAG representation. The mapping ensures that for any DAG vertex or edge, the corresponding BPMN element can be identified, and vice versa

    work page

  5. [5]

    Identification of single-entry single-exit (SESE) subgraphs: The DAG is analyzed to identify SESE subgraphs. A SESE subgraph is such that it has a single-entry vertex, i.e., the only vertex in the subgraph that has an input edge from a vertex outside the subgraph, and a single-exit vertex, i.e., the only vertex in the subgraph that has an output edge lead...

    work page

  6. [6]

    Each node in the DE- HSM model represents either a DE-HSM sub-model or a computation expressed using concurrent FSMs, with some FSM states indicating execution of BPMN tasks

    Transformation to dis crete event-finite state machine (DE-FSM) model: The DAG, with its identified SESE subgraphs, is transformed into a discre te event hierarchical state machine (D E-HSM) model. Each node in the DE- HSM model represents either a DE-HSM sub-model or a computation expressed using concurrent FSMs, with some FSM states indicating execution...

    work page

  7. [7]

    Each BPMN task element is represente d as a separate method within the smart contract

    Transformation into the smart contract methods: The interconnected DE-FSM models are then transformed into a smart contract code. Each BPMN task element is represente d as a separate method within the smart contract. Task- method executions are triggered by specific state transitions in the FSMs, making the system’s collaborative activities, i.e., the bus...

    work page

  8. [8]

    Recovery procedures for nested trade transactions In this section, we discuss automated recovery procedures for nested trade transactions, focusing on restoring the system to the state just before the transaction failure. We will first outlin e the recovery procedures specific to blockchain transactions, followed by a discussion of how these procedures ar...

    work page

Show all 71 references
  1. [9]

    The ledger state remains unaffected by the failed transaction’s execution

  2. [10]

    Since the trade transaction mechanism commits ledger updates only during the successful commit phase, there is no need for ledger recovery

    All participants are notified of the failure so that they can release locally committed resources. Since the trade transaction mechanism commits ledger updates only during the successful commit phase, there is no need for ledger recovery. However, recovery procedures for parti...

  3. [11]

    However, not all failures can be anticipated

    Trade transaction upgrade and repair Developers strive to anticipate potential issues that may arise during the execution of trade transactions and write exception handlers to manage them, trying to ensure successful completion of trade activities. However, not all failures ca...

  4. [12]

    The repair begins with the BPMN patte rn associated with the innermost trade (sub)transaction where the failure occurred

    BPMN model failure information: Information about the failure is gathered, identifying the BPMN pattern that caused it. The repair begins with the BPMN patte rn associated with the innermost trade (sub)transaction where the failure occurred

  5. [13]

    Model amendment: The developer is shown the original failing BPMN pattern ( Pf), including details on the reason for failure, the pattern’s intended function, and the objects and information involved. The goal is to replace Pf with a repaired pattern (Pr) under the following c...

  6. [14]

    backtrack

    Smart contract generation: Upon completing the BPMN model’s repair, the system generates a new smart contract from the updated BPMN model of the pattern. Fig. 3. Repair steps. Consider a scenario where the doTransport_tx fails due to a washed-out rail line. The BPMN model show...

  7. [15]

    Related work The Lorikeet project [12] uses a 2-phase approach to transform BPMN models into smart contracts

    Related work, limitations, and future work 6.1. Related work The Lorikeet project [12] uses a 2-phase approach to transform BPMN models into smart contracts. In the first phase, the BPMN model is analyzed and transformed into smart contract methods, which are then deployed and...

    2021

  8. [16]

    Bodorik, C.G

    P. Bodorik, C.G. Liu, D. Julta, Using FSMs to find patterns for off-chain computing: finding patterns for off-chain computing w ith FSMs, in: Proceedings of the 2021 The 3rd Inte rnational Conference on Blockchain Technology, ACM, 2021, pp. 28–34., https://doi.org/10.1145/3460...

    2021

  9. [17]

    Activities in the trade of goods and services are subject to effects from external ev ents that may cause failure of a trade activity su pported by a smart contract

    Summary and conclusions The trade of goods and services, including distributed finance, contains activities that require specialized customization that is not yet easy to support by traditional development of smart contracts. Activities in the trade of goods and services are s...

  10. [18]

    Conflict of interest The authors declare no conflict of interest

  11. [19]

    Author contributions All three authors participated in research and writing of this paper

  12. [20]

    D. Yang, C. Long, H. Xu, et al., A revi ew on scalability of blockchain, in: Proceed ings of the 2020 2nd International Conferenc e on Blockchain Technology, ACM, 2020, pp. 1–6., https://doi.org/10.1145/3390566.3391665

    2020

  13. [21]

    Taylor, T

    P.J. Taylor, T. Dargahi, A. Dehghantanha, et al., A systematic literature review of blockchain cyber security, Digit. Commun. Netw. 6 (2) (2020) 147– 156, https://doi.org/10.1016/j.dcan.2019.01.005

    2020 doi

  14. [22]

    S.N. Khan, F. Loukil, C. Ghedira-Guegan, et al., Blockchain smart contracts: applications, challenges, and future trends, Peer Peer Netw. Appl. 14 (5) (2021) 2901–2925, https://doi.org/10.1007/s12083-021-01127-0. 19

    2021 doi

  15. [23]

    Vacca, A

    A. Vacca, A. Di Sorbo, C.A. Visaggio, et al., A systematic literature review of blockchain and smart contract development: techniques, tools, and open challenges, J. Syst. Softw. 174 (2021) 110891, https://doi.org/10.1016/j.jss.2020.110891

    2021

  16. [24]

    Belchior, A

    R. Belchior, A. Vasconcelos, S. Guerreiro, et al., A survey on blockchain interoperability: past, present, and future trends, ACM Comput. Surv. 54 (8) (2021) 1–41, https://doi.org/10.1145/3471140

    2021 doi

  17. [25]

    Saito, H

    K. Saito, H. Yamada, What’s so different a bout blockchain?: blockchain is a probabilistic state machin e, in: Proceedings of the 2016 IEEE 36th International Conference on Distributed Computing Systems Workshops (ICDCSW), IEEE, 2016, pp. 168–175, https://doi.org/10.1109/ICDCS...

    2016 doi

  18. [26]

    Garcia-Garcia, N

    J.A. Garcia-Garcia, N. Sánchez-Gómez, D. Lizcano, et al., Us ing blockchain to improve collabor ative business process management : systematic literature review, IEEE Access 8 (2020) 142312–142336, https://doi.org/10.1109/ACCESS.2020.3013911

    2020

  19. [27]

    Lauster, P

    C. Lauster, P. Klinger, N. Schwab, et al ., Literature review linking bl ockchain and business process masnagement, in: Proceedin gs of the 15th International Conference on Wirtschaftsinformatik, WI 2020 Zent. Tracks, 2020, pp. 1802–1817. https://doi.org/10.30844/wi_2020_r10-klinger

    2020 doi

  20. [28]

    Levasseur, M

    O. Levasseur, M. Iqbal, R. Matulevičius, Survey of model-driven engineering techniques for blockchain-based applications, in: Proceedings of the 14th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modelling, CEUR, 2021, pp. 11–20. https://ceur-ws.org/Vol-3045/paper02.pdf

    2021

  21. [29]

    Tolmach, Y

    P. Tolmach, Y. Li, S.W. Lin, et al., A survey of smart contr act formal specification and verification, ACM Comput. Surv. 54 (7) (2021) 1–38, https://doi.org/10.1145/3464421

    2021 doi

  22. [30]

    López-Pintado, L

    O. López-Pintado, L. García-Bañuelos, M. Dumas, et al., Cate rpillar: a business process executi on engine on the Ethereum blockc hain, Softw. Pract. Exp. 49 (2018) 1162–1193, https://doi.org/10.1002/spe.2702

    2018 doi

  23. [31]

    A. Tran, Q. Lu, I. Weber, Lorikeet: a model-driven engineeri ng tool for blockchain-based business process execution and asset m anagement, in: Proceedings of International Conference on Business Process Management, CEUR, 2018, pp. 1–5. https://api.semanticscholar.org/CorpusID...

    2018

  24. [32]

    Mendling, I

    J. Mendling, I. Weber, W. Van Der Aalst, et al., Blockchains for business process management - challenges and opportunities, AC M Trans. Manage. Inf. Syst. 9 (1) (2018) 1–16, https://doi.org/10.1145/3183367

    2018 doi

  25. [33]

    Loukil, K

    F. Loukil, K. Boukadi, M. Abed, et al., Decentralized collaborative busin ess process execution using blockchain, World Wide Web , 24 (5) (2021) 1645–1663, https://doi.org/10.1007/s11280-021-00901-7

    2021 doi

  26. [34]

    Bodorik, C.G

    P. Bodorik, C.G. Liu, D. Jutla, TABS: Transforming automatically BPMN models into blockchain smart contracts, Blockchain Res. Appl. 4 (1) (2023) 100115, https://doi.org/10.1016/j.bcra.2022.100115

    2023

  27. [35]

    Di Ciccio, A

    C. Di Ciccio, A. Cecconi, M. Dumas, et al., Blockchain support for collaborative busin ess processes, Inf. Spektrum 42 (3) (2019 ) 182–190, https://doi.org/10.1007/s00287-019-01178-x

    2019 doi

  28. [36]

    C. Liu, P. Bodorik, D. Jutla, A tool for moving blockchain computations off-chain, in : Proceedings of the 3rd ACM International Symposium on Blockchain and Secure Critical Infrastructure, ACM, 2021, pp. 103–109., https://doi.org/10.1145/3457337.3457848

    2021

  29. [37]

    C. Liu, P. Bodorik, D. Jutla, From BPMN to smart contracts on blockchains: Transforming BPMN to DE-HSM multi-modal model, in: Proceedings of the 2021 International Conference on Engineering and Emerging Technologies (ICEET), IEEE, 2021, pp. 1–7, https://doi.org/10.1109/ICEET53...

    2021

  30. [38]

    C.G. Liu, P. Bodorik, D. Jutla, Long-term blockchain transactions spanning multiplicity of smart contract methods, in: J. Chen, B. Wen, T. Chen (Eds.), Blockchain and Trustworthy Systems, Springer, Singapore, 2024, pp. 142–155. https://doi.org/10.1007/978-981-99-8104-5_11

    2024 doi

  31. [39]

    C.G. Liu, P. Bodorik, D. Jutla, Automating smart contract generation on blockchains using multi-modal modeling, J. Adv. Inf. Technol. 13 (3) (2022): 213–223, https://doi.org/10.12720/jait.13.3.213-223

    2022 doi

  32. [40]

    C.G. Liu, P. Bodorik, D. Jutla, Supporting long-term transactions in smart contr acts, in: Proceedings of the 2022 Fourth Intern ational Conference on Blockchain Computing and Applications (BCCA), IEEE, 2022, pp. 11–19, https://doi.org/10.1109/BCCA55292.2022.9922193

    2022

  33. [41]

    EVMPatch upgrades faulty Ethereum smart cont racts using a bytecode rewriting technique to patch common bugs, such as integer over or underflows and access control errors

    described a framework, EVMPatch, which uses a bytecode rewriting technique to automatically rewrite common off-the- shelf contracts to upgradable contracts. EVMPatch upgrades faulty Ethereum smart cont racts using a bytecode rewriting technique to patch common bugs, such as in...

  34. [42]

    C. Liu, P. Bodorik, D. Jutla, Transforming automatically BPMN mode ls to smart contracts with nested trade transactions (TABS+), Distrib. Ledger Technol. Res. Pract. 3 (3) (2024) 1–37, https://doi.org/10.1145/3654802

    2024 doi

  35. [43]

    https://en.wikipedia.org/w/index.php?title=Object%E2%80%93relational_impedance_mismatch&oldid=1134321907

    Object–relational impedance mismatch. https://en.wikipedia.org/w/index.php?title=Object%E2%80%93relational_impedance_mismatch&oldid=1134321907. (Accessed: 5 Mar 2023)

    2023

  36. [44]

    https://flowable.com/open-source/docs/

    BPMN 2.0 Introduction—Flowable Open-Sour ce Documentation. https://flowable.com/open-source/docs/. (Accessed: 15 Feb 2024)

    2024

  37. [45]

    https://camunda.com/bpmn/reference/

    BPMN 2.0 Symbols—A complete guide with examples. https://camunda.com/bpmn/reference/. (Accessed: 15 Feb 2024)

    2024

  38. [46]

    https://www.omg.org/spec/BPMN/2.0.2/PDF

    Business Process Model and Notation (BPMN), Version 2.0.2. https://www.omg.org/spec/BPMN/2.0.2/PDF. (Accessed: 15 Feb 2024)

    2024

  39. [47]

    https://www.omg.org/spec/bpmn/2.0/About-BPMN

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

    2010

  40. [48]

    Process Orchestration for end-to-end automation

    Camunda. Process Orchestration for end-to-end automation. https://camunda.com. (Accessed: 15 Feb 2024)

    2024

  41. [49]

    Dikmans, Transforming BPMN into BPEL: Why and Ho w

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

    2024

  42. [50]

    Yannakakis, Hierarchical state machines, in: J

    M. Yannakakis, Hierarchical state machines, in: J. van Leeuwen, O.Watanabe, M. Hagiya, et al. (Eds.), Theoretical Computer Science: Exploring New Frontiers of Theoretical Informatics. Springer, Cham, 2000, pp. 315–330. https://doi.org/10.1007/3-540-44929-9_24

    doi

  43. [51]

    Girault, B

    A. Girault, B. Lee, E.A. Lee, Hierarchical finite state machin es with multiple concurrency mode ls, IEEE Trans. Comput. Aided De s. Integr. Circuits Syst. 18 (6) (1999) 742–760, https://doi.org/10.1109/43.766725

    1999 doi

  44. [52]

    Hoare, Communicating sequential processes, Commun

    C.A.R. Hoare, Communicating sequential processes, Commun. ACM 21 (8) (1978) 666–677, https://doi.org/10.1145/359576.359585

    1978

  45. [53]

    Cassandras, Discrete event systems: Modeling and performance analysis, 1st ed., CRC, Boca Raton, FL, 1993

    C. Cassandras, Discrete event systems: Modeling and performance analysis, 1st ed., CRC, Boca Raton, FL, 1993

    1993

  46. [54]

    López-Pintado, M

    O. López-Pintado, M. Dumas, L. García-Bañuelos, et al., Cont rolled flexibility in blockchain-b ased collaborative business proce sses, Inf. Syst. 104 (2022) 101622, https://doi.org/10.1016/j.is.2020.101622

    2022

  47. [55]

    Bagozi, D

    A. Bagozi, D. Bianchini, V. De Antonellis, et al., A three-layered approach for designing smart contracts in collaborative processes, In: H. Panetto, C. Debruyne, M. Hepp, (Eds.), On the Move to Meaningful Internet Systems: OTM 2019 Conferences, Springer, Cham, 2019, pp. 440–4...

    2019 doi

  48. [56]

    Mavridou, A

    A. Mavridou, A. Laszka, Designing secure Ethereum smart contracts: a finite state machine based approach, in: S. Meiklejohn, K. Sako (Eds.), Financial Cryptography and Data Security, Springer, Berlin, Heidelberg, 2018, pp. 523–540. https://doi.org/10.1007/978-3-662-58387-6_28

    2018 doi

  49. [57]

    Mavridou, A

    A. Mavridou, A. Laszka, Tool demonstration: FSolidM for designing secure Ethereum smart contracts, In: L. Bauer, R. Küsters (Ed s.), Principles of Security and Trust, Springer, Cham, 2018, pp. 270–277. https://doi.org/10.1007/978-3-319-89722-6_11

    2018 doi

  50. [58]

    Mavridou, A

    A. Mavridou, A. Laszka, E. Stachtiari, et al., VeriSolid: correct -by-design smart contracts for Ethereum, in: I. Goldberg, T. M oore (Eds.), Financial Cryptography and Data Security. Springer, Cham, 2019, pp. 446–465. https://doi.org/10.1007/978-3-030-32101-7_27

    2019 doi

  51. [59]

    J. Jin, L. Yan, Y. Zou, et al., Research on smart contract verification and generation method based on BPMN, Mathematics 12 (14 ) (2024) 2158, https://doi.org/10.3390/math12142158

    2024 doi

  52. [60]

    Rodler, W

    M. Rodler, W. Li, G.O. Karame, L. Davi, EVMPatch: timely and automated patching of Ethereum smart contracts, in: Proceedings of the 30th USENIX Security Symposium (USENIX Security 21), USENIX, 2021, pp. 1289–1306. https://www.usenix.org/conference/usenixsecurity21/presentation/rodler

    2021

  53. [61]

    Z. Li, Y. Zhou, S. Guo, et al., SolSaviour: a defending framework for deployed defective smart contracts, in: Proceedings of the 37th Annual Computer Security Applications Conference, ACM, 2021, pp. 748–760, https://doi.org/10.1145/3485832.3488015

    2021

  54. [62]

    H. Jin, Z. Wang, M. Wen, et al., Aroc: an automatic repair framework for on-chain smar t contracts, IEEE Trans. Softw. Eng. 48 ( 11) (2022) 4611– 4629, https://doi.org/10.1109/TSE.2021.3123170

    2022

  55. [63]

    Corradini, A

    F. Corradini, A. Marcelletti, A. Morichetta, et al., Flexible execution of multi-party busine ss processes on blockchain, in: Pr oceedings of the 5th International Workshop on Emerging Trends in Software Engineering for Blockchain, ACM, 2023, pp. 25–32, https://doi.org/10.1145...

    2023

  56. [64]

    Corradini, A

    F. Corradini, A. Marcelletti, A. Morichetta, et al., Engineeri ng trustable choreogra phy-based systems using blockchain, in: Pro ceedings of the 35th Annual ACM Symposium on Applied Computing, ACM, 2020, pp. 1470–1479, https://doi.org/10.1145/3341105.3373988

    2020

  57. [65]

    Falazi, M

    G. Falazi, M. Hahn, U. Breitenbücher, et al., Modeling and execution of blockchain-aware business processes, SICS Softw. Intensive Cyber Phys. Syst. 34 (2) (2019) 105–116, https://doi.org/10.1007/s00450-019-00399-5

    2019 doi

  58. [66]

    Falazi, M

    G. Falazi, M. Hahn, U. Breitenbucher, et al., Process-based composition of permissioned and permissionless blockchain smart contracts, in: Proceedings of the 2019 IEEE 23rd International Enterprise Distributed Object Computing Conference (EDOC), IEEE, 2019, pp. 77–87., https:/...

    2019

  59. [67]

    Klinger, L

    P. Klinger, L. Nguyen, F. B odendorf, Upgradeability concept for collaborative blockchain-based business process execution framework, In: Z. Chen, L. Cui, B. Palanisamy, et al. (Eds.), Blockchain – ICBC 2020. Springer, Cham, 2020, pp. 127–141. https://doi.org/10.1007/978-3-030...

    2020 doi

  60. [68]

    J. Poon, Plasma : Scalable Autonomous Smart Contracts, https://www.semanticscholar.org/paper/Plasma-%3A-Scalable-Autonomous-Smart- Contracts-Poon/cbc775e301d62740bcb3b8ec361721b3edd7c879, 2017. (Accessed: 1 Jan 2023)

    2017

  61. [69]

    Meisami, W.E

    S. Meisami, W.E. Bodell III, A comprehensive survey of upgradeable smart contract patterns, arXiv, 2023, preprint. arXiv:2304.03405

    2023 arXiv

  62. [70]

    Girish, S

    N.M. Girish, S. Kaganurmath, Upgradability of smart contracts: a review, Intern. Res. J. Eng. Technol. 9 (7) (2022) 2603–2606

    2022

  63. [71]

    Palladino, The state of smart contract upgrades

    S. Palladino, The state of smart contract upgrades. https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades, 2020. (Accessed: 6 Oct 2020)

    2020

Pith tools

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