# An agnostic and secure interoperability protocol for seamless asset movement

El-Hacen Diallo, Mohameden Dieye, Omar Dib, Pierre Valiorgue

► To cite this version:

El-Hacen Diallo, Mohameden Dieye, Omar Dib, Pierre Valiorgue. An agnostic and secure interoperability protocol for seamless asset movement. Journal of Network and Computer Applications (JNCA), 2024, 230, pp.103930. 10.1016/j.jnca.2024.103930. hal-05451144

HAL Id: hal-05451144

https://hal.science/hal-05451144v1

Submitted on 23 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
Research paper

# An agnostic and secure interoperability protocol for seamless asset movement

El-hacen Diallo<sup>a,d,*</sup>, Mohameden Dieye<sup>b,d</sup>, Omar Dib<sup>c</sup>, Pierre Valiorgue<sup>d</sup>

<figure><img src="image_2.png" /></figure>

## ARTICLE INFO

**Keywords:**

Blockchain interoperability

Cross-chain communication

Assets movement

Incentive smart contract

Zero-Knowledge Proofs (ZKP)

## ABSTRACT

As blockchain technology continues to evolve, it has fostered an extensive ecosystem of applications and platforms. This dynamic landscape is characterized by a myriad of innovative solutions, ranging from decentralized finance and supply chain management to digital identity and voting systems, each contributing to the ongoing advancement and adoption of blockchain technology across various sectors. Achieving interoperability among these applications and platforms poses a significant challenge due to their use of distinct protocols, and remains a bottleneck hindering the widespread adoption of blockchain technologies. Addressing this challenge requires designing a universal interoperability protocol while ensuring compliance with the security and privacy constraints specific to each blockchain, thus adding complexity. We propose an agnostic interoperability protocol designed for seamless asset movement across independent private blockchain networks, regardless of their individual protocols. This protocol leverages incentive-driven smart contract and Zero-Knowledge Proofs to establish a decentralized, secure, and privacy-focused framework for interoperability. We conduct a security analysis using game theory and provide both theoretical and empirical evaluations of the protocol end-to-end delay. Through a comprehensive use case, we demonstrate the secure deployment of the proposed protocol for asset movement between two private blockchains. We also discuss the trade-offs between cost and delay in cross-blockchain transactions. Furthermore, a comparative analysis with existing interoperability schemes showcases the proposed interoperability scheme superiority in terms of robustness, privacy preservation, and verifiability.

## 1. Introduction

Distributed Ledger Technology (DLT) has gained substantial recognition across academia and industry as the foundational technology for decentralized applications and cryptocurrencies. Its unique ability to facilitate decentralized governance and services has propelled its adoption across a spectrum of sectors such as finance, logistics, healthcare, education, social media, and entertainment (Abou Jaoude and Saade, 2019). As a key enabler, blockchain technology is orchestrating a revolutionary transition towards Web3. Web3 constitutes a decentralized internet that empowers users with control and ownership of their properties. In this paradigm, individuals are not merely consumers but active participants, with the ability to securely manage, transact, and interact with their digital properties without reliance on centralized authorities. This shift towards user-centricity marks a new era of digital

empowerment, fostering trust, transparency, and inclusivity in the online ecosystem. While Web1 operates in a read-only manner and Web2 offers read-write capabilities, Web3 advances to the concept of read-write-own,<fnref n="1" /> thereby eliminating censorship and facilitating seamless user migration across platforms with their assets.

Within the Web3 paradigm, it is crucial to enable the exchange of assets and data across different blockchain networks to enhance user experience and widen the scope of decentralized applications (dApps) (Murray et al., 2022). However, the broader adoption of blockchain technology is hindered by interoperability limitations (Wang, 2021; Belchior et al., 2022). Existing blockchain platforms operate in isolation, managing their digital assets independently. Unfortunately, the scope of these assets remains restricted and fails to

<footnote><sup>a</sup> Université Paris-Saclay, CNRS, LISN, Gif-sur-Yvette, France</footnote>

<footnote><sup>b</sup> Université Polytechnique Haut-De-France, (UPHF), Valenciennes, France</footnote>

<footnote><sup>c</sup> Wenzhou-kean University, Wenzhou, China</footnote>

<footnote><sup>d</sup> Université Claude Bernard Lyon 1 (UCBL), Villeurbanne, France</footnote>

<footnote>* Corresponding author at: Université Paris-Saclay, CNRS, LISN, Gif-sur-Yvette, France.</footnote>

<footnote>E-mail addresses: diallo@lisn.fr (E.-h. Diallo), Mohameden.Dieye@uphf.fr (M. Dieye), odib@kean.edu (O. Dib), pierre.valiorgue@univ-lyon1.fr (P. Valiorgue).</footnote>

<footnote n="1">¹ https://ethereum.org/en/web3/, accessed: April 30, 2024.</footnote>
transcend the confines of their respective networks. Given the historical development of the Internet and the diversity of blockchain applications, the emergence of a single and dominant global blockchain appears unlikely (Belchior et al., 2022; Wang et al., 2023a). In a universe of fragmented blockchain platforms, the capability to transfer assets, conduct payments, and exchange information across them is necessary (Buterin, 2016).

For example, in the decentralized social media landscape, a content creator and influencer on platform A, who has built a substantial following and earned a strong reputation as a credible and engaging content provider, can move to platform B without starting from zero, thanks to blockchain interoperability. This interoperability allows users to transition seamlessly from one platform to another, carrying over their reputation, followers, and digital assets, thereby enabling them to communicate and engage with a new audience immediately. Blockchain interoperability not only enhances user experience by preserving their digital identity and achievements across platforms but also fosters a more connected and dynamic decentralized ecosystem where users have the freedom to explore and grow without barriers.

An additional instance highlighting the significance of interoperability arises within the decentralized finance (DeFi) ecosystem. Imagine an investor actively engaged in providing liquidity on one decentralized exchange (DEX), accumulating a notable reputation and capital over time. With blockchain interoperability, they can seamlessly transfer their assets and liquidity positions to another DEX, safeguarding their investment history and reputation. This not only eliminates the need to start afresh but also ensures the security, traceability, and verifiability of the transaction. Empowered by interoperability, the investor can swiftly explore alternative liquidity pools and trading opportunities while maintaining trust and integrity in the decentralized financial landscape.

Blockchains interoperability necessitates the seamless communication, sharing, and access of assets across different blockchain networks while upholding principles of transparency, security, and privacy preservation (Buterin, 2016; Ou et al., 2022). That is known as cross-chain communication and is a pivotal component contributing to the maturation of blockchain technology (Ou et al., 2022). In blockchain systems, data validation requires the blockchain current state and historical records. Thus, the validation of external data from a different blockchain is challenging. A robust blockchain interoperability protocol must ensure the ACID (atomicity, consistency, isolation, and durability) properties for cross-chain transactions, safeguard the integrity of shared data, and ensure resilience against adversarial attempts such as double-spending, which could introduce inconsistencies across networks. These requirements must be satisfied within a trustless and decentralized environment (Herlihy, 2018; Ou et al., 2022).

Therefore, designing a secure, efficient, and agnostic cross-chain communication protocols have gained a particular attention (Wang, 2021; Belchior et al., 2021; Robinson, 2021; Pillai et al., 2022). Many existing protocols have primarily concentrated on atomic swaps—enabling the exchange of tokens between users across distinct public blockchains (Belchior et al., 2021). However, it is essential to recognize that blockchain interoperability encompasses a broader spectrum, necessitating separate consideration for various scenarios with specific requirements. This includes scenarios where blockchains with different privacy standards must cohesively interoperate (Kotey et al., 2023). In light of this, our investigation delves into the interoperability of private blockchains to shed light on potential privacy-related challenges.

Private blockchains provide a unique blend of cooperation and control that distinguishes them from their public counterparts. However, this level of oversight does not shield them from the potential for dishonest behavior among the organization that participate. The underlying issue stems from the competitive dynamics among these participants, which vie for market share, profits, and strategic positioning. This competition is a real motivation for engaging in malicious practices to secure a competitive edge. Furthermore, the interaction

between two independent private blockchains introduces heightened risks of malicious activity. The issuance of false claims by a source blockchain might not directly affect its own standing but could undermine the receiving blockchain network. Such dishonest actions can have serious consequences, including the validation of incorrect data or fraudulent transactions. This not only compromises the integrity and security of the interoperability mechanism but also diminishes trust within the broader blockchain ecosystem.

Numerous efforts toward achieving interoperability among private blockchains have been undertaken. These efforts predominantly leverage a gateway-based architecture, as initially proposed by Hardjono et al. (2019). This innovative architecture integrates gateways to provide interoperability services directly to blockchain validators. Building on this foundational concept, subsequent research, such as that conducted by Bradach et al. (2022), has relied upon the gateway-based model for the sharing of governmental information across continental blockchains. Moreover, Wang and Nixon (2021) have further enhanced the security of this architecture by implementing a threshold signature scheme, thereby refining the original framework proposed by Hardjono et al. (2019).

Despite these advancements, the proposed protocols have faced challenges in preventing dishonest gateways from propagating false claims across blockchains. To address this issue, a robust interoperability scheme should be capable of incorporating untrustworthy participants. Such a scheme should also ensure stringent verifiability for the destination blockchain while maintaining the principles of decentralization and protecting user privacy.

Therefore, in this work, we introduce a robust interoperability protocol that is both resilient and privacy-conscious, facilitating the seamless migration of assets between distinct blockchains without involving a trusted third party. This protocol is specifically designed to demonstrate resilience against malicious gateways that may propagate misleading or false assertions. The foundational approach of our protocol leverages Zero-Knowledge Proofs (ZKP) to bolster participant anonymity, safeguard against collusion attacks, and maintain the integrity of user-gateway interactions. Moreover, we introduce an incentive-driven smart contract scheme, strategically implemented to promote and reward honest conduct throughout the interoperability process.

The remainder of this paper is organized as follows: Section 2 reviews relevant literature. Section 3 outlines the main contributions. Section 4 describes the proposed interoperability protocol in detail. Section 5 focuses on the protocol's security analysis and delay evaluation. Section 6 presents a practical use case and assesses protocol delay under various scenarios. Finally, Section 7 concludes the paper and discusses potential future research directions.

## 2. Related works

This section presents related works, beginning with a discussion of evolving authentication protocols for decentralization systems. Subsequently, it delves into existing schemes for trustless blockchain interoperability, concluding with an overview of the state of the art in private blockchains.

### 2.1. Evolving authentication protocols

Different security protocols have been developed to enhance user authentication security in digital systems. For example, Two-Factor Authentication (2FA) protocols have been proposed to add an additional layer of defense against unauthorized access (Wang et al., 2023b; Wang and Wang, 2018). However, 2FA systems, particularly those relying on SMS or emails, expose user information during the transmission process. This can allow unauthorized users to access sensitive data such as phone numbers or email addresses, potentially linking to the user identity, which is a significant concern for the
proposed interoperability solution. Indeed, the users' identities must remain private and protected, ensuring that no personal information is revealed during the authentication process. This measure is crucial in an interoperability context as it helps mitigate the potential for collusion among actors within the interoperability scheme to compromise the system. Moreover, traditional 2FA protocols, in their classical form, are incompatible with the decentralized nature of blockchain platforms and their interoperability. These methods typically rely on centralized servers to store and verify user credentials, contradicting the fundamental decentralization principle of blockchain technology (Tsague et al., 2018).

To enhance anonymity during the authentication process, Jia et al. (2022) proposed a more privacy-aware 2FA method. This approach ensures that user and device identities remain anonymous and untraceable. It uses pseudo-identities and dynamic identities that are not directly linked to real-world identities, hence providing higher levels of privacy. Additionally, all authentication activities are recorded on a decentralized blockchain, eliminating the need for a central authority. Despite its privacy enhancements and decentralized nature, this approach involves multiple steps that require interaction between different entities. This limits its adaptability in an interoperability context, especially in cases where non-interactive communication is required.

To uphold the highest standards of privacy in authenticating different entities involved in the interoperability scheme, we opted to employ ZKP to protect user confidentiality. With ZKP, no information about the user is exposed, even in an anonymized form. The use of ZKP is also justified by its compatibility with decentralized environments, allowing for non-interactive authentication and thus improving its suitability for interoperability use cases, and minimizing the cost of transactions on the blockchain.

## 2.2. Zero-Knowledge Proofs (ZKP)

The concept of zero-knowledge was first introduced by Goldwasser et al. (2019) in 1989. It is a cryptographic construct that establishes the veracity of a claim while abstaining from divulging any supplementary information (Goldreich, 2002). Recently, ZKP techniques have seen tremendous interest with the prominence of blockchain technology and the crucial need for privacy in existing blockchain platforms. Due to the privacy-preserving capability of ZKP, they have emerged as a must-implement solution in the DLT world. By leveraging ZKP, participants within blockchain ecosystems can now assert their claims while preserving their anonymity (Čapko et al., 2022). This attribute has become an indispensable requisite in any interoperability protocol. There are two types of ZKP: interactive and non-interactive schemes (Goldreich, 2002). The non-interact ZKP protocols are the most suitable for most applications, as they remove the need for the prover and verifier to interact repeatedly. Examples of non-interactive ZKP protocols are zk-SNARK, Bulletproofs, zk-STARK, and NIZK (Čapko et al., 2022; Hao, 2017).

Within this study, ZKPs confer verifiability while maintaining anonymity between participants engaged in the interoperability process. This helps hide users' and interoperability gateways' identities, thereby preempting potential collusion attacks and their subsequent adversarial implications, including falsified interoperability proofs.

## 2.3. Trustless blockchain interoperability schemes

There are various blockchain interoperability solutions. Most are designed for value transfer from one public account to another on a different blockchain. Existing solutions can be classified into three broad categories (Robinson, 2021; Pillai et al., 2022): trusted, semi-trusted, and trustless schemes. Trusted schemes, also called notary schemes, rely on a third-party entity that acts as a trusted intermediary. Semi-trusted schemes rely on a trusted group that cooperatively signs and validates the claims of the source blockchain. Finally, we have trustless

schemes where no intermediary exists in the interoperability process. In these schemes, the destination blockchain must be able to verify claims from the source blockchain. We distinguish two general approaches for the trustless schemes: relays and Hashed Time-Lock Contracts (HTCL) techniques. The former ensures cross-chain communication by enabling the destination blockchain to connect to the source blockchain as a light client. Knowing the consensus rules, a light client can verify the blockchain state (e.g., to check whether a transaction exists in the blockchain) through block metadata and Merkle roots. HTCL does not require sharing block metadata. Instead, it requires participants to observe the state of smart contracts locked on the interacting blockchains until specific conditions are met or timeout is reached.

### 2.3.1. Relays

Relaying has emerged as the underlying concept behind sidechains. Sidechains, known as blockchain layer-2 scaling solutions, were primarily proposed to scale public blockchains. They also enable extending existing blockchain functionalities without significantly changing the blockchain protocol. By definition, a sidechain is a secondary blockchain steering on (or pegged to) the main blockchain, allowing the movement of tokens between the two chains (Johnson et al., 2019). Note that sidechains are separate blockchains with their validators/miners, consensus rules, and sometimes own tokens, but they must permanently store the state of the main chain (Singh et al., 2020). The communication between these two distinct blockchain networks is achieved through relays. Generally, smart contracts are hosted on the sidechain with Simple Payment Verification (SPV) (Anon, 2021a) capability over the main chain. A prominent example of relays is BTCPelay (Anon, 2021c), which relays Bitcoin blocks on the Ethereum blockchain.

Relays establish trustless cross-chain communication using smart contracts equipped with Simplified Payment Verification (SPV) capabilities. However, for effective utilization, the destination blockchain must be familiar with the consensus rules of the source blockchain. If the source blockchain relies on a voting-based consensus like Tendermint (Buchman, 2016), validators' identities and voting power must be shared with the destination blockchain. This sharing ensures transparent block metadata verification. Nonetheless, this constraint weaken the agnostic nature of relays as an interoperability solution and their adaptability to consensus changes, such as capturing updates in validators set. Moreover, *relaying* is resource-intensive, demanding miners to continuously verify and store the metadata of interconnected blockchains while maintaining their chains. To alleviate this burden, Cosmos (Kwon and Buchman, 2019) introduced blockchain hubs, which minimize the number of blockchains needing relays by allowing them to connect to a single public hub blockchain. However, this approach compromises the decentralization of interoperability, as each hub acts as a central point through which all blockchain communications pass. Additionally, privacy concerns may emerge when two private blockchains communicate, necessitating special attention. Lastly, public hubs require the maintenance of an entirely new blockchain network, making it costly.

### 2.3.2. Hashed Time-Lock Contract (HTLC)

HTLC (Hashed Time-Lock Contract) is a trustless technique that facilitates blockchain interoperability, particularly notable for its application in cryptocurrency exchanges like *atomic swaps* between users of different blockchains. This approach necessitates users to have access to and accounts in each relevant blockchain (Herlihy, 2018). For instance, envision Bob and Alice, both seeking to exchange their assets (X from blockchain A for Bob and Y from blockchain B for Alice) using HTLC. The process initiates with Bob generating a secret key S and deploying a smart contract (SC<sub>bob</sub>) on blockchain A. This contract stipulates that if S is unveiled within a specified timeout T, asset X transfers to Alice's account; otherwise, it returns to Bob. Subsequently, upon observing SC<sub>bob</sub>, Alice creates her smart contract (SC<sub>alice</sub>) on blockchain B, which
locks her asset with rules dictating that if S is disclosed within a shorter
timeframe $T'$ ($T' < T$), asset Y is sent to Bob; otherwise, it returns to
her.

HTLC facilitates direct asset transfers between accounts without an
intermediary (Anon, 2021b). Nevertheless, its effectiveness in achiev-
ing cross-chain interoperability is constrained by certain limitations.
Notably, users must deploy at least one smart contract on both the
source and target blockchains. This becomes problematic in private
blockchains, where user access to the target blockchain may be re-
stricted, making the execution of HTLC challenging.

To eliminate the need for users to have direct access and accounts on
every blockchain, connectors were introduced as intermediaries using
the Interledger Protocol (ILP) (Thomas and Schwartz, 2015). These
connectors are designed to be trustless and can monitor the state of
Hashed Time-Lock Contracts (HTLCs) while managing routing between
sender and receiver addresses. When a connector observes an asset
being locked on the source blockchain, it sets aside an equivalent
amount on the destination blockchain. Once the recipient fulfills the
conditions for unlocking the funds (such as HTLC terms), they provide
proof to the connector to claim their payment. The connector then uses
the proofs to request payment from the sender. ILP ensures atomicity,
meaning that the payment is rolled back if one party terminates the
process or a timeout occurs.

## 2.4. Interoperability between private blockchains

Numerous endeavors have been undertaken to formulate interoperability protocols tailored for private blockchains. For instance, Bu et al. (2020) introduced an intercommunication approach for two separate Hyperledger networks. Their methodology involved an announcement message to relay the transaction status, simulated and validated in the source blockchain, to the target blockchain. Subsequently, if the transaction gains confirmation within the destination blockchain, the corresponding client is notified of the outcome. Conversely, if confirmation is not achieved, an initiated rollback process is set in motion to reimburse the transaction initiator (Bu et al., 2020).

In line with the design philosophy of the Internet, Hardjono et al. (2019) proposed an architecture for achieving interoperability among private blockchains. They conceptualized blockchain networks as self-governing systems with defined routing policies and categorized blockchain nodes as intradomains and interdomains, also known as gateways. Intradomains encompass consensus nodes responsible for maintaining and validating the blockchain, while interdomains handle cross-chain communications. To elucidate their approach, the authors presented a scenario involving user X residing in blockchain B1, possessing asset AS, who intends to transfer its legal ownership to another user Y in blockchain B2. Both B1 and B2 are private blockchains, necessitating a certain degree of confidentiality during interoperability. Importantly, B1 nodes cannot directly access B2, and vice versa. Their cross-chain protocol solution entails X initiating a transaction that transfers ownership of AS to Y. This transaction encompasses X's interdomain identity, facilitating B2 in authenticating X. Subsequently, a designated B1 gateway (e.g., G1) processes the transaction and establishes trust with a corresponding gateway in B2 (e.g., G2), leveraging Trusted Execution Environments (TEEs). Following gateway trust establishment, the transaction is presented to B2 for confirmation. Once confirmed, G2 provides a proof of the validated transaction without disclosing Y's local identity to G1. The final step involves updating the asset movement status within B1 (Hardjono et al., 2019).

In their subsequent work, Hardjono (2021) extended their prior
interoperability protocol (Hardjono et al., 2019) to emphasize gateway
identity management, asset movement atomicity, and gateway relia-
bility. Each gateway is operated by a Validator as a Service Provider
(VSP) with legal standing, and must possess three key pairs for distinct
purposes: intradomain transaction signing, cross-chain communication,
and hardware-bound identity. Their key innovation is the introduction

of an HTCL-based scheme enabling one-way atomic asset movement be-
tween private blockchains. They also addressed double-spending risk in
case of gateway crashes, suggesting solutions like backup gateways and
secure channel re-establishment. Nonetheless, the paper acknowledges
potential gateway misbehavior in disseminating inaccurate claims and
proofs.

Intertrust (Wang and Nixon, 2021) proposes an agnostic interoperability protocol, bolstered by a threshold signature scheme added to the gateway-based architecture in Hardjono et al. (2019). The protocol focuses on trusted services across distinct private blockchains, emphasizing atomicity in cross-chain communications through a two-phase commit (2PC) protocol. Intertrust employs a group of gateways, one acting as a leader, orchestrating the interoperability process. The number of gateways is defined during trust establishment among leader gateways, ensuring claims' validation by a consortium of validators. This stands, in contrast, to Hardjono (2021), which relies on the leader gateway alone. Intertrust enhances distributed and reliable claim/proof services between private blockchains yet acknowledges potential issues like leader gateways' single points of failure and the risk of disseminating incorrect claims. Notably, Intertrust assumes honest behavior from blockchain clients.

The prevailing proposals for blockchain interoperability heavily rely
on fully trusted gateways, facilitated predominantly through Trusted
Execution Environments (TEEs). However, this reliance is potentially
premature, given not only the financial implications but also the sus-
ceptibility of TEEs to various attacks and vulnerabilities that could
compromise their integrity (Cerdeira et al., 2020). This vulnerability
opens the door for dishonest gateways to act maliciously by dissemi-
nating false claims and evidence, undermining the security and trust in
the interoperability of blockchain networks.

As highlighted in Hardjono (2021), there have been efforts to
mitigate malicious behaviors of gateways. Yet, the proposed solu-
tions often involve the introduction of a third-party jurisprudence
blockchain, tasked with monitoring and recording gateway activities.
This approach, while offering a layer of oversight, still centralizes trust
to a significant degree, diverging from the decentralized spirit that
blockchain technology supports.

In response to these challenges, this paper proposes a more robust
and agnostic blockchain interoperability protocol. The goal is to over-
come the constraints of existing models by minimizing dependence on
the presumed security of TEEs, which are still evolving technologies.
Rather, we introduce an incentive mechanism to ensure honest behav-
ior among gateways. This approach is especially relevant for private
blockchains, where the pursuit of strategic advantages can encourage
dishonest behavior.

The proposed scheme enhances the security and reliability of cross-blockchain transactions, thereby mitigating malicious behavior from competitive entities. Consequently, it contributes to the broader goal of establishing a truly decentralized and secure Web.

## 3. Contributions

Various private blockchain interoperability protocols exist; however, specific security and privacy issues remain unaddressed. Privacy issues can lead to the corruption of participants once their personal information is exposed. There is a direct influence between privacy and the security of blockchain interoperability. An effective interoperability scheme must, therefore, tackle dishonest participants who may collude with gateways to generate false proofs, ensure high verifiability of interoperability proofs for trust in the destination blockchain, and fairly select honest interoperability service providers (gateways) for seamless participation. To address these concerns, this study proposes an agnostic, robust, and privacy-preserving interoperability protocol. It enables users to transfer assets between blockchains without relying on a trusted third party. The main contributions of this work are as follows:
<figure><img src="image_3.png" /><figcaption>Fig. 1. System components.</figcaption></figure>

* We propose an agnostic, robust, and privacy-preserving blockchain interoperability protocol. The proposal leverages ZKP cryptographic techniques and a smart contract incentive scheme to counter dishonest participants and prevent the sharing of incorrect proofs.

* By utilizing game theory, our protocol stands resilient against dishonest gateways and offers enhanced privacy and verifiability. This includes the production of unforgeable interoperability proofs, a distinct advantage over existing protocols. These proofs guarantee that interactions between interoperability participants remain transparent, secure, and tamper-proof, thereby ensuring the overall integrity of the interoperability scheme.

* We provide a comprehensive analysis of the protocol delay, considering delays arising from interacting blockchains' consensus mechanisms, ZKP schemes, and smart contract deployments, and invocations.

* Through a detailed use case, we provide clarity on the protocol's practical implementation and its step-by-step execution. This not only aids in estimating the theoretical complexity of the protocol but also offers valuable insights into its implementation intricacies.

* We conclude with a rigorous evaluation of our scheme, supported by comprehensive simulation results, ensuring the thorough assessment of its efficacy and performance.

# 4. Proposed interoperability scheme

This section outlines the proposed interoperability protocol, comprising two parts: the first introduces the system model, and the second details the protocol itself.

## 4.1. Model

In the following, we define the system components and entities involved in the proposed interoperability protocol. We also outline the security concerns and highlight the design objectives.

### 4.1.1. System components

The system under consideration comprises various entities: users, blockchain nodes, and gateways, as depicted in Fig. 1.

* **Users:** Are blockchain clients that can request to move from their current network to another blockchain network.

* **Blockchain nodes:** Are the conventional blockchain validators and maintainers. Their role encompass consensus orchestration and validation of the blockchain state.

* **Gateways:** Are blockchain nodes playing a pivotal role in managing the interoperability process. They operate as service providers, facilitating the exchange of assets between networks.

As illustrated in Fig. 1, the system model encompasses two blockchains, namely B1 and B2, denoting the source and destination blockchains, respectively. Each blockchain operates autonomously and is upheld by its own set of validators. Due to their private nature, gateways in B1 are unable to access or modify data in B2, and vice versa. Hence, gateways from B1 and B2 are compelled to establish a communication channel, essential for driving the interoperability protocol. Furthermore, these gateways must agree upon a payment platform that supports smart contracts.

### 4.1.2. Security assumptions

Each blockchain network is assumed to be independent and dominated by honest validators. The interacting blockchains are also supposed to achieve immediate consensus finality, as is generally the case in private blockchains. Furthermore, gateways are supposed to be rational and incentive-driven to maximize their profits.

### 4.1.3. Security threat

Two primary security threats are identified in our system:

* **User-Gateway collusion:** There is a risk that users and gateways may collaborate to craft deceptive proofs, potentially leading to double-spending scenarios. In such cases, an asset could appear simultaneously in both blockchains (Hardjono, 2021).

* **Gateway vulnerability:** Gateways are potential targets for denial-of-service (DoS) attacks (Chaganti et al., 2022). These attacks threaten the continuous operation of the interoperability process. It is essential for an effective interoperability protocol to function in the face of both malfunctioning and dishonest gateways, as outlined in Hardjono et al. (2019), Hardjono (2021).

### 4.1.4. Identities management

Each blockchain network autonomously manages the identities of its validators and users. Specifically, a blockchain node possesses two sets of public/private key pairs: ($pk_{in}, sk_{in}$) and ($pk_{out}, sk_{out}$). Here, $pk_{in}$ exclusively facilitates intradomain interactions within the given blockchain, while $pk_{out}$ enables interdomain communications for validators, necessitating authentication from other blockchain networks. Conversely, users are equipped with a single active public/private key at any given time, granting access to the corresponding blockchain services they are affiliated with.

## 4.2. Proposed protocol

This paper presents a robust interoperability protocol designed for the seamless move of assets between diverse blockchains. Our approach employs an incentive-driven smart contract to promote honest behavior among participants. In addition to the incentive smart contract, ZKP are utilized to ensure confidentiality and prevent collusion between users and gateways, thereby verifying claims accurately. Our objective is to facilitate secure and private asset transfer across distinct blockchains while preserving decentralization. As illustrated in Fig. 2, the proposed protocol encompasses the following eight steps:
<figure><img src="image_4.png" /><figcaption>Fig. 2. Summarizes the proposed protocol steps.</figcaption></figure>

(1) The protocol starts with a transfer request initiated by a user from B1. The user anticipates obtaining a verifiable credential that grants them the capability to move their asset to B2. For this process, the user should possess a wallet associated with B1, facilitating the payment of the transfer fee. The transfer request, denoted as $T_x$, is characterized by essential attributes:

$$T_x := (ref_{b2}, fee, h_s, sig)$$

Here, $ref_{b2}$ references to the B2 blockchain, $fee$ is the transaction fee, and $h_s$ denotes the hash of a secret $S$ generated by the user to secure the payment fee until the transfer completion. The user signature, denoted as $sig$, is part of the transaction $T_x$ and serves as a verification of the user ownership of asset $X$ that is intended for transfer. Asset $X$ could potentially carry the user inter-domain identity; hence, it is omitted from $T_x$ to prevent any linkage to the user identity during transactions. It is crucial to maintain the confidentiality of the user's identity and the asset throughout the interoperability process. ZKP encryption techniques are applied to uphold this confidentiality. To elaborate further, a temporary identity is utilized for signing $T_x$, which remains associated with the user's public identity, becoming evident only when the user-chosen secret $S$ is unveiled. Additional technical details are provided in Section 6.2.

If $X$ is intended for transfer to an existing account within B2, the reference to that account is incorporated into $T_x$. Once the request transaction is disseminated across B1, it undergoes validation by B1 blockchain nodes, subsequently entering their transaction pools. The validation process includes user authentication, confirmation of the requested asset availability, and verification that the fee has been appropriately locked.

(2) Following the initial step, a gateway node called G1 is chosen from B1 to lead the interoperability process. To ensure fairness and randomness in selection, we assume the existence of a function that assigns each gateway a random order, with the lowest-ranked gateway becoming the leader and the others serving as backups in order. Importantly, the identity of G1 remains concealed during this process, enhancing security and

preventing potential Denial of Service (DoS) attacks. Combining the random gateway order with hidden identities creates a transparent backup system, ready to replace the leader if it fails. The leader gateway operates within a specified time window to establish and share interoperability rules with B2. If G1 fails, the leadership is seamlessly transferred to the top backup gateway, ensuring the continuity of the interoperability protocol. This approach guarantees protocol liveness and underscores the fairness of the scheme, as validators have an equal chance of becoming gateways.

(3) In this step, the leader gateway (G1) initiates the establishment of interoperability rules with one or more validators within B2. For simplicity, let us assume this involves a single validator (G2). The leader gateway (G1) needs to communicate the consensus mechanism employed by B1 to generate the verifiable credential. In turn, G2 must confirm its willingness to accept the user request in B2 by signing the interoperability rules. These rules also incorporate the agreed-upon payment platform (P), which will compensate G2 for its services upon completion of the process. The structure of the interoperability rules (R) is defined as follows:

$$R := (T_x, cons, pk_{g2}^{out}, pk_{g1}^{P}, pk_{g2}^{P}, val, sig),$$

Here, $cons$ denotes the consensus protocol in B1 for generating the verifiable credential. $pk_{g2}^{out}$ represents the inter-domain identity of G2. $pk_{g1}^P$ and $pk_{g2}^P$ refer respectively to the identities of G1 and G2 within the payment platform P. $val$ is the cost of G2 services, which must be lower than the initial transfer request fee. Lastly, $sig$ corresponds to G2 signature of the interoperability rules. This step accommodates any modifications in the consensus protocols of the interacting blockchains, making the proposed scheme adaptable and agnostic.

(4) This step mandates G1 to substantiate the credibility of its assertions by disclosing R within B1. Notably, the interoperability rules R are endorsed with the signature of G2 to validate the viability of the user request for asset move to B2. Additionally, R.cons is set to establish a global consensus in B1, making any attempts by G1 and dishonest validators in B1 to collude and
fabricate evidence ineffective. This assurance stems from the assumption that honest validators dominate the network. Furthermore, keeping G1 anonymous from the user, and vice versa, is essential. This precaution helps prevent any collaboration between the two, ensuring the accuracy of verifiable credentials is not compromised by collusion.

(5) At this stage, G1 deploys the smart contract referred to as C<sub>p</sub> on the agreed payment platform. The purpose is to ensure compensation for G2 services. To achieve this, the fees owed to G2 are locked within C<sub>p</sub>, employing the secret S generated by the user in step 1 of the protocol. Notably, G1 remains unaware of the actual secret S; its revelation could potentially trigger the payment prematurely, before the asset transfer concludes. The composition of C<sub>p</sub> is as follows:

$$C_p(c_{id}, S, T, val),$$

<caption>**Algorithm 1 Payment Smart Contract (C<sub>p</sub>)**</caption>

**Input:**
$c_{id}$ : the unique identity of the smart contract
$h_s$ : the hash of the secret S generate by the user
$H$ : hash function used to encrypt S
$T$ : the smart contract timeout lock
$val$ : G2 services cost
$pk_{g1}^p$ : G1 address in P
$pk_{g2}^p$ : G2 address in P

1: **if** $H(S)=h_s$ **and** `currentTime()` $\le$ $T$ **then**
2: &nbsp;&nbsp;&nbsp;&nbsp;`Send(val, pk_{g2}^p)`
3: &nbsp;&nbsp;&nbsp;&nbsp;`Reveal S` to $pk_{g1}^p$
4: **else if** `currentTime()` $> T$ **then**
5: &nbsp;&nbsp;&nbsp;&nbsp;`Reveal S` to $pk_{g1}^p$
6: &nbsp;&nbsp;&nbsp;&nbsp;`Refund(val)`
7: **end if**

Here, $c_{id}$ is the unique identifier of the contract within the payment platform (P). T designates the duration of the dedicated timeout period for the asset movement. The logic embodied in C<sub>p</sub> is given in Algorithm 1. If the user fails to complete the asset transfer before the stipulated timeout (T), G2 remains uncompensated. Concurrently, the user account is unlocked within B1, allowing them to reclaim the remaining transaction fee (T<sub>x</sub>.fee) previously locked during step 1. Irrespective of the outcome, G1 is assured payment since it facilitated the generation of the verifiable credentials and deployed the smart contract.

(6) In the sixth step, the validators in B1 collectively execute the R.cons consensus, resulting in the creation of a new block that encompasses all pertinent interoperability data. This block serves as the user's crucial verifiable credential for it asset in B2. This credential, denoted as C<sub>r</sub>, is structured as follows:

$$C_r := (\text{cons}_{\text{input}}, R, C_p),$$

The component `cons_{input}` encompasses the necessary inputs to validate the effective execution of the interoperability consensus (R.cons) within B1. As a distinct block in B1, the advent of C<sub>r</sub> triggers the locking of asset X, rendering it as non-spendable.

(7) The user can now use the verifiable credential published in B1 to demonstrate their eligibility for moving the asset to B2. Assuming that G2 shared the interoperability rules with B2 in step 3, all validators within B2 are informed about the user request and can validate the provided proofs. After successful validation and achieving a consensus, the equivalent to asset X is generated in B2.

(8) At this point, the user asset exists in B2, but the user cannot write to the blockchain until they obtain an intra-domain identity in B2. The identity is generated after the user reveals the secret S, which will reveal the asset in B1, and unlock the transaction fee set in the payment smart contract (C<sub>p</sub>). Upon unlocking the fee, C<sub>p</sub> automatically executes payment to G2 and subsequently discloses S to G1, enabling it to claim the transaction fee locked in B1. It is important to note that if the user fails to reveal S before the timeout, the interoperability process is unsuccessful. In such cases, the user might receive a flag in B2, potentially affecting future treatment of their requests. If the process is terminated like this, the user must connect to B1 to claim the remaining transaction fee.

The user incurs a financial loss if they do not reveal S at this stage, as they still owe payment to G1. However, a scenario can be envisioned where G2 shares incorrect interoperability claims with G1 during step 3. We will demonstrate through game theory in the next section that the proposed incentive strategy encourages participants to act honestly. Additionally, if G2 engages in dishonest behavior, it will be identified by the consensus in B2 and subjected to penalties, such as gateway revocation. Furthermore, B1 will be alerted to take appropriate measures concerning G2 in future interactions. While sharing information about gateway misconduct and subsequent punitive actions between blockchains is an important consideration, it falls beyond the scope of this work.

The proposed interoperability scheme uses an incentive model designed to promote honest behavior. Users must compensate the gateways (G1 and G2) for their services throughout the interoperability process. Regardless of the outcome of the asset transfer, G1 receives compensation for deploying the smart contract C<sub>p</sub>. G1 is required to publish all data necessary for the asset movement (C<sub>r</sub>) on Blockchain B1, facilitating the verification of C<sub>p</sub>. If G1 engages in dishonest actions, the interoperability protocol will not succeed on B1, and the block details produced by G1 will be inspected for adherence to the user request. In such instances, G1 loses the funds allocated for the smart contract deployment. The proposed solution integrates measures such as identity hiding and random selection of the leader gateway (G1) to deter collusion attacks that lead to creation of wrong proofs. By combining these various techniques, the proposed protocol makes it challenging for both the user and the gateways to engage in malicious collaboration.

## 5. Protocol analysis

This section explains how the proposed protocol achieves its objectives and compares it to existing interoperability schemes.

### 5.1. Security analysis: the incentive strategy efficiency

To prove the efficacy of the proposed incentive strategy in enhancing the security and reliability of the proposed scheme, game theory is used. The actions of the participants in the interoperability protocol are modeled as a Stackelberg game (Simaan and Cruz, 1973), a sequential-move game (see Fig. 3).

#### 5.1.1. Definitions

* Variables:

- $r_1$ and $r_2$: Payoffs for G1 and G2, respectively.

- $u_i$: utility for player i.

* Players:

- User

- G1: first gateway
<figure><img src="image_5.png" /><figcaption>Fig. 3. Game theory tree.</figcaption></figure>

- G2: second gateway

* **Strategies:**

- Honest (H)

- Dishonest (D)

* **Utility:**

- The user aims to minimize paid fees.

- G1 and G2 aim to maximize their respective gains ($r_1$ and $r_2$).

### 5.1.2. Backward induction analysis

* Starting with the user strategies, and given the gateways potential moves, the outcome utilities are: {$u_1, u_3, u_4, u_5, u_6, u_7, u_8$}. The user prefers zero loss over losing $r_1$.

* Considering G2 moves, knowing G1 acted honestly, G2 prefers gaining $r_2$. This preference excludes outcomes leading to $u_3$ and $u_4$.

* G1, as the first player, targets the highest utility among remaining options. Considering G2 strategies, G1 prefers the outcome leading to $u_1$ to maximize $r_1$.

## Conclusion

From the analysis, the strategy profile (H, H, H) stands out as the Nash Equilibrium of this game. Thus, when all players act in honesty, adhering to the proposed protocol, they each achieve maximum utility. This outcome not only underlines the efficacy of the proposed incentive strategy but also increases the trust and security embedded within the interoperability system.

The security of the proposed interoperability protocol is based on the assumption that a rational user aims to maximize their profit. Additionally, the robustness of the authentication mechanism, leveraging Schnorr ZKP, relies on the widely accepted difficulty of solving the discrete logarithm problem. This affirmation has reinforced our decision to opt for a Zero (ZKP) scheme over other authentication schemes. The latter presents trade-offs among usability, security, and privacy, as extensively discussed in Wang et al. (2014) and thoroughly evaluated in Wang and Wang (2022).

## 5.2. Achieved properties

In this part, we discuss the achieved properties of the proposed interoperability protocol.

* **Atomicity:** The interoperability protocol guarantees the atomicity of the asset movement using the smart contract ($C_p$). The user

asset will either be successfully transferred to B2, or the entire process will be aborted within a specified timeout $T$.

* **Consistency:** The asset can exist in only one blockchain at a time. It becomes spendable in the destination blockchain (B2) only after the interoperability process is completed and the user has revealed the secret $S$ to trigger the payment process for the gateways.

* **Isolation:** During step 6 of the interoperability protocol, the asset is locked in B1, rendering it unspendable until the completion of the entire process.

* **Durability:** The asset movement is finalized via a consensus mechanism within the destination blockchain. Therefore, it remains persistent unless malicious validators gain control over the blockchain network.

* **Verifiability:** As described in step 6, an honest user presents a verifiable credential issued using a global consensus from the source blockchain to the destination blockchain. More explicitly, G1 shares any necessary information about B1 consensus rules, making the proposed protocol agnostic. Then, the information is validated through consensus in B1 and published alongside the interoperability-related data. Only then will the asset be built in B2. Hence, the proposed protocol offers strong verifiability between the two interoperating blockchains.

* **Confidentiality:** The participants (users and validator nodes) in the interoperability protocol maintain their anonymity. This is achieved by encrypting their identities using a ZKP scheme.

* **Robustness against attacks:** The gateways, as pivotal components in our protocol, can become prime targets for malicious entities seeking to attack the system.

(a) **DoS attacks:** For instance, attackers might consider launching Denial of Service (DoS) attacks against the gateways, aiming to disrupt their availability. However, our approach of concealing gateway identities combined with the randomization in selecting the leading gateway greatly heightens the challenge for executing such attacks.

(b) **Collusion attacks:** Additionally, there is a potential threat where the designated leader gateway might conspire with a user to disseminate false information to the destination blockchain. To thwart this possibility, we have introduced measures to keep user identities anonymous. Moreover, the proposed protocol integrates an incentive scheme that promotes honest behavior among both the users and the gateways. The effectiveness of this incentive-centric approach is rigorously analyzed and substantiated in Section 5.1.

* **Fairness:** The honest gateways are selected randomly and equitably to orchestrate the interoperability process.

* **Agnostic:** The proposed protocol dynamically adapts to any changes in the source blockchain. In step 3, the gateways share consensus rules for the verifiable credential generation, making the protocol agnostic.

We have demonstrated the proposed protocol security, robustness, verifiability, and fairness. However, it is crucial to verify its feasibility in terms of delay. In the upcoming sections, we will analyze the interoperability protocol delay both theoretically and empirically.

## 5.3. Delay evaluation

In this section, we assess the proposed protocol delay, which considers the entire process from the user initial request in B1 to the completion of the asset movement in B2. We establish an equation, denoted as $t$, that represents the cumulative processing delays of each protocol step. Note that communication delays, such as data transmission within the blockchain networks, are excluded from this consideration. The protocol delay is formulated as $t = t_1 + t_2 + \dots + t_g$, where:
<table><caption>**Table 1**
Variables description.</caption><thead><tr><th>Variable</th><th>Description</th></tr></thead><tbody><tr><td>t<sub>zkp<sub>s</sub></sub></td><td>Signing using ZKP delay</td></tr><tr><td>N</td><td>The number of B1 gateways</td></tr><tr><td>t<sub>zkp<sub>v</sub></sub></td><td>Verifying ZKP signature delay</td></tr><tr><td>t<sub>cons<sub>1</sub></sub></td><td>B1 Network consensus delay</td></tr><tr><td>t<sub>cons<sub>2</sub></sub></td><td>B2 Network consensus delay</td></tr><tr><td>t<sub>F</sub></td><td>The random function F execution delay</td></tr><tr><td>t<sub>g<sub>1</sub>g<sub>2</sub></sub></td><td>The delay to establish a secure communication channel between G1 and G2</td></tr><tr><td>t<sub>g<sub>2</sub></sub></td><td>The time it takes G2 to process the user request and to compute a response</td></tr><tr><td>t<sub>R<sub>v</sub></sub></td><td>The verification of the interoperability rules R in B1</td></tr><tr><td>t<sub>c<sub>p</sub></sub></td><td>The creation and deployment of the smart contract C<sub>p</sub> on the payment platform</td></tr><tr><td>t<sub>c<sub>r<sub>v</sub></sub></sub></td><td>The verifiable credential verification delay</td></tr><tr><td>t<sub>id<sub>g</sub></sub></td><td>New account creation in B2 delay</td></tr></tbody></table>

(1) $t_1 = 2 * (t_{zkp_s} + t_{zkp_v}) + t_{cons_1}$, where $t_{zkp_s}$ denotes the average delay when signing using a ZKP protocol and $t_{zkp_v}$ when verifying the signature. $t_{cons_1}$ is the average consensus latency in B1. ZKP signing is used twice by the user: to lock the transaction fee and to sign $T_x$ anonymously. In addition, the global consensus is run to lock the transaction payment fee.

(2) $t_2 = t_{zkp_s} + (N - 1) * t_{zkp_v} + t_F$, where $t_F$ is the execution time of the random verifiable function $F$ and $N$ number of gateways. Each gateway generates ZKP proof to participate in the leader selection. The generated anonymous identities are then shared and verified among gateways. Finally, each gateway runs the random function $F$.

(3) $t_3 = 2 * (t_{zkp_s} + t_{zkp_v}) + t_{g1g2} + t_{g2}$, where $t_{g1g2}$ denotes the time it takes G1 to establish a secure communication channel with B2. And $t_{g2}$ the time it takes G2 to verify and to compute a response to the user request. This step requires two rounds of communications between G1 and G2 to establish the interoperability rules. A ZKP signing is used during each round to hide the gateway identity.

(4) $t_4 = t_{zkp_v} + t_{R_v}$, where $t_{R_v}$ corresponds to the time it takes to verify the interoperability rules R. B1 validators also have to authenticate G2 in this step.

(5) $t_5 = t_{c_p}$, where $t_{c_p}$ is the corresponding delay to the smart contract $C_p$ invocation on the payment platform.

(6) $t_6 = t_{cons_1} + t_{zkp_s}$. In this step, a block containing the verifiable credential is created by G1 and published in B1. A ZKP protocol is always used by G1 to sign the block.

(7) $t_7 = t_{c_r_v} + t_{zkp_v} + t_{cons_2}$, where $t_{c_r_v}$ is the verification time of the verifiable credential ($C_r$) in B2. $t_{c_r_v}$ depends on the consensus rules $R$. $t_{cons_2}$ is the consensus latency of the blockchain B2. B2 validators have at least to authenticate the issuer of $C_r$, requiring ZKP signature verification.

(8) $t_8 = t_{id_g}$, where $t_{id_g}$ is the time it takes to generate a new identity of the user in B2. That is, only if the user requested to move their asset to a new account in B2.

So,

$$t = 6 * t_{zkp_s} + (N + 5) * t_{zkp_v} + 2 * t_{cons_1} + t_{cons_2} + t_F + t_{g1g2} + t_{g2} + t_{R_v} + t_{c_p} + t_{c_r_v} + t_{id_g}$$

<caption>**Table 1** describes the equation delay (t) variables.</caption>

The variables $t_F$, $t_{R_v}$, and $t_{c_r_v}$ are considered to be negligible compared with the protocol total delay. Furthermore, the $t_{g2}$ delay is also negligible, assuming that G2 stores the complete B2 blockchain

and can locally process the user response by requesting its local ledger. $t_{g1g2}$ delay is also negligible compared to the total delay if we assume that there are dedicated services that enable gateways from different networks to find each other.

So finally, the time equation can be contracted into:

$$t = 6 * t_{zkp_s} + (N + 5) * t_{zkp_v} + 2 * t_{cons_1} + t_{cons_2} + t_{c_p} + t_{id_g}$$

Regarding scalability in terms of increasing requests, multiple asset movement requests can be processed simultaneously, and multiple verifiable credentials can be included in one block. However, a smart contract must be invoked separately for each asset transfer request. It is worth mentioning that the scalability limitations of the blockchain, such as high inter-block delay, will impact the protocol delay. Therefore, in Section 6, we simulate and evaluate the protocol delay (t) considering a specific scenario.

## 5.4. Comparison with existing works

This section compares the proposed interoperability protocol against existing protocols that employ a gateway-based architecture. Specifically, we have identified three protocols for comparison: the basic gateway protocol (Hardjono et al., 2019), the witness blockchain protocol (Hardjono, 2021), and the threshold-based protocol (Wang and Nixon, 2021). The comparison focuses on key metrics encompassing verifiability (i.e., the effectiveness of the provided blockchain proof), privacy techniques employed to maintain confidentiality between the involved blockchains throughout the interoperability process, and the protocol resilience against dishonest gateways. The comparison is summarized in Table 2. Notably, metrics like fairness and delay are excluded from the table due to the limited availability of comparative elements. Additionally, the ACID and agnosticism properties are omitted from the comparison as they are assumed to be achieved in the existing protocols.

It is worth noting that each component of our scheme can undergo thorough individual assessment. For instance, the authentication scheme can be evaluated in detail against other authentication methods, utilizing standard performance metrics outlined in Bonneau et al. (2012) and Wang et al. (2018). In Bonneau et al. (2012), the authors examine two decades of authentication proposals aimed at replacing text passwords for general-purpose user authentication on the web, considering a broad set of twenty-five usability, deployability, and security benefits that an ideal scheme might offer. Additionally, Wang et al. (2018) proposes a systematic evaluation framework focusing on security, efficiency, and scalability for measuring Two-Factor Authentication Schemes for Real-Time Data Access in Industrial Wireless Sensor Networks.

While these references are significant, some of the metrics they employ may not directly apply to our context or may fall outside the scope of our paper. Metrics such as “Easy-to-Learn”, “Infrequent-Errors”, “Easy-Recovery-from-Loss”, “Server-Compatible”, and “Browser Compatible” are tailored specifically to ZKP-free authentication schemes and may not be suitable for our use case.

It is also important to note that in our evaluation methodology, we refrain from relying on proprietary metrics. Instead, we adhere to standardized indicators commonly found in similar works. Performance metrics such as Atomicity, Consistency, Isolation, Durability, Verifiability, Decentralization, Confidentiality, Robustness, Fairness, Agnosticism, Delay, Scalability, and Privacy are widely accepted in a blockchain-based context (Belchior et al., 2022; Hardjono et al., 2018). Therefore, our evaluation is comprehensive as it is based on standardized metrics, providing a holistic assessment of the system rather than focusing solely on individual components.
<table><caption>**Table 2**
Comparison with existing protocols.</caption><thead><tr><th>Protocol</th><th>Illustration</th><th>Description</th><th>Verifiability</th><th>Privacy</th><th>Robustness against attacks</th></tr></thead><tbody><tr><td>The basic gateway-based protocol (Hardjono et al., 2019)</td><td>B1 G B2</td><td>Introduced the gateway-based architecture wherein some of the blockchain validators as interoperability services providers</td><td>Low</td><td>Medium</td><td>Low</td></tr><tr><td>The witness blockchain-based protocol (Hardjono, 2021)</td><td>B1 G B2 B3</td><td>Relies on a third-party witness blockchain that records the gateways interactions</td><td>Low</td><td>Medium</td><td>Low</td></tr><tr><td>The threshold signature-based protocol (Wang and Nixon, 2021)</td><td>B1 G B2 G</td><td>Coupled a threshold signature scheme with the basic gateway-based protocol</td><td>Medium</td><td>Medium</td><td>Medium</td></tr><tr><td>Proposed protocol</td><td>B1 G B2</td><td>Proposed an incentive smart contract combined with ZKP techniques to enable a secure blockchain interoperability</td><td>High</td><td>High</td><td>High</td></tr></tbody></table>

* **Verifiability:** High verifiability is achieved in the proposed protocol by imposing a global consensus to validate the leader gateway claims while creating the verifiable credential. The gateway claims are assumed trustworthy in the basic gateway-based protocol, and no further verification layer was established. However, that is a strong assumption as they can be dishonest and share wrong claims. The same assumption is made for witness blockchain-based protocol. Its verifiability is hence low even though the witness-based blockchain (B3) retrospectively helps to detect dishonest gateways. The threshold-based protocol offers a higher verifiability thanks to relying on a group of gateways certifying leader gateway claims. However, a dishonest gateway can still convince dishonest gateways to collude and form a malicious group.

* **Privacy techniques:** In the basic gateway-based protocol, gateways use identity mapping to hide the intra-domain identity of the user when sending cross-chain messages. However, the gateway still knows the user identity, allowing dishonest gateways to reveal their information to the destination blockchain. That privacy concern is also relevant for the witness blockchain-based and threshold signature-based protocols. Our proposed protocol forces users to hide their identities through a ZKP scheme. The gateways also must remain anonymous, using the same ZKP techniques. Therefore, the proposed interoperability protocol discloses no personal data without the user consent.

* **Robustness against attacks:** The witness blockchain-based protocol relies on a jurisprudence blockchain that records the gateway activities. Dishonest participants can thus be punished and revoked as interoperability service providers. Therefore, the witness blockchain-based protocol is more robust against attacks than the basic gateway-based protocol, which does not provide any method to counter dishonest gateways. Gateways can still share erroneous claims without impunity in the threshold signature-based protocol. However, it is more challenging for a gateway to misbehave than the basic gateway-based protocol. That is because the leader gateway needs to collude with other gateways. All the above protocols failed to counter malicious gateways. They have a single point of failure and are prone to collusion attacks.

In contrast, the proposed protocol mitigates DoS attacks on gateways through random selection and identity hiding. The latter also makes corruption between the user and the gateways difficult. In addition, we use an effective incentive strategy to prevent gateways from being dishonest.

In summary, the proposed protocol ensures better verifiability, privacy preservation, and robustness against dishonest gateways compared to existing protocols. The following section proposes a use case that deploys and empirically assesses the proposed protocol.

## 6. Use case

This section defines a use case to evaluate the proposed protocol empirically. We then show how the proposed scheme can be deployed for a specific interoperability scenario. In addition, a thorough evaluation of the protocol delay is assessed considering the smart contract deployment costs and blockchain parameters such as consensus delay, transactions arrival rate, and pending transactions. The coexistence of interdomain and intradomain transactions is also analyzed and discussed.

### 6.1. Use case definition

Digital assets hold value within specific blockchain networks. However, their transactions are limited to those networks. The question is: how can users move assets across different blockchains without intermediaries? Our protocol tackles this, guaranteeing security and privacy. The main goal is to illustrate how this protocol works in a specific scenario, providing more implementation details for better understanding.

Let us consider the following scenario :

* **B1:** a blockchain network composed of five validators ($v_1, v_2, v_3, v_4, v_5$) running the Tendermint consensus mechanism. Among these validators, three ($v_1, v_2, v_3$) are registered as gateways, having respectively $pk_1^{out}, pk_2^{out}, pk_3^{out}$ as their interdomain public/private key pairs and are authenticated in B2. Since B1 runs Tendermint, the validators have dynamic voting power. Let $H$ be the standard hash function used in B1. And let $pk_l$ be the address that locks assets such that if sent to $pk_l$, they become unspendable in B1. We assume that it is possible to lock an asset under specific conditions.

* **B2:** a blockchain network running Hyperledger Fabric v1.0 of four validators having interdomain public/private key pairs. The validators must be able to authenticate validators from the blockchain B1 through their interdomain keys. Let $ref_{b2}$ be the reference to B2 blockchain.

* The user: possesses a public-private pair ($pk_u, sk_u$) for authentication in B1. Let $X$ represent the asset intended for transfer to B2.
## 6.2. Protocol deployment

The proposed protocol is adapted to this use case following these eight steps:

(1) The user initially locks the payment fee for the transfer request (i.e., to move the asset) in B1 by issuing the transaction $T_{fee}$ defined as:

$$T_{fee} := (fee, ti, pk_i, h_s, sig),$$

Here, *fee* denotes the transfer fee, while *ti* represents the timestamp. *pk*<sub>*i*</sub> represents the destination address of the fee, rendering it unspendable. *h*<sub>*s*</sub> = *H*(*S*) is the hash of a secret *S* generated by the user. *T*<sub>*fee*</sub> remains locked within B1 until the user reveals *S*. This ensures that the fee will only be dispatched once the user initiates it. As such, the user maintains control over the payment triggering. Lastly, *sig* denotes the user signature. It is important to note that the *sig* must authenticate the user without disclosing their identity. Further technical details regarding this aspect will be provided subsequently.

Next, the user creates the transfer request defined as:

$$T_x := (ref_{b2}, ti, H(T_{fee}), sig)$$

Where *ref*<sub>*b2*</sub> is a reference to B2 blockchain, *ti* the timestamp. *H*(*T*<sub>*fee*</sub>) is used as a reference to *T*<sub>*fee*</sub> in blockchain B1. The signature, *sig*, is generated using the Schnorr non-interactive zero-knowledge proof (NIZK) (Hao, 2017). Non-interactive means that the verification is possible by any entity having access to the public variables of the ZKP protocol. *sig* will be, in addition to being a signature, also the proof of knowledge of *pk*<sub>*u*</sub> linked to a temporary identity *y* (public) through *S*, by the relation: *y* = *g*<sup>*S*</sup>. *S* must be generated such that it is linked with the user public key *pk*<sub>*u*</sub>. Thus, all validators in B1 can publicly verify that the user knows *pk*<sub>*u*</sub> without revealing it.

The pair (*y*, *S*) is established through the relation *y* = *g*<sup>*S*</sup>, while *y* and *H*(*g*) are made public in the same way as their public keys but at different times. This avoids establishing a relationship between the user public key and *y*. In this way, *y* represents an temporary anonymous public identity (or account), which can be used to perform transfer and receipt operations of assets without knowing the associated public or private keys.

The user connects to authenticate and issue requests. Once connected, they receive a recyclable key pair at each connection (*s*, *t*) randomly linked by the relation: *t* = *g*<sup>*s*</sup>. *s* is private, and *t* is public.

**Signaling with NIZK.** Let us consider the cyclic group *G*, generated by *g*, of prime order *q*, where *g* and *q* are public. Suppose we want to sign an integer *x* = *S* ∈ *G*, such that *y* = *g*<sup>*x*</sup>, without revealing *x*. The signing process using the ZKP involves the following steps:

(a) The user selects a secret $s \in \mathbb{Z}_q^*$. Here, $\mathbb{Z}_q^*$ denotes a finite cyclic group of order $q-1$.

(b) The public key is computed as, $t = g^s \in G$.

(c) Using the computed public key and other components, the signature *sig* is formed as a pair *sig* = (*c*, *r*). In this pair:

* $c = H(g, y, t, T_x)$ is a hash function incorporating the public variables and the transaction.

* $r = s - c \times x$ is a derived value using the secret, hash result, and an unknown *x*.

**Verification.** To verify the authenticity of the user signature:

(a) Validators compute the value $g^r \times y^c$.

(b) This computed value must match *t* for the signature to be valid.

It is vital for validators to have knowledge of the public variables *q*, *g*, *y*, *t* to execute the verification process.

In what follows, all authentication is done using ZKP with the process previously described, independently of the blockchain.

(2) At this step, a gateway is selected to handle the asset movement process. The gateways get their identities generated using the described above ZKP scheme. The ZKP is meant to hide gateway identities from the user to avoid collusion attacks. Let {$t_1, t_2, t_3$} be the public keys resulting from the ZKP, respectively on the secrets $pk_1^{out}, pk_2^{out}$, and $pk_3^{out}$. To simplify the selection of the leader gateway, we consider a function $T(l, seed)$ that randomly orders the gateways through the $y_i$ associated with $pk_i$ by the relation: $y_i = g^{pk_i}$. Where *l* is a list of the ZKP keys of the gateways (i.e., {$t_1, t_2, t_3$}), and *seed* is the seed of the random function. We use $H(T_x)$ as the *seed*. For each $T_x$, a gateway executes *T* to verify if it is the leader gateway.

(3) Let $g_1$ be the leader gateway. In an off-chain manner, $g_1$ shares the interoperability rules with gateways from B2 to enable the approval process. In this context, $g_1$ has to create a secure communication channel with one gateway (e.g., $g_2$) from B2. $g_2$ will then provide the equivalent asset $X'$ in B2 of *X*, the user asset. It is important to note that the asset remains anonymous, and $g_2$ must trust the ZKP proofs in $T_x$ which verifies the existence of asset *X* in B2. The final approval occurs in the last step of the protocol when *S* is revealed. $g_1$ also has to agree with $g_2$ on the payment cost of its provided service and the payment platform. The result of this negotiation phase is the interoperability rules, defined as:

$$R := (T_x, X', \text{cons}, pk_{g_2}^{out}, sig),$$

Where *cons* is the consensus rules that will be followed in B1 to generate a verifiable credential for the user. Since B1 runs Tendermint, *cons* must include the blockchain validators' interdomain keys and their voting power. More explicitly, *cons* is defined as the set {$v_1, c_1$}, ..., {$v_4, c_4$}), where $c_i \in \mathbb{N}^*$ is the voting power of $v_i$. Here, *sig* represents the signature of *R* by $g_2$. It must enable validators in B1 to authenticate $g_2$ as a validator from B2 without revealing its identity.

(4) At this stage, the gateway $g_1$ spreads *R* in B1 network. B1 validators has to verify that *R.cons* ensures global consensus in B1 and $g_2$ is trustworthy and from B2. Thanks to the ZKP protocol, all that is achieved anonymously and privacy-preserving.

(5) Now, $g_1$ invokes the smart contract $C_p$ to eventually pay the gateway B2. This smart contract is locked using two parameters: the user secret *S* = $k_u$ and a timeout *T*. Assuming the agreed upon payment platform is Ethereum, the smart contract is then the implementation of the Algorithm 1 in Ethereum.

(6) At this step, validators in B1 run the Tendermint consensus on a block containing the verifiable credentials:

$$C_r : (\text{cons}_{\text{input}}, R, C_p),$$

Where $\text{cons}_{\text{input}}$ refers to the required inputs to run *cons* (i.e., Tendermint). $\text{cons}_{\text{input}}$ is the list of validators {$p_1^{out}, \dots, p_k^{out}$} such that $\sum_{i=1}^{l=k} c_i > \frac{2}{3} \sum_{i=1}^{l=4} c_i$. The interoperability rules *R* are included in *C*<sub>*r*</sub> to enable B2 validators to verify the proof and for traceability reasons. Furthermore, the smart contract, $C_p$, is added to *C*<sub>*r*</sub> to allow B2 access to the timeout *T* and to verify the authenticity of *S* when revealed by the user. Note that *C*<sub>*r*</sub> is a block appended to the B1 blockchain following the defined rules in *R.cons*.

(7) The user can now see the verifiable credential published in B1. Then, the user utilizes this credential in B2 as proof, enabling them to generate their asset *X* within B2. B2 validators must check if $C_r \cdot \text{cons}_{\text{input}}$ verifies the previously established interoperability rules and if it was signed by $g_2$ (i.e., $C_r \cdot R \cdot \text{cons}$). Once the verification is done, through consensus, B2 validators build a new block containing $C_r$ and a new transaction that creates $X'$, under the condition *S* is revealed before *T*.
<table><caption>**Table 3**
Simulation parameters.</caption><thead><tr><th>Parameters</th><th>Value(s)</th></tr></thead><tbody><tr><td># of pending intradomain txs</td><td>10, 100, 1000, 10000</td></tr><tr><td>interdomain txs arrival rate</td><td>1, 10, 20, 30, 40, 50, 60</td></tr><tr><td>total # cross-chain txs</td><td>1000</td></tr><tr><td># txs per block</td><td>1000</td></tr><tr><td>Gas price (Gwei)</td><td>[1–12], [13–24], [25–36], [37–48], [49–60]</td></tr><tr><td>t<sub>zkp_s</sub></td><td>0.3s</td></tr><tr><td>t<sub>zkp_v</sub></td><td>0.1s</td></tr><tr><td>N</td><td>5</td></tr><tr><td>t<sub>cons_1</sub> by default</td><td>2s</td></tr><tr><td>t<sub>cons_2</sub></td><td>10s</td></tr><tr><td>t<sub>id_g</sub></td><td>0.1s</td></tr></tbody></table>

(8) Once the user observes their asset successfully created in B2, they must reveal the secret S, to reveal the asset X initiate the payment to g2 before the specified timeout T. Until yet, the user has no intradomain identity within B2. This identity will only be established once the secret S is revealed with sufficient time remaining for g2 to claim its payment. As specified in the contract C<sub>p</sub>, the payment of g2 will reveal the secret S to g1. Then, g1 has to present S in B1 to unlock the transfer fee locked by the user in step 1. Note that revealing S will also enable B1 to deanonymize the user, thereby allowing actions in their wallet.

### 6.3. Use case evaluation

This section empirically evaluates the proposed protocol delay for the presented use case. The variables in the equation delay t, given as

$$t = 6 * t_{zkp_s} + (N + 5) * t_{zkp_v} + 2 * t_{cons_1} + t_{cons_2} + t_{c_p} + t_{id_g}$$

are evaluated to estimate t. In this context, the implementation of Shnorr scheme presented in Alessandro et al. (2023) is adapted to compute non-interactive Shnorr ZKP signing and verification delays, $t_{zkp_s}$ and $t_{zkp_v}$. Furthermore, to capture blockchain parameters on the proposed protocol, the Tendermint consensus is implemented to simulate the B1 network. Different values of $t_{cons_1}$ against pending transactions are captured. By default $t_{cons_1}$ (i.e., B1 consensus delay) is set to 2 s.

The B2 network is powered by Hyperledger Fabric v.1.0 of four validators; thus, $cons_2$ is estimated at 10 s. This value represents the average transaction confirmation delay in the Hyperledger Fabric network of 4 validators (Nasir et al., 2018). In addition, $t_{id_g}$, new identity creation delay in B2 is estimated to 0.1 s (Pongnumkul et al., 2017).

Ethereum is the payment platform, so the latency depends on the smart contract gas. The gas price is the amount of Gwei (or Ether) the user has to pay per unit of gas consumed (i.e., the amount of computing power) to process their transaction. In Pacheco et al. (2022), a comprehensive study was conducted on transaction processing time in relation to gas price, leveraging real Ethereum gas prices.<fnref n="2" /> The study segments gas prices into categories: very cheap (1–12 GWei), cheap (13–24 GWei), regular (25–36 GWei), expensive (37–48 GWei), and very expensive (49–60 GWei) (Pacheco et al., 2022, p. 16). It then presents the processing times for each category. These results are utilized to calculate the delay in the proposed protocol.

The Table 3 summarizes the simulation parameters. The underlined values are the default values of the corresponding parameters. The simulation values are thought to show important aspects of the proposed protocol. In the following, the terminologies cross-chain and interdomain transactions are used interchangeably.

<figure><img src="image_6.png" /><figcaption>**Fig. 4.** Protocol delay vs. Ethereum gas price.</figcaption></figure>

The studied metrics in this simulation are the impact of the smart contract on the protocol delay; the end-to-end delay of interdomain and intradomain transactions according to pending transactions; and finally, the coexistence of cross-chain and intradomain transactions.

#### 6.3.1. The impact of the smart contract C<sub>p</sub> on the protocol delay

Fig. 4 shows the evolution of t (i.e., protocol delay) against the increasing gas prices. As can be seen from the results, if the gas price is very cheap, the interoperability process takes more than 3000 s. This high delay results from the contract invocation time. The gas price needs to be higher to incentivize Ethereum validators to prioritize $C_p$, among other transactions. Fig. 4 also shows that if the gas price is regular (i.e., between 25–36 Gwei), the protocol delay is $t = 190$ s. It means the user has to wait for 190 s to see their asset in B2, which is reasonable for many use cases. Note that this delay can vary significantly and is correlated with the level of network congestion at the time of interaction with Ethereum.

To ensure minimized asset transfer delay, the user has to lock a sufficient transaction fee that will be used to pay the gateway G2, the smart contract invocation cost, and the remaining goes to the gateway G1. It belongs to G1 to negotiate with G2, the most appropriate formula, considering both the smart contract and G2 services costs. Users must be able to estimate the appropriate transaction fee for any given request.

The smart contract invocation time directly affects the protocol delay, such that if the former increases, the other follows. Therefore, gateways must choose the appropriate payment platform to minimize contract invocation delay and cost. For this use case, the gateways can choose Polygon<fnref n="3" /> as an alternative to Ethereum to reduce the cross-chain transaction fee and hence the transfer processing delay.

#### 6.3.2. The impact of B1 performance on the protocol delay

In Fig. 5, we study the effect of the increasing number of pending transactions on transaction latency (i.e., the end-to-end delay from generation to confirmation). 100 pending transactions, i.e., there are 100 interadomain transactions waiting in the validators mempools when a cross-chain transaction is issued. For this evaluation, the smart contract invocation delay is set to 30 s, based on optimal case data from GasTracker<fnref n="2" />. This decision is underpinned by the Ethereum network observed trend towards faster transaction processing delays. Intradomain, cross-chain, and prioritized cross-chain transaction latencies are plotted. Intradomain transactions refer to standard transactions in B1. The cross-chain transactions, however, correspond to the user asset movement request. Unlike intradomain transactions, interdomain or cross-chain transactions are finalized at the destination blockchain

<footnote n="2">² https://etherscan.io/gasTracker, accessed: April 30, 2024.</footnote>

<footnote n="3">³ https://polygon.technology/, accessed: April 30, 2024.</footnote>
<figure><img src="image_7.png" /><figcaption>Fig. 5. Transaction latency vs. Pending Transactions.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 6. Added delay in interadomain transaction.</figcaption></figure>

(B2). Finally, we have a prioritized cross-chain transaction, wherein the validators favor a cross-chain transaction over intradomain transactions. Fig. 5 shows a direct correlation between the number of pending transactions in the *mempools* and the resulting delay. The reason is that during each consensus round, the proposed block cannot contain more than a limited number of transactions (1000). The remaining transactions will still be pending on the *mempools*, waiting for the next round. Fig. 5 also shows that prioritizing cross-chain transactions reduces latency. For instance, increasing the number of pending transactions from 10 to 10000 increases the cross-chain transaction latency from 44 s to 72 s, while the prioritized cross-chain remains almost invariant (44 s). The invariance in prioritized cross-chain transactions despite the increase in pending transactions is because the inter-block delay (i.e., new block appearance delay) is almost the same.

The proposed interoperability protocol delay depends directly on the interacting blockchains. In particular, the higher the number of pending transactions in validators *mempools*, the longer the asset transfer delay. However, the delay remains unchanged when the gateways prioritize cross-chain transactions. The gateways will mainly prioritize interdomain transactions, aiming to maximize their profits. Therefore, it is interesting to analyze intradomain and interdomain transaction coexistence.

### 6.3.3. Interadomain transactions coexistence with intradomain transactions

Fig. 6 depicts the impact of cross-chain transactions arrival rate on intradomain transactions. The number of intradomain and cross-chain transactions to be generated is set to 1000. The cross-transaction arrival rate, however, increases from 1 to 60 tx/s (i.e., transaction per second), following a Poisson distribution. Fig. 6 shows that intradomain

<figure><img src="image_9.png" /><figcaption>Fig. 7. Protocol delay vs. increasing cross-chain transactions arrival rate.</figcaption></figure>

transaction latency increases with the cross-chain transaction arrival rate increase. For example, when cross-chain transaction arrival rate is 60 tx/s, the intradomain transaction latency increases by more than 4 s. This increase is because validators prioritize cross-chain over interdomain transactions to maximize profit.

On the other hand, Fig. 7 shows that prioritizing cross-chain transactions reduces the proposed interoperability protocol. For example, by increasing the arrival rate from 1 to 60 tx/s, the protocol delay *t* is reduced by 4 s. The first reason for this reduction in the protocol delay is that validators favor cross-chain transactions over intradomain transactions. The other reason is that, e.g., if the cross-chain transactions arrival rate is 60 tx/s, the 100 transactions can be included in the same block, as block size in 1000 transactions.

In summary, validators will favor cross-chain transactions to maximize their profit. The high frequency of interdomain transactions increases intradomain transaction latency. To mitigate that, the blockchain network (B1) could limit the number of gateways for each consensus round. Thus, when proposing a block, non-gateways cannot include cross-chain transactions. However, that must be achieved without compromising the fairness of the blockchain network.

## 7. Conclusion

This paper introduces an innovative blockchain interoperability protocol designed to address the pressing need for seamless and secure digital asset transfer across diverse blockchain networks. In a rapidly evolving blockchain landscape characterized by a multitude of applications and platforms, achieving interoperability has emerged as a critical challenge. Our protocol offers a novel solution that is agnostic, robust, and privacy-preserving, marking a significant advancement in the digital field.

Our work presents a groundbreaking blockchain interoperability protocol that serves to bridge the gap between disparate blockchain networks. This protocol facilitates the frictionless movement of digital assets while ensuring compliance with individual protocol constraints. By integrating incentive-driven smart contracts and Zero-Knowledge Proofs (ZKP), our protocol establishes a decentralized and privacy-focused framework for interoperability. This not only enhances the security and trustworthiness of cross-blockchain transactions but also provides a solution that is robust against dishonest participants. Through the utilization of game theory, we validate the effectiveness of our incentive scheme, ensuring heightened levels of verifiability, privacy protection, and overall robustness compared to existing models.

Furthermore, we have provided a detailed use case scenario to demonstrate the practical implementation of our protocol, coupled with a simulation-based analysis of its feasibility in terms of delay. This empirical evidence underscores the protocol's real-world applicability and effectiveness. Experimental results demonstrate that the protocol
delay averages around 190 s, indicating the time required for a user to witness the transfer of their digital asset from the origin blockchain B1 to the target blockchain B2. This delay has been found to be reasonable and acceptable for numerous real-world use cases, particularly in decentralized finance and e-commerce applications.

As we look towards the future, we aim to further enhance the proposed protocol by exploring optimization strategies to minimize protocol delay. This will significantly improve its suitability for interoperability scenarios that demand exceptionally low latency.

Furthermore, we are committed to studying the practical applicability of our protocol in specific domains, such as interoperability between insurance companies and telecommunications providers. In the insurance domain, for example, our protocol could facilitate the seamless transfer of user profiles between different insurance providers, enhancing customer convenience and satisfaction. Similarly, in the telecommunications sector, our protocol could enable users to switch their profiles in a decentralized manner, providing greater control over their personal data. The overarching goal is to develop a generic framework that enables easy and effective implementation of blockchain interoperability across various domain-specific use cases.

## Credit authorship contribution statement

**El-hacen Diallo:** Writing – review & editing, Writing – original draft, Visualization, Validation, Investigation, Formal analysis, Data curation, Conceptualization. **Mohameden Dieye:** Writing – review & editing, Writing – original draft, Validation, Methodology, Formal analysis, Conceptualization. **Omar Dib:** Writing – review & editing, Writing – original draft, Validation, Methodology. **Pierre Valiorgue:** Writing – review & editing, Writing – original draft.

## Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

## Data availability

No data was used for the research described in the article.

## References

Abou Jaoude, J., Saade, R.G., 2019. Blockchain applications–usage in different domains. IEEE Access 7, 45360–45381.

Alessandro, G., Luca, G., Andrea, G., Fadi, B., 2023. BITPoliTO/schnorr-sig. [Online]. Available: https://github.com/BITPoliTO/schnorr-sig.git. (Accessed 17 January 2023).

Anon, 2021a. Simplified payment verification. https://en.bitcoinwiki.org/wiki/Simplified_Payment_Verification. (Accessed 21 November 2022).

Anon, 2021b. atomic-swap based projects. https://github.com/topics/atomic-swap. (Accessed: 21 November 2022).

Anon, 2021c. BTC relay. http://btcrelay.org/. (Accessed: 21 November 2022).

Belchior, R., Riley, L., Hardjono, T., Vasconcelos, A., Correia, M., 2022. Do you need a distributed ledger technology interoperability solution? In: Distributed Ledger Technologies: Research and Practice. ACM New York, NY.

Belchior, R., Vasconcelos, A., Guerreiro, S., Correia, M., 2021. A survey on blockchain interoperability: Past, present, and future trends. ACM Comput. Surv. 54 (8), 1–41.

Bonneau, J., Herley, C., Van Oorschot, P.C., Stajano, F., 2012. The quest to replace passwords: A framework for comparative evaluation of web authentication schemes. In: 2012 IEEE Symposium on Security and Privacy. IEEE, pp. 553–567.

Bradach, B., Nogueira, J., Llambías, G., González, L., Ruggia, R., 2022. A gateway-based interoperability solution for permissioned blockchains. In: 2022 XVIII Latin American Computer Conference. CLEI, IEEE, pp. 1–10.

Bu, G., Haouara, R., Nguyen, T.-S.-L., Potop-Butucaru, M., 2020. Cross hyperledger fabric transactions. In: Proceedings of the 3rd Workshop on Cryptocurrencies and Blockchains for Distributed Systems. pp. 35–40.

Buchman, E., 2016. Tendermint: byzantine Fault Tolerance in the Age of Blockchains. University of Guelph.

Buterin, V., 2016. Chain interoperability. R3 Research Paper 9.

Čapko, D., Vukmirović, S., Nedić, N., 2022. State of the art of zero-knowledge proofs in blockchain. In: 2022 30th Telecommunications Forum. TELFOR, IEEE, pp. 1–4.

Cerdeira, D., Santos, N., Fonseca, P., Pinto, S., 2020. Sok: Understanding the prevailing security vulnerabilities in trustzone-assisted tee systems. In: 2020 IEEE Symposium on Security and Privacy. SP, IEEE, pp. 1416–1432.

Chaganti, R., Boppana, R.V., Ravi, V., Munir, K., Almutairi, M., Rustam, F., Lee, E., Ashraf, I., 2022. A comprehensive review of denial of service attacks in blockchain ecosystem and open challenges. IEEE Access.

Goldreich, O., 2002. Zero-knowledge twenty years after its invention. IACR Cryptol. ePrint Arch. 2002, 186.

Goldwasser, S., Micali, S., Rackoff, C., 2019. The knowledge complexity of interactive proof-systems. In: Providing Sound Foundations for Cryptography: On the Work of Shafi Goldwasser and Silvio Micali. pp. 203–225.

Hao, F., 2017. Schnorr non-interactive zero-knowledge proof. Request for Comments 8235, RFC Editor, [Online]. Available: https://www.rfc-editor.org/info/rfc8235.

Hardjono, T., 2021. Blockchain gateways, bridges and delegated hash-locks. arXiv preprint arXiv:2102.03933.

Hardjono, T., Lipton, A., Pentland, A., 2018. Towards a design philosophy for interoperable blockchain systems. arXiv preprint arXiv:1805.05934.

Hardjono, T., Lipton, A., Pentland, A., 2019. Toward an interoperability architecture for blockchain autonomous systems. IEEE Trans. Eng. Manage. 67 (4), 1298–1309.

Herlihy, M., 2018. Atomic cross-chain swaps. In: Proceedings of the 2018 ACM Symposium on Principles of Distributed Computing. pp. 245–254.

Jia, X., Luo, M., Wang, H., Shen, J., He, D., 2022. A blockchain-assisted privacy-aware authentication scheme for internet of medical things. IEEE Internet Things J. 9 (21), 21838–21850.

Johnson, S., Robinson, P., Brainard, J., 2019. Sidechains and interoperability. arXiv preprint arXiv:1903.04077.

Kotey, S.D., Tchao, E.T., Ahmed, A.-R., Agbemenu, A.S., Nunoo-Mensah, H., Sikora, A., Welte, D., Keelson, E., 2023. Blockchain interoperability: the state of heterogeneous blockchain-to-blockchain communication. IET Commun. 17 (8), 891–914.

Kwon, J., Buchman, E., 2019. Cosmos whitepaper. A Netw. Distrib. Ledgers.

Murray, A., Kim, D., Combs, J., 2022. The promise of a decentralized Internet: What is web 3.0 and HOW can firms prepare? Bus. Horiz.

Nasir, Q., Qasse, I.A., Abu Talib, M., Nassif, A.B., 2018. Performance analysis of hyperledger fabric platforms. Secur. Commun. Netw. 2018.

Ou, W., Huang, S., Zheng, J., Zhang, Q., Zeng, G., Han, W., 2022. An overview on cross-chain: Mechanism, platforms, challenges and advances. Comput. Netw. 109378.

Pacheco, M., Oliva, G.A., Rajbahadur, G.K., Hassan, A.E., 2022. Is my transaction done yet? An empirical study of transaction processing times in the ethereum blockchain platform. ACM Trans. Softw. Eng. Methodol.

Pillai, B., Biswas, K., Hóu, Z., Muthukkumarasamy, V., 2022. Cross-blockchain technology: integration framework and security assumptions. IEEE Access 10, 41239–41259.

Pongnumkul, S., Siripanpornchana, C., Thajchayapong, S., 2017. Performance analysis of private blockchain platforms in varying workloads. In: 2017 26th International Conference on Computer Communication and Networks. ICCCN, IEEE, pp. 1–6.

Robinson, P., 2021. Survey of crosschain communications protocols. Comput. Netw. 200, 108488, [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1389128621004321.

Simaan, M., Cruz, J.B., 1973. On the stackelberg strategy in nonzero-sum games. J. Optim. Theory Appl. 11 (5), 533–555.

Singh, A., Click, K., Parizi, R.M., Zhang, Q., Dehghantanha, A., Choo, K.-K.R., 2020. Sidechain technologies in blockchain networks: An examination and state-of-the-art review. J. Netw. Comput. Appl. 149, 102471.

Thomas, S., Schwartz, E., 2015. A protocol for interledger payments. [Online]. Available: https://interledger.org/interledger.pdf.

Tsague, A.Z., Fute, E.T., Amraoui, A., Tonye, E., 2018. DS-NIZKP: A ZKP-based strong authentication using digital signature for distributed systems. Int. J. Comput. Sci. Inf. Secur. (IJCSIS) 16 (6).

Wang, G., 2021. Sok: Exploring blockchains interoperability. Cryptology ePrint Archive.

Wang, D., He, D., Wang, P., Chu, C.-H., 2014. Anonymous two-factor authentication in distributed systems: Certain risks are beyond attainment. IEEE Trans. Dependable Secure Comput. 12 (4), 428–442.

Wang, D., Li, W., Wang, P., 2018. Measuring two-factor authentication schemes for real-time data access in industrial wireless sensor networks. IEEE Trans. Ind. Inform. 14 (9), 4081–4092.

Wang, G., Nixon, M., 2021. Intertrust: Towards an efficient blockchain interoperability architecture with trusted services. In: 2021 IEEE International Conference on Blockchain. Blockchain, IEEE, pp. 150–159.

Wang, D., Wang, P., 2018. Two birds with one stone: Two-factor authentication with security beyond conventional bound. IEEE Trans. Dependable Secure Comput. 15 (4), 708–722.

Wang, Q., Wang, D., 2022. Understanding failures in security proofs of multi-factor authentication for mobile devices. IEEE Trans. Inf. Forensics Secur. 18, 597–612.

Wang, G., Wang, Q., Chen, S., 2023a. Exploring blockchains interoperability: A systematic survey. ACM Comput. Surv.

Wang, Q., Wang, D., Cheng, C., He, D., 2023b. Quantum2FA: Efficient quantum-resistant two-factor authentication scheme for mobile devices. IEEE Trans. Dependable Secure Comput. 20 (1), 193–208.
**El-hacen Diallo** is currently a Postdoctoral Researcher at Université Paris-Saclay, holds a 2018 Computer Science Engineering degree from the Polytechnic School of Nouakchott and completed his Ph.D. at Paris-Saclay in April 2022. His research interests include distributed systems, cybersecurity, vehicular networks, and blockchain technology, building upon experience from his postdoctoral fellowship at Université Claude Bernard Lyon 1.

**Mohameden Dieye** is a young researcher who carries out his work within a research team of the Liris laboratory of the university Claud Bernard - Lyon 1. He graduated from Claude Bernard University with a Master's degree in Statistics-Econometrics, IT Security and Data Science. These main areas of research interest currently focus on theoretical (Cryptography, ZKP, SSI) and practical (DID, Interoperability, IoT, Blockchain) aspects.

**Omar DIB** is a computer scientist with a B.Eng. and Ph.D. from the University of Technology of Belfort-Montbéliard. His research focuses on artificial intelligence

(AI), machine learning, decision support systems, and blockchain technology. He has made substantial contributions to AI and machine learning, developing algorithms to enhance decision-making processes. Additionally, Dr. DIB is actively involved in the development of secure and privacy-centric blockchain interoperability solutions, addressing challenges posed by unique blockchain protocols and security and privacy constraints. He worked as a Research Engineer at the Research Institute of Technology SystemX, France, before joining Wenzhou-Kean University as an Assistant Professor in the Computer Science department in 2020. His work aims to shape the future of AI, machine learning, and blockchain technologies.

**Pierre Valiorgue** is a research engineer at Université Claude Bernard Lyon 1. His research interests are in the field of Decentralized Autonomous Organization, Blockchain and skills management.