PIECHAIN Demo: Exploring a Practical Blockchain Interoperability Framework

Authors: (1) Daniel Reijsbergen, Nanyang Technological University, Singapore, Singapore; (2) Aung Maw, Singapore University of Technology and Design, Singapore, Singapore; (3) Jingchi Zhang, Nanyang Technological University, Singapore, Singapore; (4) Tien Tuan Anh Dinh, Deakin University, Melbourne, Australia; (5) Anwitaman Datta, Nanyang Technological University, Singapore, Singapore. Content Overview Abstract & Introduction Overview of PIEChain Implementation of PIEChain Demontration Plan Extensions References Abstract A plethora of different blockchain platforms have emerged in recent years, but many of them operate in silos. As such, there is a need for reliable cross-chain communication to enable blockchain interoperability. Blockchain interoperability is challenging because transactions can typically not be reverted – as such, if one transaction is committed then the protocol must ensure that all related transactions are committed as well. Existing interoperability approaches, e.g., Cosmos and Polkadot, are limited in the sense that they only support interoperability between their own subchains, or require intrusive changes to existing blockchains. To overcome this limitation, we propose PIECHAIN, a general, Kafka-based cross-chain communication framework. We utilize PIECHAIN for a practical case study: a cross-chain auction in which users who hold tokens on multiple chains bid for a ticket sold on another chain. PIECHAIN is the first publicly available, practical implementation of a general framework for cross-chain communication. I. INTRODUCTION A blockchain is a replicated, tamper-evident database designed for hostile environments. It consists of a number of nodes, of which some may be malicious, which maintain an append-only ledger. The ledger stores transactions that modify some global states. In the canonical example, i.e., cryptocurrencies [7], the global states are user accounts and native (fungible) tokens, and the ledger contains transactions transferring tokens from one account to another. In another emerging application, the blockchains store non-fungible tokens (NFTs) uniquely representing assets, e.g., digital art works or concert tickets. Many blockchains also support smart contracts letting users define their own states and codes that modify the states. Smart contracts are stored in the ledger and are replicated and kept consistent by all the blockchain nodes. In recent years, many independent blockchain platforms have emerged, resulting in an ecosystem with a long tail. On the one hand, there are a small number of hugely popular, general-purpose blockchain platforms such as Ethereum and Hyperledger. On the other hand, there are thousands of smaller blockchains designed for specific applications, most of which are only in early stages of development. This includes more than 10 000 cryptocurrencies [3] as of early 2023, alongside blockchains for healthcare, identity management, and IoT. In general, these blockchains do not interoperate, i.e., they exist in silos. As such, blockchain interoperability, i.e., the ability for users to exchange information or assets on different blockchains, is a subject that is drawing increasing interest from the research community [6], [10], [4], [1], [11]. One of the main challenges in designing a secure blockchain interoperability framework is to guarantee atomicity, i.e., that either all steps of an agreed set of transactions terminate successfully, or none do. This is more complicated in blockchains than in traditional databases because blockchain transactions are (in principle) irreversible. For example, if a payment for an NFT on Chain A has already been made on Chain B, then atomicity requires that the transaction on Chain A must go ahead because the transaction on Chain B cannot be reverted. One common approach to guarantee atomicity is to escrow all of the tokens that are involved in the deal in smart contracts, and release them only through a commit message that is signed by all parties [6]. Another important challenge in blockchain interoperability is to guarantee liveness, so that the tokens that are escrowed cannot be frozen forever. To ensure liveness, it must be possible for nodes to send an abort message that allows all parties to withdraw their assets from escrow. To guarantee both atomicity and liveness, an interoperability framework must be able to tolerate adversarial nodes who send a commit message to one blockchain and an abort message to another. It is known for asynchronous networks (i.e., where there is no bound on message delays) that this is impossible to achieve without a trusted third party (TTP) [10]. There are two main approaches to overcome this challenge [6]. The first approach is to combine a synchrony assumption with a cooldown period for aborts – i.e., assuming that a commit vote, once generated, can be appended to all affected blockchains before the end of any cooldown period for aborts. This approach is taken in, e.g., hashed timelocked contracts [5]. The second approach is to replace the TTP with another blockchain to ensure that either a valid commit or abort message can be created, but not both [6], [9]. Although approaches of both types have been proposed in the scientific literature, they either do not have a publicly available implementation [5], [6], [9], or are limited in their application scope, e.g., creating backed assets on another blockchain [11] or token swaps [8]. In a separate development, several blockchain platforms have emerged that enable interoperability by default, e.g., Cosmos and Polkadot. However, these platforms only support interoperability between their own subchains, or require intrusive changes to existing blockchains. This motivates the need for a general and practical interoperability framework that can be interfaced to existing blockchain platforms without modifying them. Our goal is to provide such a framework. Contributions & Novelty: We present PIECHAIN to achieve this goal. As synchrony is difficult to assume in practice, PIECHAIN uses cross-chain services to replace the TTP. The cross-chain services communicate using an event log that uses Apache’s Kafka protocol for efficiency. To demonstrate the practical relevance of PIECHAIN, we have implemented a cross-chain service for a realistic case study: a cross-chain auction. We have interfaced PIECHAIN with some of the most popular blockchain platforms that support smart contracts: Ethereum, Hyperledger Fabric, and Quorum. Finally, we have developed a GUI for our case study. The auction case study is one of three case studies (two auctions and a flash loan [6]) whose code can be found in the PIEChain code repository on GitHub. II. OVERVIEW OF PIECHAIN A. Entities The main entities in PIECHAIN are as follows (see also Figure 1): Blockchains, which store assets (e.g., tokens, keys) that are held by users. A user may hold assets on multiple blockchains. Each blockchain has its own protocol to determine who has read and write access – blockchains are typically either permissioned, i.e., a fixed set of nodes has read and write access, or permissionless, i.e., everyone has read access and can create transactions, and nodes with sufficient power (e.g., processing speed) can add transactions to the blockchain. Cross-chain services (CC-SVCs), which allow users to exchange assets on different blockchains. Each CC-SVC consists of a server that interacts with user clients to facilitate crosschain communication. In practice, the CC-SVC charges the users for participation, and it can interact with any number of blockchains. In the following, each CC-SVC corresponds to a set of events involved in an atomic exchange of assets that are sent by a server to the Kafka ledger. In practice, a single server may operate many CC-SVCs. The Kafka network, which serves as an append-only log of events generated by the CC-SVCs. Events correspond to transactions made on underlying blockchains. The Kafka network is operated by a fixed set of nodes who charge CCSVCs for uploading events. In PIECHAIN, we assume that the CC-SVCs are semitrusted, and that they are motivated to behave honestly by having a reputation to uphold, akin to commercial outsourced service providers. The Kafka network operators are untrusted but have no incentive to misbehave as they do not interact with the underlying blockchains. This allows us to run a protocol (Kafka) that prioritizes efficiency over security. An alternative design is to make the CC-SVCs untrusted and the Kafka network trusted. In this case, each Kafka node runs a (light) client for each of the underlying blockchains to validate the inclusion of transactions on those chains. In this case, the event log would have to use a more secure protocol such as PBFT [2]. We leave such a design as future work. B. Process Flow Given the entities of Section II-A, the process flow in PIECHAIN has the same structure as cross-chain deals as proposed by Herlihy et al. [6]. Cross-chain deals are agreements by multiple users to exchange assets on different blockchains, and consist of five phases (see also Figure 2): Clearing phase: the CC-SVC creates the smart contracts on the different blockchains that are used to escrow and transfer the assets involved in the deal. Escrow phase: the users escrow their outgoing assets by transferring them to the smart contracts. Transfer phase: the assets are tentatively exchanged, i.e., the execution logic of the smart contracts is specified. Validation phase: each user checks whether the result of the execution logic would be to their satisfaction. Commit phase: the deal is concluded through commitment if all parties are satisfied, or through abortion otherwise. Commitment means that the execution logic in the smart contracts is executed and that the assets are exchanged as specified by the deal. Abortion means that the assets in each smart contract are returned to their original owners. To commit, the users interactively construct a commit vote, which is sent by the CC-SVC to the Kafka ledger. To abort, a single user sends an abort message to the CC-SVC. For each CC-SVC, either a commit or abort message can be added to the Kafka ledger, but not both. An inclusion proof of a commit vote on the Kafka ledger is accepted by all the smart contracts on the different blockchains – this guarantees that once a commit vote is constructed, either all asset transfers can be executed or none. III. IMPLEMENTATION OF PIECHAIN To illustrate the practical applicability of PIECHAIN, we have interfaced it to several commonly-used blockchain platforms and used it to implement an application from the scientific literature [6]: a cross-chain auction for a digital asset. The blockchain support extends to other case studies, as we discuss in Section V. A. Blockchain Support To interface an underlying blockchain with PIECHAIN, the CC-SVCs must be able to validate transactions on those chains. Our implementation supports the following blockchain platforms: Ethereum (both the Proof-of-Work and Proof-ofAuthority versions of private Ethereum), Hyperledger Fabric, and Quorum. The latter two support permissioned blockchains, whereas Ethereum has a permissionless main chain but also supports private chains with the same functionality. B. Auction In our case study, an auctioneer sells an asset on one blockchain and receives payment in the form of assets on another blockchain. As in [6], we use the example of a ticket seller. The ticket is an NFT on a dedicated blockchain, whereas the other blockchain supports more commonly-used fungible tokens (e.g., Ether). The former blockchain is called the ticket blockchain and the latter the coin blockchain. This is easily generalized to settings with more than one coin blockchain. In the following, we consider a first-price auction (i.e., the bidder with the highest bid pays its bid and receives the asset). The five phases of the protocol are then as follows: The auctioneer enlists a CC-SVC which creates smart contracts on the ticket blockchain and the coin blockchains. The auctioneer transfers its asset (the ticket’s NFT) to the ticket contract, and the bidders transfer their bids to the contract on their coin blockchain. The execution logic is determined: the auctioneer updates each of the ticket and coin contracts by specifying which party receives the ticket and which bid is transferred to the auctioneer. (Note that this logic cannot be specified in the ticket contract a priori because the contract on the ticket chain cannot read data from the coin blockchains.) Each user (i.e., the auctioneer and the bidders) determines whether the outcome of the transfer protocol is agreeable to them, i.e., whether the ticket is indeed transferred to the correct party. All users construct a commit vote – once this has been constructed, it is sent to each contract to enact the transfers specified in the transfer phase. In PIECHAIN, the auction requires two (logical) types of CC-SVC: the relayer and the signer. The relayer listens for events (bids) on the coin chains and relays them to the ticket blockchain. The signer assists in creating the commit vote. IV. DEMONSTRATION PLAN For our demonstration, we have developed a graphical user interface (GUI) using the React framework to illustrate a cross-chain auction. The GUI consists of three main pages: a dashboard page that displays a list of known auctions as depicted in Figure 3, a detailed view for individual auctions as depicted in Figure 5, and a page for the creation of new auctions (not displayed). The view is the same for an auctioneer as for bidders. On the dashboard view, prospective auctioneers can click the “Create New Auction” button to initiate an auction – the auctioneer selects a CC-SVC, the asset to be auctioned, which other blockchains to accept bids from, the exchange rate for tokens between different blockchains (which must be fixed in advance), and the time at which the auction is concluded. Next, the relay CC-SVC creates the relevant contracts, and sends the address of the contract on the asset chain to the auctioneer. The auctioneer can then add the auction on its dashboard by adding the contract address and clicking the “Add Existing Auction” button. Meanwhile, it advertises the contract address to potential bidders. When the bidders become aware of the asset contract address, they can also add it to their dashboards. After the bidder has added the auction, she can view it in more detail by pressing the “View” button in the auction’s panel, which takes her to the detailed view page. On this page, the bidder is able to view crucial information about the auction such as its creation and conclusion times, and a list of bids. The highest bid is marked with an asterisk. If the auction is still ongoing, then the bidder can add a bid by specifying the blockchain on which the bid is made and the amount of tokens to bid. A transaction is then made to the relevant coin contract and the information is sent to the relay CC-SVC. A user can also abort any bids that she has made via the CC-SVC. After the auction is concluded, the relay CC-SVC informs all participants and specifies the tentative transfer of goods in the smart contracts. The CC-SVC then asks all participants’ clients to participate in creating a commit vote. (Failure to participate should result in a penalty [4].) When the commit vote has been created, it is sent to all contracts to initiate the final transfer of assets. At this point, the GUI will show that the auction has concluded. The exact flow of the demo will be as follows: One user – the auctioneer – opens a web-browser based GUI and uses it to initiate an auction for a selected asset. In this process, all the features on the auction creation page are demonstrated. The asset exists on a dedicated ticket chain running in Hyperledger Fabric. Contracts are created on all involved blockchains (step 1 of Figure 2. At least two other users, who use browser windows on different machines, navigate to the newly created auction’s detail page and submit their individual bids for the asset (step 2 of Figure 2). At least one bidder uses (private) Ethereum, and the other uses Quorum. After some time, the auction is concluded and the winning bid is determined (step 3 of Figure 2). This will cause an “end auction” event to be sent to the relay CCSVC by the auctioneer. The signers, who are listening for this type of event, will notice the event and construct a commit vote (step 4 of Figure 2). The commit vote is then sent to Kafka, and forwarded by the relay node to the auction contract and the coin chain contracts. At this point, the asset is transferred to the winning bidder, and the winning bid to the auctioneer (step 5 of Figure 2). Throughout the demo, we will use a terminal window to query the states of the underlying blockchains after each step, as displayed in Figure 4. This will allow the audience to observe the changes happening in the background, and to interact with the flow of the demonstration: e.g., by asking for new actions to see how the background states change. To illustrate the flow of the demo, a video can be found online 2 which depicts the tentative demo slides, and the screen if the auctioneer and bidders were to perform their actions using a single computer. (This is not a limitation of PIECHAIN, but makes it easier to record video.) V. EXTENSIONS The CC-SVC framework and the interface for the supported blockchains can be used to easily extend PIECHAIN to other use-cases. One of these is a cross-chain flash loan as described in [6]. A GUI for flash loans would have limited practical relevance as arbitrage opportunities are typically resolved rapidly, so the interactions with the CC-SVC would normally be done by trading bots. However, if time permits, we will display a visualization for the impact of the steps in a flash loan on the states of the various involved contracts. REFERENCES [1] Rafael Belchior, Andre Vasconcelos, S ´ ergio Guerreiro, and Miguel ´ Correia. A survey on blockchain interoperability: Past, present, and future trends. ACM Computing Surveys (CSUR), 2021. [2] Miguel Castro and Barbara Liskov. Practical Byzantine fault tolerance. In OsDI, volume 99, pages 173–186, 1999. [3] CoinLore. https://www.coinlore.com/all coins, 2023. [4] Daniel Engel, Maurice Herlihy, and Yingjie Xue. Failure is (literally) an option: Atomic commitment vs optionality in decentralized finance. In SSS 2021, 2021. [5] Maurice Herlihy. Atomic cross-chain swaps. In ACM PODC, pages 245–254, 2018. [6] Maurice Herlihy, Barbara Liskov, and Liuba Shrira. Cross-chain deals and adversarial commerce. The VLDB Journal, 2021. [7] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008. [8] Sri AravindaKrishnan Thyagarajan, Giulio Malavolta, and Pedro Moreno-Sanchez. Universal atomic swaps: Secure exchange of coins across all blockchains. In IEEE S&P, 2022. [9] Victor Zakhary, Divyakant Agrawal, and Amr El Abbadi. Atomic commitment across blockchains. Proceedings of the VLDB Endowment, 13(9), 2021. [10] Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias, and William J Knottenbelt. SoK: Communication across distributed ledgers. In Financial Crypto, 2021. [11] Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais, and William Knottenbelt. Xclaim: Trustless, interoperable, cryptocurrency-backed assets. In IEEE S&P, 2019. This paper is available on arxiv under CC 4.0 license. Authors: (1) Daniel Reijsbergen, Nanyang Technological University, Singapore, Singapore; (2) Aung Maw, Singapore University of Technology and Design, Singapore, Singapore; (3) Jingchi Zhang, Nanyang Technological University, Singapore, Singapore; (4) Tien Tuan Anh Dinh, Deakin University, Melbourne, Australia; (5) Anwitaman Datta, Nanyang Technological University, Singapore, Singapore. Authors: Authors: (1) Daniel Reijsbergen, Nanyang Technological University, Singapore, Singapore; (2) Aung Maw, Singapore University of Technology and Design, Singapore, Singapore; (3) Jingchi Zhang, Nanyang Technological University, Singapore, Singapore; (4) Tien Tuan Anh Dinh, Deakin University, Melbourne, Australia; (5) Anwitaman Datta, Nanyang Technological University, Singapore, Singapore. Content Overview Abstract & Introduction Overview of PIEChain Implementation of PIEChain Demontration Plan Extensions References Abstract A plethora of different blockchain platforms have emerged in recent years, but many of them operate in silos. As such, there is a need for reliable cross-chain communication to enable blockchain interoperability. Blockchain interoperability is challenging because transactions can typically not be reverted – as such, if one transaction is committed then the protocol must ensure that all related transactions are committed as well. Existing interoperability approaches, e.g., Cosmos and Polkadot, are limited in the sense that they only support interoperability between their own subchains, or require intrusive changes to existing blockchains. To overcome this limitation, we propose PIECHAIN, a general, Kafka-based cross-chain communication framework. We utilize PIECHAIN for a practical case study: a cross-chain auction in which users who hold tokens on multiple chains bid for a ticket sold on another chain. PIECHAIN is the first publicly available, practical implementation of a general framework for cross-chain communication. I. INTRODUCTION A blockchain is a replicated, tamper-evident database designed for hostile environments. It consists of a number of nodes, of which some may be malicious, which maintain an append-only ledger. The ledger stores transactions that modify some global states. In the canonical example, i.e., cryptocurrencies [7], the global states are user accounts and native (fungible) tokens, and the ledger contains transactions transferring tokens from one account to another. In another emerging application, the blockchains store non-fungible tokens (NFTs) uniquely representing assets, e.g., digital art works or concert tickets. Many blockchains also support smart contracts letting users define their own states and codes that modify the states. Smart contracts are stored in the ledger and are replicated and kept consistent by all the blockchain nodes. In recent years, many independent blockchain platforms have emerged, resulting in an ecosystem with a long tail. On the one hand, there are a small number of hugely popular, general-purpose blockchain platforms such as Ethereum and Hyperledger. On the other hand, there are thousands of smaller blockchains designed for specific applications, most of which are only in early stages of development. This includes more than 10 000 cryptocurrencies [3] as of early 2023, alongside blockchains for healthcare, identity management, and IoT. In general, these blockchains do not interoperate, i.e., they exist in silos. As such, blockchain interoperability, i.e., the ability for users to exchange information or assets on different blockchains, is a subject that is drawing increasing interest from the research community [6], [10], [4], [1], [11]. One of the main challenges in designing a secure blockchain interoperability framework is to guarantee atomicity, i.e., that either all steps of an agreed set of transactions terminate successfully, or none do. This is more complicated in blockchains than in traditional databases because blockchain transactions are (in principle) irreversible. For example, if a payment for an NFT on Chain A has already been made on Chain B, then atomicity requires that the transaction on Chain A must go ahead because the transaction on Chain B cannot be reverted. One common approach to guarantee atomicity is to escrow all of the tokens that are involved in the deal in smart contracts, and release them only through a commit message that is signed by all parties [6]. Another important challenge in blockchain interoperability is to guarantee liveness, so that the tokens that are escrowed cannot be frozen forever. To ensure liveness, it must be possible for nodes to send an abort message that allows all parties to withdraw their assets from escrow. To guarantee both atomicity and liveness, an interoperability framework must be able to tolerate adversarial nodes who send a commit message to one blockchain and an abort message to another. It is known for asynchronous networks (i.e., where there is no bound on message delays) that this is impossible to achieve without a trusted third party (TTP) [10]. There are two main approaches to overcome this challenge [6]. The first approach is to combine a synchrony assumption with a cooldown period for aborts – i.e., assuming that a commit vote, once generated, can be appended to all affected blockchains before the end of any cooldown period for aborts. This approach is taken in, e.g., hashed timelocked contracts [5]. The second approach is to replace the TTP with another blockchain to ensure that either a valid commit or abort message can be created, but not both [6], [9]. Although approaches of both types have been proposed in the scientific literature, they either do not have a publicly available implementation [5], [6], [9], or are limited in their application scope, e.g., creating backed assets on another blockchain [11] or token swaps [8]. In a separate development, several blockchain platforms have emerged that enable interoperability by default, e.g., Cosmos and Polkadot. However, these platforms only support interoperability between their own subchains, or require intrusive changes to existing blockchains. This motivates the need for a general and practical interoperability framework that can be interfaced to existing blockchain platforms without modifying them. Our goal is to provide such a framework. Contributions & Novelty : We present PIECHAIN to achieve this goal. As synchrony is difficult to assume in practice, PIECHAIN uses cross-chain services to replace the TTP. The cross-chain services communicate using an event log that uses Apache’s Kafka protocol for efficiency. To demonstrate the practical relevance of PIECHAIN, we have implemented a cross-chain service for a realistic case study: a cross-chain auction. We have interfaced PIECHAIN with some of the most popular blockchain platforms that support smart contracts: Ethereum, Hyperledger Fabric, and Quorum. Finally, we have developed a GUI for our case study. The auction case study is one of three case studies (two auctions and a flash loan [6]) whose code can be found in the PIEChain code repository on GitHub. Contributions & Novelty II. OVERVIEW OF PIECHAIN A. Entities The main entities in PIECHAIN are as follows (see also Figure 1): Blockchains, which store assets (e.g., tokens, keys) that are held by users. A user may hold assets on multiple blockchains. Each blockchain has its own protocol to determine who has read and write access – blockchains are typically either permissioned, i.e., a fixed set of nodes has read and write access, or permissionless, i.e., everyone has read access and can create transactions, and nodes with sufficient power (e.g., processing speed) can add transactions to the blockchain. Cross-chain services (CC-SVCs), which allow users to exchange assets on different blockchains. Each CC-SVC consists of a server that interacts with user clients to facilitate crosschain communication. In practice, the CC-SVC charges the users for participation, and it can interact with any number of blockchains. In the following, each CC-SVC corresponds to a set of events involved in an atomic exchange of assets that are sent by a server to the Kafka ledger. In practice, a single server may operate many CC-SVCs. The Kafka network, which serves as an append-only log of events generated by the CC-SVCs. Events correspond to transactions made on underlying blockchains. The Kafka network is operated by a fixed set of nodes who charge CCSVCs for uploading events. In PIECHAIN, we assume that the CC-SVCs are semitrusted, and that they are motivated to behave honestly by having a reputation to uphold, akin to commercial outsourced service providers. The Kafka network operators are untrusted but have no incentive to misbehave as they do not interact with the underlying blockchains. This allows us to run a protocol (Kafka) that prioritizes efficiency over security. An alternative design is to make the CC-SVCs untrusted and the Kafka network trusted. In this case, each Kafka node runs a (light) client for each of the underlying blockchains to validate the inclusion of transactions on those chains. In this case, the event log would have to use a more secure protocol such as PBFT [2]. We leave such a design as future work. B. Process Flow Given the entities of Section II-A, the process flow in PIECHAIN has the same structure as cross-chain deals as proposed by Herlihy et al. [6]. Cross-chain deals are agreements by multiple users to exchange assets on different blockchains, and consist of five phases (see also Figure 2): Clearing phase: the CC-SVC creates the smart contracts on the different blockchains that are used to escrow and transfer the assets involved in the deal. Escrow phase: the users escrow their outgoing assets by transferring them to the smart contracts. Transfer phase: the assets are tentatively exchanged, i.e., the execution logic of the smart contracts is specified. Validation phase: each user checks whether the result of the execution logic would be to their satisfaction. Commit phase: the deal is concluded through commitment if all parties are satisfied, or through abortion otherwise. Commitment means that the execution logic in the smart contracts is executed and that the assets are exchanged as specified by the deal. Abortion means that the assets in each smart contract are returned to their original owners. Clearing phase: the CC-SVC creates the smart contracts on the different blockchains that are used to escrow and transfer the assets involved in the deal. Clearing phase: the CC-SVC creates the smart contracts on the different blockchains that are used to escrow and transfer the assets involved in the deal. Escrow phase: the users escrow their outgoing assets by transferring them to the smart contracts. Escrow phase: the users escrow their outgoing assets by transferring them to the smart contracts. Transfer phase: the assets are tentatively exchanged, i.e., the execution logic of the smart contracts is specified. Transfer phase: the assets are tentatively exchanged, i.e., the execution logic of the smart contracts is specified. Validation phase: each user checks whether the result of the execution logic would be to their satisfaction. Validation phase: each user checks whether the result of the execution logic would be to their satisfaction. Commit phase: the deal is concluded through commitment if all parties are satisfied, or through abortion otherwise. Commitment means that the execution logic in the smart contracts is executed and that the assets are exchanged as specified by the deal. Abortion means that the assets in each smart contract are returned to their original owners. Commit phase: the deal is concluded through commitment if all parties are satisfied, or through abortion otherwise. Commitment means that the execution logic in the smart contracts is executed and that the assets are exchanged as specified by the deal. Abortion means that the assets in each smart contract are returned to their original owners. To commit, the users interactively construct a commit vote, which is sent by the CC-SVC to the Kafka ledger. To abort, a single user sends an abort message to the CC-SVC. For each CC-SVC, either a commit or abort message can be added to the Kafka ledger, but not both. An inclusion proof of a commit vote on the Kafka ledger is accepted by all the smart contracts on the different blockchains – this guarantees that once a commit vote is constructed, either all asset transfers can be executed or none. III. IMPLEMENTATION OF PIECHAIN To illustrate the practical applicability of PIECHAIN, we have interfaced it to several commonly-used blockchain platforms and used it to implement an application from the scientific literature [6]: a cross-chain auction for a digital asset. The blockchain support extends to other case studies, as we discuss in Section V. A. Blockchain Support To interface an underlying blockchain with PIECHAIN, the CC-SVCs must be able to validate transactions on those chains. Our implementation supports the following blockchain platforms: Ethereum (both the Proof-of-Work and Proof-ofAuthority versions of private Ethereum), Hyperledger Fabric, and Quorum. The latter two support permissioned blockchains, whereas Ethereum has a permissionless main chain but also supports private chains with the same functionality. B. Auction In our case study, an auctioneer sells an asset on one blockchain and receives payment in the form of assets on another blockchain. As in [6], we use the example of a ticket seller. The ticket is an NFT on a dedicated blockchain, whereas the other blockchain supports more commonly-used fungible tokens (e.g., Ether). The former blockchain is called the ticket blockchain and the latter the coin blockchain. This is easily generalized to settings with more than one coin blockchain. In the following, we consider a first-price auction (i.e., the bidder with the highest bid pays its bid and receives the asset). The five phases of the protocol are then as follows: The auctioneer enlists a CC-SVC which creates smart contracts on the ticket blockchain and the coin blockchains. The auctioneer transfers its asset (the ticket’s NFT) to the ticket contract, and the bidders transfer their bids to the contract on their coin blockchain. The execution logic is determined: the auctioneer updates each of the ticket and coin contracts by specifying which party receives the ticket and which bid is transferred to the auctioneer. (Note that this logic cannot be specified in the ticket contract a priori because the contract on the ticket chain cannot read data from the coin blockchains.) Each user (i.e., the auctioneer and the bidders) determines whether the outcome of the transfer protocol is agreeable to them, i.e., whether the ticket is indeed transferred to the correct party. All users construct a commit vote – once this has been constructed, it is sent to each contract to enact the transfers specified in the transfer phase. The auctioneer enlists a CC-SVC which creates smart contracts on the ticket blockchain and the coin blockchains. The auctioneer enlists a CC-SVC which creates smart contracts on the ticket blockchain and the coin blockchains. The auctioneer transfers its asset (the ticket’s NFT) to the ticket contract, and the bidders transfer their bids to the contract on their coin blockchain. The auctioneer transfers its asset (the ticket’s NFT) to the ticket contract, and the bidders transfer their bids to the contract on their coin blockchain. The execution logic is determined: the auctioneer updates each of the ticket and coin contracts by specifying which party receives the ticket and which bid is transferred to the auctioneer. (Note that this logic cannot be specified in the ticket contract a priori because the contract on the ticket chain cannot read data from the coin blockchains.) The execution logic is determined: the auctioneer updates each of the ticket and coin contracts by specifying which party receives the ticket and which bid is transferred to the auctioneer. (Note that this logic cannot be specified in the ticket contract a priori because the contract on the ticket chain cannot read data from the coin blockchains.) Each user (i.e., the auctioneer and the bidders) determines whether the outcome of the transfer protocol is agreeable to them, i.e., whether the ticket is indeed transferred to the correct party. Each user (i.e., the auctioneer and the bidders) determines whether the outcome of the transfer protocol is agreeable to them, i.e., whether the ticket is indeed transferred to the correct party. All users construct a commit vote – once this has been constructed, it is sent to each contract to enact the transfers specified in the transfer phase. All users construct a commit vote – once this has been constructed, it is sent to each contract to enact the transfers specified in the transfer phase. In PIECHAIN, the auction requires two (logical) types of CC-SVC: the relayer and the signer. The relayer listens for events (bids) on the coin chains and relays them to the ticket blockchain. The signer assists in creating the commit vote. IV. DEMONSTRATION PLAN For our demonstration, we have developed a graphical user interface (GUI) using the React framework to illustrate a cross-chain auction. The GUI consists of three main pages: a dashboard page that displays a list of known auctions as depicted in Figure 3, a detailed view for individual auctions as depicted in Figure 5, and a page for the creation of new auctions (not displayed). The view is the same for an auctioneer as for bidders. On the dashboard view, prospective auctioneers can click the “Create New Auction” button to initiate an auction – the auctioneer selects a CC-SVC, the asset to be auctioned, which other blockchains to accept bids from, the exchange rate for tokens between different blockchains (which must be fixed in advance), and the time at which the auction is concluded. Next, the relay CC-SVC creates the relevant contracts, and sends the address of the contract on the asset chain to the auctioneer. The auctioneer can then add the auction on its dashboard by adding the contract address and clicking the “Add Existing Auction” button. Meanwhile, it advertises the contract address to potential bidders. When the bidders become aware of the asset contract address, they can also add it to their dashboards. After the bidder has added the auction, she can view it in more detail by pressing the “View” button in the auction’s panel, which takes her to the detailed view page. On this page, the bidder is able to view crucial information about the auction such as its creation and conclusion times, and a list of bids. The highest bid is marked with an asterisk. If the auction is still ongoing, then the bidder can add a bid by specifying the blockchain on which the bid is made and the amount of tokens to bid. A transaction is then made to the relevant coin contract and the information is sent to the relay CC-SVC. A user can also abort any bids that she has made via the CC-SVC. After the auction is concluded, the relay CC-SVC informs all participants and specifies the tentative transfer of goods in the smart contracts. The CC-SVC then asks all participants’ clients to participate in creating a commit vote. (Failure to participate should result in a penalty [4].) When the commit vote has been created, it is sent to all contracts to initiate the final transfer of assets. At this point, the GUI will show that the auction has concluded. The exact flow of the demo will be as follows: One user – the auctioneer – opens a web-browser based GUI and uses it to initiate an auction for a selected asset. In this process, all the features on the auction creation page are demonstrated. The asset exists on a dedicated ticket chain running in Hyperledger Fabric. Contracts are created on all involved blockchains (step 1 of Figure 2. At least two other users, who use browser windows on different machines, navigate to the newly created auction’s detail page and submit their individual bids for the asset (step 2 of Figure 2). At least one bidder uses (private) Ethereum, and the other uses Quorum. After some time, the auction is concluded and the winning bid is determined (step 3 of Figure 2). This will cause an “end auction” event to be sent to the relay CCSVC by the auctioneer. The signers, who are listening for this type of event, will notice the event and construct a commit vote (step 4 of Figure 2). The commit vote is then sent to Kafka, and forwarded by the relay node to the auction contract and the coin chain contracts. At this point, the asset is transferred to the winning bidder, and the winning bid to the auctioneer (step 5 of Figure 2). One user – the auctioneer – opens a web-browser based GUI and uses it to initiate an auction for a selected asset. In this process, all the features on the auction creation page are demonstrated. The asset exists on a dedicated ticket chain running in Hyperledger Fabric. Contracts are created on all involved blockchains (step 1 of Figure 2. One user – the auctioneer – opens a web-browser based GUI and uses it to initiate an auction for a selected asset. In this process, all the features on the auction creation page are demonstrated. The asset exists on a dedicated ticket chain running in Hyperledger Fabric. Contracts are created on all involved blockchains (step 1 of Figure 2. At least two other users, who use browser windows on different machines, navigate to the newly created auction’s detail page and submit their individual bids for the asset (step 2 of Figure 2). At least one bidder uses (private) Ethereum, and the other uses Quorum. At least two other users, who use browser windows on different machines, navigate to the newly created auction’s detail page and submit their individual bids for the asset (step 2 of Figure 2). At least one bidder uses (private) Ethereum, and the other uses Quorum. After some time, the auction is concluded and the winning bid is determined (step 3 of Figure 2). This will cause an “end auction” event to be sent to the relay CCSVC by the auctioneer. The signers, who are listening for this type of event, will notice the event and construct a commit vote (step 4 of Figure 2). The commit vote is then sent to Kafka, and forwarded by the relay node to the auction contract and the coin chain contracts. At this point, the asset is transferred to the winning bidder, and the winning bid to the auctioneer (step 5 of Figure 2). After some time, the auction is concluded and the winning bid is determined (step 3 of Figure 2). This will cause an “end auction” event to be sent to the relay CCSVC by the auctioneer. The signers, who are listening for this type of event, will notice the event and construct a commit vote (step 4 of Figure 2). The commit vote is then sent to Kafka, and forwarded by the relay node to the auction contract and the coin chain contracts. At this point, the asset is transferred to the winning bidder, and the winning bid to the auctioneer (step 5 of Figure 2). Throughout the demo, we will use a terminal window to query the states of the underlying blockchains after each step, as displayed in Figure 4. This will allow the audience to observe the changes happening in the background, and to interact with the flow of the demonstration: e.g., by asking for new actions to see how the background states change. To illustrate the flow of the demo, a video can be found online 2 which depicts the tentative demo slides, and the screen if the auctioneer and bidders were to perform their actions using a single computer. (This is not a limitation of PIECHAIN, but makes it easier to record video.) V. EXTENSIONS The CC-SVC framework and the interface for the supported blockchains can be used to easily extend PIECHAIN to other use-cases. One of these is a cross-chain flash loan as described in [6]. A GUI for flash loans would have limited practical relevance as arbitrage opportunities are typically resolved rapidly, so the interactions with the CC-SVC would normally be done by trading bots. However, if time permits, we will display a visualization for the impact of the steps in a flash loan on the states of the various involved contracts. REFERENCES [1] Rafael Belchior, Andre Vasconcelos, S ´ ergio Guerreiro, and Miguel ´ Correia. A survey on blockchain interoperability: Past, present, and future trends. ACM Computing Surveys (CSUR), 2021. [2] Miguel Castro and Barbara Liskov. Practical Byzantine fault tolerance. In OsDI, volume 99, pages 173–186, 1999. [3] CoinLore. https://www.coinlore.com/all coins, 2023. [4] Daniel Engel, Maurice Herlihy, and Yingjie Xue. Failure is (literally) an option: Atomic commitment vs optionality in decentralized finance. In SSS 2021, 2021. [5] Maurice Herlihy. Atomic cross-chain swaps. In ACM PODC, pages 245–254, 2018. [6] Maurice Herlihy, Barbara Liskov, and Liuba Shrira. Cross-chain deals and adversarial commerce. The VLDB Journal, 2021. [7] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008. [8] Sri AravindaKrishnan Thyagarajan, Giulio Malavolta, and Pedro Moreno-Sanchez. Universal atomic swaps: Secure exchange of coins across all blockchains. In IEEE S&P, 2022. [9] Victor Zakhary, Divyakant Agrawal, and Amr El Abbadi. Atomic commitment across blockchains. Proceedings of the VLDB Endowment, 13(9), 2021. [10] Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias, and William J Knottenbelt. SoK: Communication across distributed ledgers. In Financial Crypto, 2021. [11] Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais, and William Knottenbelt. Xclaim: Trustless, interoperable, cryptocurrency-backed assets. In IEEE S&P, 2019. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv