BlockChain I/O: Enabling Cross-Chain Commerce

Blockchain technology enables secure tokens transfers in digital marketplaces, and recent advances in this field provide other desirable properties such as efficiency, privacy, and price stability. However, these properties do not always generalize to a setting across multiple independent blockchains. Despite the growing number of existing blockchain platforms, there is a lack of an overarching framework whose components provide all of the necessary properties for practical cross-chain commerce. We present BlockChain I/O to provide such a framework. BlockChain I/O introduces entities called cross-chain services to relay information between different blockchains. The proposed design ensures that cross-chain services cannot violate transaction safety, and they are furthermore disincentivized from other types of misbehavior through an audit system. BlockChain I/O uses native stablecoins to mitigate price fluctuations, and a decentralized ID system to allow users to prove aspects of their identity without violating privacy. After presenting the core architecture of BlockChain I/O, we demonstrate how to use it to implement a cross-chain marketplace and discuss how its desirable properties continue to hold in the end-to-end system. Finally, we use experimental evaluations to demonstrate BlockChain I/O's practical performance.


Introduction
Numerous blockchains, distributed ledgers, 1 and Decentralized Finance (DeFi) products have been designed and deployed, resulting in a siloed ecosystems since most of these systems do not support interoperation with others by design. 'To ameliorate the limitations of isolated blockchains, several works have aimed at enabling different extents of intercommunication, interoperation and integration across blockchains. These include theoretical building blocks as well as functional software artefacts, with some that are limited to specific subsets of systems, whereas others are more general-purpose [4,18,19,44]. Among these, the most basic are generic payload-agnostic inter-blockchain communication mechanisms [17,23,43] and protocols for value transfer, payments, or exchanges across blockchains [25,39,40] which assume and enable upper-layer applications to orchestrate the business logic. Other examples include dedicated bridges that validate transfers between a given pair of blockchains [14,42], mechanisms that ensure the security of cross-chain transfers through timelocks [22,40], and relay chains that support efficient state proofs [8,31].
The wealth of proposals mentioned above indicates that there is a rich set of existing solutions that ensure the basic security of cross-chain interactions, i.e., that tokens are never stolen or locked forever. However, as in Maslow's hierarchy of needs, there are desirable properties beyond basic security in the context of Web3.0: examples include privacy, resistance to token price fluctuations, and support for a wide range of use cases. Although approaches exist that address some of these aspects in isolation, such as privacy [11], stablecoin support [34], and generality [35], there is a need for an umbrella framework that achieves all of the desired primitives. The Indian government's Open Network for Digital Commerce [33] is a useful starting point both for the aspired nature of an open marketplace in general and also in part in determining the list of desired primitives.
In this paper we enumerate a set of additional desirable functionalities required as building blocks for versatile crosschain commerce, and describe a modular technology stack, BlockChain I/O (see Figure 1) that achieves these desiderata. In addition to the aforementioned basic functions of intercommunication, value transfers, and cross-chain swaps and deals (which are realized in BlockChain I/O through an extension of PieChain [35]), 2 we identify further functionalities that are required for an infrastructure which can support versatile cross-chain commerce. Furthermore, we propose ways to achieve a key subset of these functionalities; details of which and how they interact among each other comprise the main technical contributions of this paper. We note that storage solutions, such as the InterPlanetary File System (IPFS) [6] may also be essential for operationalizing fully decentralized applications and marketplaces -however, the proposed BlockChain I/O architecture is agnostic to the data storage service (which could be cloud-based).
BlockChain I/O supports the following components in a unified framework for cross-chain commerce.
Atomic Cross-chain Transactions. The first and most basic desirable property for cross-chain commerce is that token transfers are atomic -i.e., all transfers in a deal happen or none do. This ensures that users who send tokens also receive the tokens agreed in the deal. To ensure atomicity, we use PieChain for cross-chain communication: dedicated entities called cross-chain services relay relevant information, e.g., bids and token prices, between nodes. Once the outline of a deal has become clear, e.g., after an auction has terminated, they send a tentative exchange of tokens to the involved blockchains, and the users lock their tokens in escrow. Users then vote to commit if the exchange of tokens is agreeable, and abort otherwise. As such, BlockChain I/O facilitates cross-chain deals [23] which have proven security guarantees, i.e., safety and liveness. If cross-chain services misbehave, e.g., if they go offline while processing a deal, or if they misrepresent the outcome of an auction, then this is provable to nodes who view the relevant blockchains. In BlockChain I/O, we utilize a separate class of nodes called auditors to detect this misbehavior and relay it to a governance layer -the resulting reputation damage provides a disincentive for cross-chain services to misbehave.
Decentralized Identities. A second desirable property for cross-chain commerce is the ability to assure users that the entities with whom they interact have certain attributes, e.g., that they are real people or licensed companies, that they have a demonstrable track record in their field, or that they have the correct age or country of residence. Challenges include the multitude of different ledgers that provide this information (e.g., by countries or corporations) and ensuring user privacy through pseudonymity. In BlockChain I/O, we leverage Hyperledger AnonCreds [24] for this purpose.
Native Stablecoin Support. When carrying out multichain transactions, there are several practical bottlenecks that involve economic rather than technical considerations, e.g., i) the tokens involved in deals may lose value, ii) parties may abandon trades leading to opportunity costs for others, and iii) users may be reluctant to receive payments in less popular, volatile currencies, even when it is technically possible. As such, a third desirable property is support for a currency which can be naturally used across chains, and which provides stability against price volatility or catastrophic failure of smaller blockchains and associated cryptocurrencies. In this paper, we explore how a cross-chain stablecoin based on recent work CroCoDai [34] can be implemented for cross-chain commerce and integrated with our core interoperability module, PieChain.
Generality. Although there are already many existing blockchain platforms, they often impose bottlenecks in the form of high cost, low performance, etc. As such, it can occasionally be advantageous to deploy a new, purposespecific ledger. The only requirements for integrating a new blockchain in BlockChain I/O is for the governance nodes and at least one cross-chain service to run a (light) client for the new blockchain, and for BlockChain I/O's core contracts to be translated to the new blockchain's virtual machine code. If blockchains share the same virtual machine design, e.g., the Ethereum Virtual Machine (EVM), then the smart contracts can be re-used -furthermore, the construction of the commit vote in PieChain is more efficient if the blockchains share a built-in signature verification scheme.
Finally, to validate the implementation of our ideas and viability of a versatile platform for cross-chain commerce, we implement a decentralized marketplace that allows users to create and bid on token listings both as a proof-of-concept, and to drive our performance benchmark experiments.
In summary, our contributions are as follows.
• We present BlockChain I/O, a framework for crosschain commerce that has the desirable properties of atomic cross-chain transactions, decentralized identities that preserve privacy, native stablecoin support, and generality as discussed above.
• We present an implementation of a decentralized marketplace that is built using BlockChain I/O, and provide the results of benchmark experiments to show that it has practical performance.
The rest of this paper is organized as follows. Section 2 presents the background and related work. Section 3 discusses two use cases for cross-chain commerce. Section 4 presents the core architecture of BlockChain I/O, including the components and system requirements, while Section 5 presents the digital identity component in detail. Section 6 presents a decentralized marketplace built on top of BlockChain I/O. Section 7 presents the experimental results and Section 8 concludes the paper.

Background & Related Work
In this section, we first discuss existing cross-chain mechanisms and related work on digital identities. Next, we discuss related work on e-commerce and reputation systems, which we need for the online marketplace of Section 6.

Blockchains & Cross-chain systems
Blockchains are decentralized, append-only ledgers that can be used to track the ownership of digital tokens. Each individual blockchain is an ordered list of transactions that are grouped into blocks, and each block contains a reference to a previous block, forming a chain. A transaction may represent a change of tokens, or a call to a smart contract which is a piece of code on the blockchain. Smart contracts can be used to implement the logic of cross-chain commerce concepts such as auctions and listings. By executing the full list of transactions in the blockchain, a node obtains the global state, i.e., the current ownership of all digital tokens and the internal states of all smart contracts. Blockchains transactions are atomic by design, i.e., if a single transaction consists of multiple steps that modify the global state, then if any step is committed/aborted then all are. However, atomicity cannot be guaranteed by default in cross-chain systems where transactions may involve steps on different blockchains. Existing cross-chain solutions can be typically categorized as sidechains, relays, notary schemes, or ledgers of ledgers [4]. A sidechain is a blockchain that interacts with another (typically primary) blockchain as an extension, aiming to improve its scalability or interoperability. Major examples of sidechains in the context of Bitcoin include RSK [29] and the Liquid Network [32]. A notary scheme is a system where an entity initiates a transaction on one blockchain in response to a specific event occurring on another blockchain -one example is the PieChain framework that we use in the core architecture of Section 4. Similarly, a relay refers to a mechanism where a designated entity keeps track of events or transactions on one blockchain and then relays this information to another blockchain. One of the most popular relay solutions, BTC Relay, 3 was released in 2016 by the Ethereum Foundation. It is a bridge between the Bitcoin blockchain and Ethereum smart contracts. Since Bitcoin block headers are stored in an Ethereum smart contract, BTC Relay is able to securely verify Bitcoin transactions without any intermediaries. Finally, a 'ledger of ledgers' system is one where a central blockchain is connected to multiple other blockchains (known as sidechains or parachains). These blockchains collectively form an interconnected ecosystem. Polkadot [10] exemplifies such a system. It relies on an underlying relay chain for security, which can be used by other parachains (parallel chains), which could in principle run distinct protocols, inducing in effect a logical star topology with the relay chain in the center. Thus Polkadot achieves not only sharding to improve scalability, but also provides support for heterogeneity, and given that all the parachains rely on the same relay chain, the parachains can natively interoperate. However, this does not immediately help in solving the larger problem of facilitating arbitrary existing blockchain pairs which do not share Polkadot's relay chain, to interoperate among themselves. Similar to Polkadot, Cosmos [27] also uses a central 'hub' which ensures governance at a global level, while supporting parallel chains called 'zones'.
The idea of disentangling a blockchain's security (in effect, its consensus mechanism) from its operating environment is extended in 1DLT [9], which uses a 'Consensus as a Service' (CaaS) abstraction. In contrast to Polkadot's unique relay chain, 1DLT harnesses multiple public blockchains such as Algorand [16] and Hedera [2] for the underlying consensus-dependent security guarantees to deploy EVMbased blockchains enjoying the versatile programmability of EVMs while evading Ethereum's high cost and low throughput issues. Though the current 1DLT [9] implementation only supports EVMs, the CaaS abstraction can in principle be extended to support other environments, similar to Polkadot. While the CaaS module in 1DLT itself relies on multichain interaction, CaaS or 1DLT do not address the general problem of interoperation of multiple blockchains. However, such on-demand deployment of DLTs can be handy to spin-up a new ledger for any purpose, and readily integrate it with BlockChain I/O's open marketplace.

Digital Identities
A digital identity is commonly defined as a one-to-one relationship between an individual and her digital presence, where such a presence in our setting refers to a set of attributes such as age, location, etc. An approach for digital identities utilize Self Sovereign Identity (SSI) schemes, providing individuals with full control and ownership over usage of their data [13]. The Sovrin Network is one such publiclyaccessible blockchain based technique [41] supporting verifiable claims involving SSIs. However, potential pitfalls for SSI users include: a lack of trust between identity issuers and validators [13], identity theft and fraud, the difficulty of loading verifiable credentials to a user's wallet, secure authentication, and poor key recovery. These limitations can be addressed with Decentralized Identifiers (DIDs, alternatively referred also as decentralized Digital Identities) that support Verifiable Credentials (VCs) following W3C-recommended verifiable credential data models. DID schemes assign the various actions required for the creation and verification of digital identities to different user types, particularly holders who have a digital presence, issuers who issue DIDs, and verifiers who verify DIDs. DID schemes require a Verifiable Data Registry (VDR) scheme to store meta-information that governs the structure of the DIDs and VCs -e.g., which attributes are stored and in what format -and the public keys of DID issuers. Hyperledger AnonCreds [24] is an increasingly popular toolset that enables the creation of DIDs and VDRs. AnonCreds specifies a set of protocols for zeroknowledge proofs and schema definitions that allow any consortium of users to run a VDR on a permissioned blockchain, e.g., Hyperledger Indy, where the consortium members have write access and arbitrary users can have read access. It is inherently decentralized. Subject to acceptance of participants within an ecosystem, arbitrary entities may participate as issuers, in the creation of VDRs, or the creation of DIDs given a VDR. DID schemes provide privacy through the use of zero-knowledge cryptography to prove attributes from a DID, and accountability because issuers sign the DIDs so that issuers of incorrect DIDs suffer reputation damage.

E-Commerce
E-commerce, i.e., the electronic sale of goods or services, grew rapidly after the emergence of the World Wide Web and digital payments in the 1990s. A prominent example of e-commerce is an online marketplace in which a website is maintained by a dedicated entity -e.g., eBay or Amazon -and a multitude of independent vendors create listings that are browsed and purchased by buyers. Depending on the marketplace, vendors can set a fixed price for each item (e.g., Amazon), or buyers can bid for the items through an e-auction mechanism (e.g., e-Bay). There is a variety of auctions, i.e., open-bid increasing-price (English) auctions, openbid decreasing-price (Dutch) auctions, sealed-bid first-price auctions, and sealed-bid second-price (Vickrey) auctions [12]. Recent advances in the field of multi-party computation and zero-knowledge cryptography have enabled e-auction approaches that are both privacy-preserving and verifiable [1,7], thus enabling e-auctions on public blockchains [15].

Reputation Systems
One critical factor that determines the success of e-commerce platforms is trust [3]. Vendors can establish trust through repeated interactions with buyers during which the properties above are demonstrated. In the case of an online marketplace, the result of interactions can be registered by the buyers through a reputation system. For example, in eBay, the percentage of positive feedback is displayed on each vendor's account page. Privacy is an important aspect of reputation systems: if user identities are known, then users may avoid giving negative feedback out of fear of retaliation -however, if users are fully anonymous, then this may allow vendors to inflate their reputation (or damage their competitors') through dummy accounts -a so-called Sybil attack.
Hasan et al. [20] present a systemic overview of privacypreserving reputation systems (PPRSs), and distinguish two main categories: i) User anonymity-oriented PPRSs, in which user identities are hidden and feedback is visible, and ii) Feedback confidentiality-oriented PPRSs, in which user identities are visible and feedback is hidden. Martins et al. [30] present a blockchain-based e-commerce framework in which buyers can pool their orders in a single listing, and sellers compete to supply all the buyers in a listing through a descending-bid auction. By pooling buyers, they are able to design a reputation system that is resilient to Sybil attacks: fake buyer(s) who collude with sellers to boost the seller's rating are at risk of having to purchase a real item if an honest seller wins the auction, as their payments are held in escrow. Soska et al. [36] present Beaver, a decentralized anonymous marketplace in which the cost of a Sybil attack can be made explicit.

Decentralized E-Commerce: Use Cases
In the following, we discuss two use cases for decentralized e-commerce platform and discuss why the components discussed in the introduction provide non-trivial solutions to the challenges.

Scalping-Resistant Ticket Sales
Ticket scalping refers to the practice where tickets are bought by third parties for the sole purpose of re-selling them at a higher price. Although ticket scalping may increase the efficiency of the sales process by mimicking dynamic pricing [5,37], it is generally regarded as unfair both by customers who observe tickets that were previously affordable being sold at prices that are (far) beyond their budget, and by vendors whose potential profits are seized by another entity [5]. Ticket scalping is non-trivial to avoid in a decentralized marketplace because the entities who make purchases are pseudonymous. For example, restricting the number of tickets sold to a single entity does not solve the problem, because the scalper can trivially create a multitude of different accounts. Furthermore, because each account is pseudonymous, it is unclear whether the customer who attends the event paid the original price for the ticket, or bought the keys to the ticket for a higher price at an external marketplace.
To address ticket scalping, we use the existence of dedicated blockchains that contain identity information to link ticket purchases to digital identities. These blockchains are typically different from the ones on which the ticket is sold and/or the payment is made, so this is necessarily a crosschain challenge. In particular, as part of the function call that initiates the ticket purchase, the customer must also submit a DID. When the ticket is shown at the event, the customer reveals their name and/or any other associated information using an ID card, to match the same as linked in the DID, thwarting large-scale systematic ticket scalping.

Sybil-Resistant Reputations
As discussed in Section 2.4, reputation systems that allow users to rate their interactions with vendors may enhance their trust in the marketplace. One challenge in a reputation system is that a vendor may create Sybil accounts to boost its reputation or hurt its competitors' through dishonest feedback. Centralized systems can link each customer or vendor account to a credit card, making large-scale Sybil attacks impractical. However, in a fully decentralized anonymous marketplace, such an approach is impossible by design.
To address the challenge of Sybil attacks, we use DIDs to provide an analogous defense mechanism as a centralized marketplace. In particular, vendors who list an item can include a reputation metric signed by a cross-chain service, such that feedback is included in the metric only if it was issued by a customer who meets certain attributes, such as inclusion on a ledger maintained by trusted (e.g., government) organizations. Although this does not protect against Sybil attacks completely (e.g., a vendor could still ask family members or friends to give favorable feedback) it emulates the level of protection of centralized systems.

The BlockChain I/O Framework
In this section, we describe BlockChain I/O's core architecture and its main components. In Section 5, we furthermore discuss how these core modules integrate with a decentralized digital identity (DID) system. Figure 2 visualizes the different entities and their interactions, and the different types of smart contracts on each chain.

System Components
Blockchains (BCs). In our setting, there are multiple independent blockchains, and each of them supports its own set of tokens, including the native token (e.g., Ethereum's ETH token) and user-created tokens (e.g., Ethereum's ERC-20 tokens and NFTs). We assume that all blockchains support smart contracts and use the account model for native token balances. 4 Independent blockchains are not designed to interoperate inherently, i.e., a smart contract on one blockchain cannot use information from another blockchain without a cross-chain communication and coordination framework.
Cross-Chain Services (CC-SVCs). In BlockChain I/O, we use the PieChain framework for communication between the underlying blockchains. In PieChain, information is relayed between blockchains by CC-SVCs, which are entities that use full nodes or light clients to detect eventsi.e., interactions with BlockChain I/O smart contracts. Detected events are written to an event log -in PieChain, Apache Kafka is used for this purpose. Users and CC-SVCs can subscribe to events and hence track the interactions with BlockChain I/O contracts across the supported blockchains.
If CC-SVCs or the event log are compromised, then users are not at risk of having tokens stolen or frozen permanently. CC-SVCs can delay the conclusion of cross-chain deals, or misrepresent digital identities, but they are disincentivized from doing so by auditors, which we discuss in more detail below. As the same is true for the messaging service, we choose a performance-oriented solution -i.e., Kafka -instead of a security-oriented one such as a private blockchain. The rarity of misbehavior in Ethereum's block proposal market [21] empirically supports the assumption that relay services are sufficiently disincentivized by reputation damage in practice.
Stablecoins. Stablecoins are tokens whose value is pegged to a real-world asset, e.g., the US dollar. The use of stablecoins for cross-chain deals minimizes the influence of token price fluctuations on users' valuation of the involved assets. For example, if a user were to bid on an auction item using bitcoins, then a sudden change of the bitcoin price could cause the user to reconsider whether winning would lead to an acceptable outcome and abort. Although such a change of heart cannot be ruled out entirely as other offline circumstances may change (e.g., the user's valuation of the item), the use of stablecoins mitigates one prominent source of uncertainty about the value of the involved tokens.
To enable stablecoins in BlockChain I/O, we use the design of CroCoDai [34] which relies on an optimized (to reduce volatility) portfolio of cryptoassets from multiple chains: customers who need stablecoins can buy them locally or deposit collateral tokens on supported chains. Collateral tokens are stored in dedicated smart contracts called vaults, and can be reclaimed at a later time by returning the stablecoins plus some interest. If price changes or interest cause the ratio of the collateral's value to the amount of created stablecoins to become too low, then the collateral can be liquidated through an auction. Information about price of the collateral tokens is provided to the vaults by price oracles (e.g., Chainlink or Uniswap contracts).
Stablecoins can be transferred between chains if approved by the governance layer. The governance layer also decides on changes in the system-level parameters, e.g., the interest rate or liquidation ratio. To receive input from the governance layer, supported blockchains have relay contracts that validate messages from the governance layer, e.g., by validating (group) signatures or a zero-knowledge proof-of-state.
DIDs. The pseudonyms of each user can be linked to a set of attributes that represent important information about the user's identity, e.g., her name, location, or age. We assume that this information itself is stored (typically in encrypted form) on blockchains, e.g., in an ID contract or using a dedicated data type. In BlockChain I/O, vendors can indicate during the specification of a cross-chain deal which attributes of potential customers must be submitted and what conditions must be met -e.g., to ensure that customers submit (a hash of) their full name to prevent ticket scalping, or have a sufficient record of activity to prevent Sybil attacks. To obtain a DID, which must be specific to a request to avoid replay attacks, a holder requests it from an issuer -next, it is validated by a verifier who signs the DID. The DID's signature can then be verified by the contracts that use it. As part of any cross-chain deal, the creator must specify which ID ledgers are trusted, and which CC-SVCs are trusted to act as verifiers. We discuss the design and integration of DIDs in BlockChain I/O in more detail in Section 5.
Governance Chain. This is a special blockchain on which nodes who monitor the underlying blockchains are present -this can be an existing blockchain. The main role is to vote on changes to system-level parameters (especially for the stablecoin) and to verify claims of misbehavior by CC-SVCs.

Auditors. Misbehavior/abuse by CC-SVCs is detected by BlockChain I/O users called auditors.
Since the CC-SVCs' actions are entirely restricted to blockchain actions, misbehavior is provable to entities who have a view of the different blockchains. We identify three main types of misbehavior by CC-SVCs: i) not concluding a cross-chain deal faithfully (e.g., not awarding an auction's item to the highest bidder), ii) causing a cross-chain deal to abort by failing to forward messages, and iii) misrepresenting the reputation or attributes of customers or vendors. Upon detecting misbehavior by a CC-SVC, an auditor can submit a claim of misbehavior to a smart contract on the governance chain. If the claim is invalid, then the auditor loses a small deposit, but if it is valid, the CC-SVC suffers a reputation penalty, which hampers the prospects of the CC-SVC being used in the future.
Smart Contracts. As depicted in Figure 2, each blockchain contains five main types of smart contracts: the coin and vault contracts for the stablecoin, the relay contract to receive input from the governance layer, and possibly an IDs contract to store DID information. Finally, a blockchain would also have one or more app contracts to implement applications on top of BlockChain I/O-in Section 6, we give an example of such an application, namely a decentralized marketplace.

System Requirements
A platform for cross-chain commerce should satisfy the following requirements.
(1) Atomicity. Users who send tokens as part of a deal also receive all of the tokens agreed in the same deal. (1) Pseudonymity. The only information about users that is revealed by the protocol is a link to a persistent pseudonym, and whether the pseudonym meets the attributes required for the trade. (3) Stablecoin support. Tokens that users need to purchase to participate in the trades are pegged to realworld currencies, to ensure that they are not exposed to price fluctuations. (4) General Applicability. The system should be able to support real-world use cases and be able to support all existing blockchains by adding smart contracts.
Ledgers of ledgers such as Polkadot or Cosmos do not satisfy (4) because they only support their own sidechains or parachains, and can therefore not be integrated with existing blockchains through the addition of smart contracts. Hyperledger AnonCreds, CroCoDai, and PieChain respectively satisfy (2), (3), and (4), but not the others. BlockChain I/O satisfies (1) by using the framework of cross-chain deals [23], which ensures safety -user tokens cannot be stolen or lost -and therefore the atomicity property defined above. To show that BlockChain I/O supports (2), we present its integration with DID support in Section 5. BlockChain I/O supports stablecoins through its integration with CroCoDai. To demonstrate that BlockChain I/O satisfies (4), we discuss in Section 6 a decentralized marketplace that enables the use-cases presented in Section 3. In Section 7, we empirically evaluate a proof-of-concept implementation of this marketplace that incorporates two blockchains that are EVM-compliant (private Ethereum and Quorum) and one that is not (Hyperledger Fabric), and find that its computation times and gas fees are reasonable.

Entities
We leverage the zero-knowledge proofs [26] based Hyperledger AnonCreds [24] for decentralized Digital Identities (DIDs). The logical entities involved in the process of creating and verifying DIDs are as follows.
Holder: Any entity which is trying to establish its credentials can be a holder -e.g., in the cross-chain marketplace, this would typically be a vendor or bidder.
Issuer: Issuers are entities who are responsible for generating valid schema and credential definitions for holders. In cross-chain applications, they may be any pre-specified trusted organization. Issuers themselves are identified using so-called issuer identifiers, which are a form of DIDs. Accommodating arbitrary entities as issuers makes the approach decentralized -in effect, issuers have an analogous role to that of certificate authorities in the Web PKI, and DIDs and issuer identifiers can be seen as the analogues of end-entity and intermediate certificates.
Verifier: The verifier communicates with the VDR for each action and with the "Registration Smart Contract" (RSC) module of PieChain where the verifier is notified through an event listing action. The verifier validates the schema identity, credential definition identity, and the DID of the respective holder, and forwards an ECDSA (Elliptic Curve Digital Signature Algorithm) based signed hashed transaction that indicates validation of the DID, along with VC information, to the RSC for acceptance or rejection of the respective holder.
Verifiable data registry (VDR): Hyperledger AnonCreds is used as a VDR to verify and store the DIDs, schema information, credential definition identity, revocation list for future reference and validation of VCs.
Registration Smart Contract (RSC): This module realizes the integration of AnonCreds with BlockChain I/O and is used to communicate with the credential holders or verifiers. It validates the DID, 160-bit hashed address information and VC of the holder during registration and validates the signed hashed information regarding the holder received from the verifier. Figure 3 depicts the interactions, which, in effect, also require cross-chain communication given that AnonCreds itself is built using the Hyperledger framework.

DID Creation
For generation of pseudonym DIDs, the issuer first has to determine the schema and credential definition for the holder (which can be reused for many users/holders when suitable). To generate credentials, the issuer also has to be verified using its issuer identifier. In this regard, both the issuer and verifier first forward their requests to the system pool to obtain their identifiers, verification keys, and roles as Trust Anchor or Trustee respectively. After obtaining a suitable role (Trust Anchor), the issuer requests AnonCreds VDR to generate the schema of the holder based on some secret credentials provided by the holder using a predefined reusable template. As a response, a schema ID is returned by Anon-Creds VDR. Using this schema ID, the issuer requests the credential definition alongside other information like tag  values and type and revocation information for the schema. Next, a DID is generated internally by the verifier. After getting credential definition information from AnonCreds, the issuer forwards it to the holder. Later on, the holder requests verification of the DID against the credential definition. However, based on validation of such information, the verifier either forwards the DID and credential definition -in a 32bit encrypted format called the canonicalization format -to the holder if the schema is valid (after getting confirmation from AnonCreds), otherwise it rejects the request.

DID Verification
A conversion mechanism is maintained by the verifier for adaptation of information from the canonicalization format to ECDSA-based signed information while communicating with PieChain via the RSC. So, after obtaining the DID and credential definition from the holder as a request to interact with other elements of BlockChain I/O and the cross-chain marketplace, it is first forwarded to the RSC along with a 160bit hashed address of the holder. It is then further validated by the RSC (in turn communicating with the validator and the VDR) against the information maintained by the Anon-Creds schema and VCs. If the holder is valid, only then the respective credentials are forwarded along with the DID to the RSC to grant the holder access for further communication with PieChain, otherwise the request is rejected.

Decentralized Marketplace
In this section, we present a decentralized marketplace built on top of the BlockChain I/O infrastructure described in Sections 4 and 5. We discuss both the core design of the marketplace, as well as the smart contract implementation. We then explain how to implement the two use cases from Section 3, and how auditors detect abuse by CC-SVCs.

Overview
Users. The marketplace has the following types of users.
• Bidders who hold crypto tokens and who are interested in purchasing listed tokens. • Vendors who want to sell tokens, and who seek to exchange them for (other) crypto tokens.
In addition, the core user types of BlockChain I/O, i.e., CC-SVCs, auditors, and governance token holders, also participate in the marketplace.

Listings.
A listing represents an intent to sell equivalent tokens -these can be same-sized batches of cryptocurrencies, or NFTs that represent identical goods. Each listing belongs to one of the following types (see also Section 2. which the parties who transfer tokens vote to commit if agreeable. Upon commitment or abortion, the tokens are transferred or returned to the intended users. If an exchange is aborted because a user neglects to commit or reveal, then this user loses the abort penalty. 4. Feedback. If the token represents physical items whose quality cannot be determined unambiguously, users may provide feedback on the other users -e.g., to indicate their opinion of the speed of delivery, whether the item matched the description, etc.
Events. The following types of events are recorded by the CC-SVCs: 1. AuctionCreatingEvent, emitted after a new listing has been created, 2. BiddingAuctionEvent, emitted after a new bid has been created, and 3. AuctionEndingEvent, emitted after a listing has been concluded.

Smart Contract Specification
Listings are processed through a single market smart contract, which is a type of app contract as depicted in Figure 2.
In the following, we first describe the smart contract's core functions, and then discuss how they are integrated with DID support in Section 6.3. createListing. Takes as input a start timer, a reveal timer, a conclusion timer, a feedback timer, CC-SVC addresses, a listing type, and an initial/fixed price. If successful, creates an entry for the listing using a hashmap in the market contract.
bidFixed. Takes as input a listing ID. If the listing has the 'fixed' type, the current time is between the start and conclusion timers, and the sender has enough stablecoins in her wallet, then a bid is recorded, and an amount of stablecoins equal to the listing's fixed price is transferred to the marketplace smart contract for escrow.
bidOpen. Takes as input a listing ID and bid value. If the listing has the 'open' type the current time is between the start and conclusion timers, the value is greater than the previous highest bid and the listing's starting price for an increasing-price auction (or if it is the first bid in a decreasingprice auction), and the sender has enough stablecoins in her wallet, then a bid is recorded, and an amount of stablecoin equal to the bid value is transferred to the marketplace smart contract for escrow.
bidSealed. Takes as input a listing ID and bid hash. If the listing has the 'sealed' type, the current time is between the start and reveal timers, and the sender has enough stablecoins in her wallet to pay the abort fee, then a tentative bid is recorded, and an amount of stablecoins equal to abort fee is transferred to the marketplace smart contract for escrow.
revealBid. Takes as input a listing ID and bid value. If the listing has the 'sealed' type, the current time is between the reveal and conclusion timers, the hash of the value equals the hash stored through bidSealed, the sender has enough stablecoins in its wallet to pay the value minus the already escrowed abort fee, then a bid is recorded, and an amount of stablecoins equal to the bid value is transferred to the marketplace smart contract for escrow.
concludeListing. Takes as input a listing ID and a number of winners. If sent by the cross-chain service, and the current time is between the conclusion and feedback timers, then the auction is concluded. If the auction has not been concluded before the feedback timer, then it is aborted and all tokens in escrow are returned.
giveFeedback. Takes as input a listing ID and a bid ID. If the auction has been concluded and the current time is between the conclusion and feedback timers, then the user's feedback is recorded in the contract.

Use Cases
The two use cases of Section 3 can be implemented by combining DIDs with the smart contract discussed in Section 6.2 in the following way. For the first use case (i.e., mitigating ticket scalping), each bidder who calls the bidFixed, bidOpen, or bidSealed function also includes a DID that contains a hash of personal identifying information, e.g., the bidder's full name. When redeeming the ticket, the ticket owner can then reveal that it was indeed her who issued the winning bid. For the second use case (i.e., a reputation system that is resilient against Sybil attacks), a vendor includes an aggregate feedback score (signed by a CC-SVC who acts as a verifier) when creating a new auction.

Audits
In the marketplace, CC-SVCs are relied on for faithfully concluding an auction through the concludeListing function, and for signing DIDs for personal identifying information and for the feedback aggregates. If they misbehave in any of these roles, then this is detectable by auditors and governance token holders. In particular, if they misrepresent an auction outcome, then a higher bid must exist on a chain than the one that was declared the winner. An auditor can send a proof of the existence of this bid to the governance chain, upon which a reputation penalty can be administrated to the CC-SVC. Similarly, if a CC-SVC has misrepresented a DID or reputation aggregate, then this can be demonstrated to the governance chain. This creates necessary checks and balances to ensure that end-users can identity and isolate misbehaving CC-SVCs, thus creating a mechanism to satisfy the implicit trust assumptions in PieChain's design.

Experiments
In this section, we present our experimental results, demonstrating that the marketplace built using BlockChain I/O (as discussed in Section 6) has practical performance. We focus on the elements that are common between all use cases -i.e., creating and processing a listing on multiple blockchains.

Experimental Set-Up
We use an iMac with an i9-10900k CPU to simulate an experimental environment with local test networks for Ethereum, Quorum, and Fabric. For the stablecoin, we use a modified version of the Dai stablecoin for coin transfers based on the coin and relay contracts from [34].

Results
In this section, we estimate the time duration and gas cost of each phase in the processing of a listing. We consider an increasing-bid open auction, in which the main steps are as follows: 1. the auctioneer creates the listing through a call to addAsset from an Asset contract, which is deployed on the Fabric network, 2. upon detecting an addAsset call, the CC-SVC subsequently deploys an Auction contract on both the Ethereum and Quorum platforms, and publishes an AuctionCreatingEvent to our event logging system hosted by Kafka, 3. users place bids for the listing by making calls to either bid or bidClosed, which are revealed at a later stage (only for the closed auction), 4. the CC-SVC detects that bidding activity has been accomplished by a successful coin transfer and then publishes a corresponding BiddingAuctionEvent on Kafka for logging purposes, 5. after a specified period, the auctioneer may actively conclude the listing by invoking an endAuction call to the Asset contract on Fabric. Alternatively, this action can be automatically triggered when the auction reaches its predetermined conclusion time, 6. once such a state change has been caught by the CC-SVC, it changes the state of the Auction contracts on both Ethereum and Quorum into ending -which means that they await further action from the user -and logs this activity as an Auctio-nEndingEvent, 7. the user who has placed the highest bid across all platforms (in our case, Ethereum and Quorum) has the choice to either commit or abort the auction result, 8. the CC-SVC forwards the winning user's response to the Asset contract on the Fabric, then either returns or collects the coins transferred by the user in the previous stage, 9. if the related event AuctionResponse has been posted by one CC-SVC and received by Kafka, the CC-SVC transfers the asset from the auctioneer to the winning bidder. Taking a simple increasing-bid open auction as an example, the time and gas costs of these steps are displayed in Table 1. We observe reasonable time costs: each step takes fewer than 10 seconds, whereas an auction would typically run for more than a day. Furthermore, a bid costs ≈130000 gas, which at current gas prices (≈16 GWei) would cost $3.75 USD on Ethereum's main chain, but typically (much) less on other EVM-compliant chains (enabling bids on smaller chains is a core motivation for BlockChain I/O).

Conclusions
We have presented BlockChain I/O, a framework for crosschain commerce. It satisfies the essential properties of transaction atomicity, pseudonymity, stablecoin support, and general applicability. We have demonstrated its versatility by creating a decentralized marketplace built on top of BlockChain I/O, hosting a variety of application use-cases. We validated our proof-of-concept implementation for functional correctness and by benchmarking the overheads to demonstrate the practicality of the BlockChain I/O framework.