Source-linked AI summary
Runtime Verification for Business Processes Utilizing the Bitcoin Blockchain
Christoph Prybila, Stefan Schulte, Christoph Hochreiner, Ingo Weber
TL;DR
Decentralized choreographies need runtime monitoring and verification despite participants lacking centralized control and complete runtime knowledge. This paper develops and prototypes a Bitcoin-based verification approach, finding that it supports choreography monitoring while preserving participant independence and anonymity, with performance shaped by confirmation delays and a security trade-off in greedy execution.
Problem
Decentralized choreographies require trusted runtime documentation and verification of process state for contract-related purposes, but participants lack centralized control and complete runtime knowledge.
Method
The paper develops a blockchain-based runtime verification approach for choreographies, implements it as a fully functional prototype using Bitcoin, and evaluates it qualitatively and through performance analysis.
Results
The prototype supports runtime verification with Bitcoin; greedy execution reduces overall duration by about 56× versus non-greedy execution, while confirmation waiting dominates performance.
Takeaways & Limitations
The approach is primarily suitable for long-running processes, while greedy execution can significantly reduce overhead at the cost of reduced security.
Takeaways & Limitations
Bitcoin transaction confirmation times are unpredictable, and greedy execution reduces security despite lowering runtime overhead.
Abstract
from arXiv · showhide
The usage of process choreographies and decentralized Business Process Management Systems has been named as an alternative to centralized business process orchestration. In choreographies, control over a process instance is shared between independent parties, and no party has full control or knowledge during process runtime. Nevertheless, it is necessary to monitor and verify process instances during runtime for purposes of documentation, accounting, or compensation. To achieve business process runtime verification, this work explores the suitability of the Bitcoin blockchain to create a novel solution for choreographies. The resulting approach is realized in a fully-functional software prototype. This software solution is evaluated in a qualitative comparison. Findings show that our blockchain-based approach enables a seamless execution monitoring and verification of choreographies, while at the same time preserving anonymity and independence of the process participants. Furthermore, the prototype is evaluated in a performance analysis.
1. Introduction
Choreographies distribute process control among independent participants, creating a need for trusted runtime verification and documentation. This paper investigates Bitcoin blockchain technology as a basis for verification and implements and evaluates a prototype.
- Motivation: Choreographies distribute process control among independent parties, especially in inter-organizational settings where centralized control is unavailable.They can also mitigate bottlenecks associated with centralized business process management systems.
- Motivation: Process contracts define participants’ obligations, rights, and execution rules, while choreography records support contract verification, accounting, and compensation.The documentation must be indisputable and accepted by all participants.
- Motivation: A choreography-oriented BPMS therefore needs end-to-end runtime verification of whether executions satisfy contractual functional and non-functional objectives.The paper describes verification as evaluating compliance with requirements or imposed conditions.
- Motivation: Independent choreography participants face verification challenges similar to cryptocurrency users, because process tasks must be permanently and trustworthily documented.The paper identifies blockchain use as a promising basis for decentralized and indisputable runtime verification.
- Contributions: The paper examines blockchain properties, develops a Bitcoin-based runtime verification approach, and implements a fully functional prototype for running process instances.The work also evaluates the approach through qualitative comparison and performance analysis.
2. Background
The background frames choreographies as decentralized peer-to-peer process execution and explains why blockchain properties are relevant to trusted, anonymous, and immutable verification. It also introduces Bitcoin’s transaction and blockchain foundations.
- Business Process Management: Choreographies share process control among independent participants, reducing centralized bottlenecks while creating requirements for traceability, contract verification, and trustworthy participation records.These records support accounting, compensation, and enforcement across organizational boundaries.
- Business Process Management: Existing dedicated runtime verification for choreographies is described as missing, motivating blockchain-based solutions.The stated requirements include tracing execution paths and providing a legal basis for contract enforcement.
- Blockchain: Bitcoin uses a decentralized ledger maintained by independent miners rather than a central institution, supporting anonymous digital payments and distributed verification.Bitcoin addresses provide abstraction that contributes to anonymity.
- Blockchain: A blockchain forms an unchangeable history by linking blocks of transactions to preceding transaction history.Bitcoin transactions are public, allowing historical transaction data to be fetched and examined.
- Blockchain: Bitcoin is classified as a first-generation blockchain with limited adaptability, whereas Ethereum provides an open programming environment and smart contracts.The paper selects Bitcoin because it is presented as more mature and robust than Ethereum for the target B2B context.
- Bitcoin Transactions: Bitcoin transactions consist of inputs and outputs secured by scripts, with signatures controlling access to outputs and enabling transaction authorization.Transactions can contain multiple inputs and outputs, allowing funds to be combined, split, and distributed.
3. Related Work
Related work covers contract-based monitoring, message control, token passing, and blockchain-based verification. The paper positions Bitcoin as a decentralized trust basis while noting limitations in prior approaches and Bitcoin itself.
- Monitoring Approaches: Prior choreography-monitoring work defines monitoring information through contracts, BPMN extensions, BPEL4Chor agreements, or related modeling mechanisms.These approaches specify what information participants provide and how it is shared or accessed.
- Runtime Verification: Message-controlling approaches use enterprise service buses or proxies to intercept communications and log information centrally.They require tight software integration, which can reduce choreography flexibility and increase rigidity.
- Runtime Verification: Token-passing approaches use cryptographic tokens as proofs of execution paths and participation, but tokens may be lost or require shared storage.Shared storage becomes a centralized source of control and trust.
- Blockchain-Based Verification: The paper uses Bitcoin as a shared trust basis outside single-organization control, allowing messages and token information to be stored in blockchain transactions.This is presented as a way to address challenges in earlier verification approaches.
- Blockchain-Based Verification: An Ethereum smart-contract approach can enforce authorized process-state changes and execution sequences, but requires participants’ public keys and roles during contract creation.The cited downside is reduced flexibility when all participants must be known in advance.
- Blockchain Selection: Ethereum is described as unstable for the target B2B setting, while Bitcoin is selected based on greater maturity and prior network analysis.Bitcoin nevertheless has limited scalability, and increasing throughput could reduce synchronization and security.
4. Runtime Verification for Choreographies
The paper proposes Bitcoin blockchain technology as the basis for runtime verification in decentralized choreographies. It presents the conceptual approach, its realization with Bitcoin transactions, and an implementation framework.
- Approach: The proposed approach uses the Bitcoin blockchain to provide a decentralized and undeniable trust basis for verifying choreography execution.The section structure covers the conceptual solution, Bitcoin transaction realization, and an encapsulating framework.
4.1. Conceptual Solution
The conceptual solution uses a Bitcoin output as a transferable control token whose transaction chain records choreography execution and supports runtime monitoring, verification, and accountability. Handover metadata, signatures, hashes, and blockchain publication document each transition while preserving participant anonymity.
- Design choice: Bitcoin’s transaction techniques limit adaptability but enable the solution to use an existing mature blockchain.The approach deliberately avoids smart contracts and addresses Bitcoin’s limited support for diverse use cases.
- Control token: A free Bitcoin output serves as the process instance’s control token and stores execution state in the blockchain.Token possession assigns responsibility for executing a choreography activity, and the token can be split to enable parallelism.
- Handover documentation: Each enriched transaction records process state, while sender and receiver signatures document approval of the handover.The metadata includes process and task identifiers, timestamps, and a process-data hash; process data itself is transferred off-chain.
- Verification and accountability: The transaction chain provides evidence of process progress that can support penalties, rewards, and deviation detection.Participants and the process owner can detect deviations from the choreography model and react to them.
- Privacy and identity: Handover addresses are generated for each transfer and remain anonymous to protect choreography participants’ privacy.RSA-based signatures and certificates are additionally assumed for mutually proving participant identities outside the Bitcoin addresses.
- Handover procedure: The handover sequence exchanges terms and encrypted data, creates and co-signs a transaction template, and publishes it to the blockchain for monitoring.The process owner observes new handover documentation and can request more detailed progress information from participants.
4.2. Realizing the Solution with Bitcoin Transactions
The implementation realizes process verification with Bitcoin’s standard data-output and P2SH transaction types. These structures encode process metadata, transfer token control, and validate the process-data hash while avoiding non-standard transactions.
- Transaction constraints: Non-standard Bitcoin transactions are unsuitable because miners generally discard them and inclusion requires finding a willing miner that wins block creation.The implementation therefore restricts itself to standard transaction structures.
- Transaction types: Data output and P2SH are the two standard transaction types used because they permit arbitrary data while remaining standard.A data output is a limited data field, created with zero Bitcoins and intended only to contain data.
- Data layout: The data output stores the process id, task id, timestamp, and receiver signature, while an adapted P2SH output stores the process-data hash and transfers the token.The process-data hash cannot fit in the data output element and therefore requires P2SH storage.
- Handover validation: A P2SH redeem script binds the receiver’s public-key hash to the transferred process-data hash, allowing the receiver to verify token and data correctness.The receiver reconstructs the redeem script and compares it with the hash placed in the P2SH output.
- Transaction validation: The handover transaction template contains negotiated process data and remains incomplete until receiver and sender signatures are added.The receiver can validate the previous transaction’s redeem script and included data hash before signing.
4.3. Runtime Verification Framework and Implementation
The Java framework implements the Bitcoin-based verification approach with an SPV client, REST-based data collection, and greedy publishing. Greedy publishing addresses Bitcoin’s variable confirmation delays by allowing valid chains of unconfirmed transactions to continue execution.
- Framework: The Java framework abstracts implementation details so it can integrate with arbitrary choreography-oriented BPMSs.It uses an SPV Bitcoin client, a remote REST API, and a greedy publishing mode.
- Performance constraint: Bitcoin’s median ten-minute block creation time and highly variable block intervals make transaction confirmation a major runtime-verification challenge.Waiting for every confirmation is suitable for long-running processes but can bottleneck processes with short tasks between handovers.
- Greedy publishing: Greedy publishing appends transactions to unconfirmed transactions, allowing participants to validate and continue a process before all transactions enter the blockchain.Bitcoin miners accept transactions referencing unconfirmed inputs, enabling chains of unconfirmed transactions.
- Performance effect: Greedy publishing avoids delaying fast-paced processes and can allow multiple chained transactions to be confirmed in one block.Each participant retains the complete execution chain and can prove handovers confirmed by both partners.
- Risks: A lost intermediate transaction invalidates the remaining pending chain, and conflicting alternative transactions can disrupt continuation.The approach relies on transactions remaining available in miners’ pending buffers and faces malicious-participant risks.
5. Evaluation
The evaluation compares the blockchain-based runtime verification framework with existing approaches and verification-less baselines, measuring execution performance, error detection, and transaction costs. Results show that confirmation waiting dominates runtime, while greedy publishing substantially reduces duration but trades away security.
- Qualitative comparison: The approach shares all process-related data with participants and cannot enforce task order during execution, although the process owner can identify an incorrect path afterward.These limitations distinguish the approach from solutions that restrict data sharing or encode process models directly in transaction logic.
- Evaluation setup: 122 process instances produced 450 Bitcoin transactions over 50.551 hours, with completion requiring every transaction to reach confirmation depth 1.The evaluation used four process models, each assigning tasks to distinct participants.
- Non-greedy results: 99.42% of non-greedy runtime-verification step duration came from transaction confirmation, compared with 0.05% for framework logic and 0.53% for REST API requests.The high confirmation overhead produces substantial and highly variable execution durations.
- Non-greedy results: 7.74 minutes was the median non-greedy transaction confirmation time, although one transaction required 172.78 minutes to confirm.The non-greedy mode is therefore better suited to processes with long-running tasks, such as logistics and supply-chain processes.
- Greedy results: 1,520.68 seconds was the mean greedy execution duration, with 91.38% spent waiting for transaction confirmations and 8.62% on broadcasting, REST requests, and framework logic.Greedy transactions had an 8.76-minute median confirmation time and a 309.18-minute maximum.
- Evaluation objectives: The approach supports detecting incorrect choreography executions, including attempts to hand over a process instance with instructions for a task that does not fit the current execution stage.The evaluation deliberately introduced corrupted handovers at random participant transitions.
- Discussion: The greedy-mode reduction makes blockchain verification applicable to processes with very short task sequences, while non-greedy operation fits long-running business processes.The greedy and non-greedy medians cannot be causally distinguished because the experimental data cannot determine whether chaining unconfirmed transactions caused their deviation.
6. Conclusion
The paper presents Bitcoin blockchain technology for runtime verification of decentralized choreography-based process instances. The approach increases trust and flexibility, but excludes shared-data confidentiality and incurs overhead that limits its suitability to long-running processes.
- The approach uses blockchain technology to document process state updates and establish a decentralized trust basis for choreography-based runtime verification.
- The qualitative comparison reports increased trust and flexibility through a decentralized verification trust basis.
- The approach does not take into account confidentiality of shared data.
- Measured runtime overhead and unpredictable Bitcoin transaction confirmation times make the approach primarily suitable for long-running processes.
- Future work includes fault management using Multi-Signature redeem scripts and support for additional process patterns such as loops.