A Blockchain Cross-Chain Solution Based on Relays

At present, with the continuous development of blockchain technology and the continuous expansion of its application fields, a large number of blockchain applications that adapt to different scenarios are emerging. However, blockchain systems are independent from each other, and information and value are only shared and circulated on their own chains, making a large number of blockchain projects isolated information and value systems. With the in-depth application of blockchain technology, the demand for data exchange, value circulation, and business collaboration between blockchain applications is increasing, which has led to the increasingly prominent problem of “chain-level islands”. The demand for interconnection between cross-chain applications and data has become an urgent problem to be solved in the development of blockchain. Therefore, the research on scalability and interoperability of blockchain is becoming increasingly popular in the current blockchain field.

Blockchain interoperability technology [1], also known as blockchain cross-chain technology, refers to the ability of effectively exchanging data, value, and functions between different blockchain systems. It involves crossing the trusted boundary of blockchain data (the scope of the consensus mechanism) and achieving credible information acquisition and collaborative status updates among independent blockchain systems, which is consistent with the effect of intra-blockchain operations [2]. According to the degree of structural differences between interoperable blockchains, interoperability technology can be divided into homomorphic expansion technology and heterogeneous interoperability technology [3].

At present, the mainstream cross-chain technologies mainly include four methods [4]: hashed time lock contract [5], notary scheme [6], [7], sidechain/relays [8], and distributed private key control. Among them, the relay technology is essentially a fusion and extension of the notary scheme and sidechain mechanism [9]. The relay chain is a third-party chain built for the system, which is a channel for cross-chain transactions and data information transmission between various chains. It builds a cross-chain operation layer for various blockchains, provides a unified language, and collects inter-chain data status for self-verification, thus achieving the purpose of cross-chain. This technology has high security and important application value for many problems faced by blockchain.

The difficulty in solving the cross-chain interoperability problem for heterogeneous blockchains lies in the fact that each blockchain network is an independently vertical and closed system, as they all have their unique designs and implementations in terms of system architecture, network topology, consensus algorithms, encryption mechanisms, privacy and security mechanisms, etc. When it comes to cross-chain interactions, not only do we need to consider how to convert different data and asset formats into the target format to ensure the security and correctness of the interaction, but also address issues such as contract execution order, transaction confirmation, and the security of cross-chain assets [10]. However, all current cross-chain mechanisms applied in a multi-chain environment have their respective advantages and disadvantages. For instance, the security of the notary scheme relies on the honesty of notaries, which is easy to operate but poses a centralization risk. The hashed time lock contract has decentralized characteristics, but there is a risk of hackers stealing private keys [11]. Relay technology offers high security, but it may introduce additional delays and performance overheads, affecting the efficiency and speed of cross-chain transactions. Distributed private key control avoids the risk of centralization to a certain extent, but smart contracts do not yet support distributed computing and multi-trigger mechanisms, making development difficult. In summary, current cross-chain technologies mainly face issues such as low security, inefficient transaction processing, and unsupported smart contract operations. When facing practical problems, the most suitable method should be chosen according to local conditions.

To address these challenges, this study implements interoperability between heterogeneous blockchains based on relay technology. Specifically, by building a blockchain collaboration platform and deploying consortium blockchains and smart contracts, it realizes functions such as inter-blockchain information inquiry and asset transactions. This approach does not require the participation of a trusted third party, avoiding centralization risks and ensuring the security and correctness of transactions.

The remaining structure of this article is as follows: Section 2 outlines the background related to blockchain interoperability, including existing solutions and related research on cross-chain technology; Section 3 presents the research methods; Section 4 analyzes the experimental results, and Section 5 provides the concluding remarks of this study.

As blockchain enters the 3.0 era, independent blockchains cannot meet the needs of most business scenarios, so collaboration between different blockchains has become an inevitable way to improve the scalability of blockchain. The emergence of cross-chain technology is of great significance to data sharing, value exchange, and business collaboration between different blockchains. At present, some scholars have conducted research on cross-chain technology.

In 2016, ConsenSys, an American company, designed a cross-chain technical solution BTC-Relay based on relay chain, but this technology cannot conduct two-way cross-chain operations [12], only realizing one-way cross-chain from Ethereum to Bitcoin. In 2017, the cross-chain project Wanchain [13] based on Ethereum was launched, which is a public chain cross-chain project adopting distributed private key control technology. It realizes the function of fully decentralized cross-chain asset account management with high security and privacy. In 2018, Yanget al. [14] proposed CVEM, a value exchange mechanism to support cross-chain transfers of different types of tokens. This solution shortened the delay in the trading process to a certain extent and also ensured the security and scalability of value exchange. In the same year, Zhang et al. [15] proposed a multi-party cross-chain protocol based on hash locking to solve the settlement problem of multi-party cross-chain asset transfers. In 2019, the Cosmos project was launched, which is composed of Hubs and Zones. In this project, a blockchain cross-chain communication protocol (Inter Blockchain, IBC) [16] was also designed for communication between Hubs and Zones, allowing different types of blockchains to freely expand and interact with high throughput. However, Cosmos only supports asset transfer and does not support smart contracts and other operations, so its application scenarios are limited. In 2020, Polkadot was officially launched [17], which is comparable to Cosmos, but Polkadot aims to solve the value circulation between blockchains. In the same year, the WeCross white paper [18] was released, indicating that the WeCross blockchain cross-chain collaboration platform can support various forms of cross-chain interactions between applications and blockchains, as well as between homogeneous and heterogeneous blockchains.

In June 2021, Gai et al. [19] proposed a novel sidechain framework called Cumulusbased on BFT, which selects sidechain nodes to communicate with the mainchain in a fair, efficient, and decentralized manner while not compromising the security and efficiency of both consensus protocols. In September 2021, Yin et al. [20] introduced a sidechain construction based on POS and POW, which improved the timeliness of cross-chain transfers through an innovative cross-chain certificate generation process and committee selection method. In the same year, Ghosh et al. [21] addressed the challenges of interoperability and data transfer between private and public blockchains. In January 2022, Baldimtsi et al. [22] put forward the concept of anonymous sidechains, which not only formally defined “anonymous sidechains” but also solved the problem of how multiple anonymous blockchains interact with each other, providing a structure for privacy-preserving Zerocash cross-ledger transactions. In February of the same year, Li et al. [23] proposed a secure and efficient sidechain construction method called SEPoW, suitable for PoW sidechain systems. This method overcomes the drawbacks of centralized exchange of cross-chain assets in participating blockchains. Also in 2022, Westerkamp and Diez [24] introduced a novel verifiable proof-of-stake chain relay cross-chain scheme, greatly promoting the development of proof-of-stake chain technology and enabling multiple proof-of-stake chains to securely interact and jointly participate in global industry applications. Hei et al. [25] built a comprehensive cross-chain trading system called Practical AgentChain, where various tokens can be mapped to corresponding tokens for trading, addressing many challenges of cross-chain transactions. In 2023, Xie et al. [26] achieved asynchronous consensus in relay chain scenarios by transmitting cross-chain messages and transactions through cross-chain gateways.

Although the above research has provided some solutions to break the “data silos” problem of blockchain, there are still some shortcomings. For example, although the importance of cross-chain technology is recognized by the industry, there is relatively little original research on cross-chain technology. Most of the cross-chain research stays at the level of theory, protocols, or models, and there are few actually implemented cross-chain platforms.

Despite the significant progress made in addressing the “data silos” issue in blockchain and providing valuable insights for the application and development of cross-chain technology, there are still limitations and challenges.

Cross-chain technology, as a bridge connecting different blockchain networks, its uniqueness and innovation are crucial to promoting the progress of the entire blockchain industry. However, most current research focuses on theoretical discussions, protocol design, and model construction, which undoubtedly lay a solid foundation for the development of cross-chain technology. Nevertheless, the transition from theory to practice still faces numerous challenges.

The relatively few actual implementations of cross-chain platforms reflect both the many technical, security, and performance issues that still exist in cross-chain technology and the industry's lack of application in this field. To truly solve the “data silos” issue, we need more practical exploration and implementations to verify the feasibility and effectiveness of cross-chain technology.

The challenges of interaction between heterogeneous blockchains lie in issues such as transaction verification, cross-chain transaction management, adaptation of multi-chain protocols, management of locked assets, and security guarantees [27].

To achieve interconnection and interoperability between heterogeneous blockchains, WeCross has designed a unified architectural abstraction for heterogeneous blockchains. From top to bottom, it includes the transaction layer, interaction layer, and data layer, with each layer supporting and cooperating with each other.

(1) The transaction layer encapsulates cross-chain transactions supported by the cross-chain collaboration platform. As shown in Figure 1 [18], it includes two-phase transaction and hashed time-lock contract, providing support for cross-chain transaction verification and asset transfer.

(2) As shown in Figure 2 [18], the interaction layer encapsulates blockchain stubs suitable for adapting to different blockchains, internet protocols for data interoperability between different blockchains, and transaction verification to ensure the credibility of data on the blockchain. It realizes the correspondence of different cross-chain routing and other blockchain systems.

(3) Based on the premise of enabling cross-chain operations, the data layer unifies interface resources. As shown in Figure 3 [18], it encapsulates resources necessary for cross-chain transactions, blockchain structures, and addressing protocol resources.

Taking the FISCO BCOS consortium blockchain and the Hyperledger Fabric consortium blockchain as examples, the meanings of fields such as block height, block hash, previous block hash, and state data hash value in their abstract blockchain structures are the same, with the difference being the Merkle root field used for verification. As shown in Table 1.

Based on the abstract architecture of the blockchain system, heterogeneous blockchains can directly connect to the blockchain cross-chain collaboration platform without any changes. After successful connection, the process of interoperability between heterogeneous chains is shown in Figure 4 [18].

When performing interoperability between heterogeneous chains, the user initiates a cross-chain call first. The business contract registers the cross-chain call request with the bridge contract (used to record contract cross-chain requests). The bridge contract places the received request in a task queue. Finally, the router polls the task queue and forwards and processes the requests in the task queue.

This paper simulates the construction of a comprehensive cross-chain ecosystem. By building the Router, Account Manager, Console, and a visual web-based management console of the blockchain cross-chain collaboration platform WeCross [18], a real cross-chain network system is formed, realizing functions such as cross-chain information inquiry and update, asset trading, etc.

The router first provides a unified interface for heterogeneous blockchains, enabling different blockchains to access the router system in a “non-intrusive” manner through stubs. It abstracts resources on the blockchain, simplifying the complexity of cross-chain interactions. Finally, the router can effectively route the invocation requests to the corresponding blockchains, ensuring the smooth progress of cross-chain operations. In this experiment, two routers are built through ports 8250, 8251, 25500, and 25501 on the machine, with the specific deployment diagram as shown in Figure 5 [18].

The universal account is an abstract object designed to uniformly manage different types of blockchain accounts, representing the identity of users. All blockchains use universal accounts when sending transactions, and all transactions can be mapped back to the corresponding universal accounts. There is a one-to-many relationship between universal accounts and chain accounts (the actual accounts used for transaction signatures when initiating transactions to different types of blockchains), but the relationship between chain accounts and cross-chain accounts is only one-to-one. The diagram of cross-chain accounts is shown in Figure 6.

Account Manager refers to an account that manages universal accounts of the institution. If a user wants to initiate a cross-chain transaction, he needs to log in on the router first. And the router needs to be connected to the Account Manager of its own institution, or else it cannot be accessed. The schematic diagram of the routing account is shown in Figure 7 [18].

As shown in Figure 8 [18], the relationship between the stub and the router is similar to a power strip and a plug. Different types of blockchains only need to customize their own ``plugs" to connect to the router. In this experiment, FISCO BCOS 2.0 consortium blockchain and Hyperledger Fabric 1.4 consortium blockchain were selected as the application chains of the cross-chain system. Therefore, FISCO BCOS-2-Stub and Hyperledger Fabric-1.4-Stub were implemented separately, enabling FISCO BCOS 2.0 consortium blockchain and Hyperledger Fabric 1.4 consortium blockchain to have the ability to connect to the router.

The implementation of the stub mainly includes four modules: BCOS-StubFactory, BCOS-Account, BCOS-Connection, and BCOS-Driver. BCOS-StubFactory is used to define the plugin type and provide the instantiation entry for BCOS-Account, BCOS-Connection, and BCOS-Driver. BCOS-Account represents the blockchain account, which is used for transaction signing and allows customization of information such as chain account name, type, whether it is the default account, etc. BCOS-Connection is responsible for parsing configuration files, initializing the blockchain SDK, providing a unified sending interface for the Driver, interacting with the blockchain, and obtaining resource lists on the blockchain. BCOS-Driver implements the basic interfaces of the stub, calls the sending entry of the BCOS-Connection object to interact with the blockchain, and encodes and decodes blockchain-related data.

In this experiment, the main cross-chain models used include the single-partition single-router model and the single-partition multi-router model.

Single-partition single-router model: For a scenario where users from one organization need to access multiple blockchains simultaneously, a router can be built within the organization and configured with multiple blockchain stubs to connect to multiple blockchains. By configuring different prefixes for the multiple blockchain stubs, users can address and access resources in the network through the router. As shown in Figure 6, users can configure a router with two different blockchain stubs to access resources on two different blockchains.

Single-partition multi-router model: For a scenario where multiple users from multiple organizations want to cross-access each other's blockchains, multiple routers can be deployed and configured with their respective blockchain stubs. The routers interconnect through P2P network protocols, and they automatically synchronize and exchange blockchain stub and resource information among themselves. Users from different organizations can access the corresponding resources by calling their own organization's router, which forwards the requests to other organizations' routers and returns the results along the routing path. As shown in Figure 9 [18], User A and User B can access resources on two different blockchains through the routing network composed of routers.

Smart contracts leverage blockchain technology to enable trusted transactions without a third party. By automatically executing and verifying contract terms, they bring greater efficiency, security, and transparency to various fields. In this experiment, smart contracts with different functions were deployed on the Hyperledger Fabric 1.4 consortium blockchain and the FISCO BCOS 2.0 consortium blockchain to realize various business operations. Part of the resource deployment diagram is shown in Figure 10.

Two-phase transactions are used to ensure the consistency of distributed system transactions, with advantages such as strong reliability, strong universality, and simple implementation. In the WeCross transaction model, the proxy contract is responsible for managing the transaction status and controlling the reading and writing of resources. It also saves the resources, invocation methods, and parameter lists for each execution step in the transaction. The transaction manager is implemented by router.

When a transaction begins, the resources participating in the transaction are recorded and locked by the proxy contract. Subsequent invocation requests must provide the corresponding transaction ID to be executed correctly. When rolling back a transaction, the reverse interfaces are called in the reverse order of the forward interface execution to ensure the consistency of the transaction.

Taking FISCO BCOS 2.0 consortium blockchain and Hyperledger Fabric 1.4 consortium blockchain as examples, the functions of heterogeneous blockchain interoperability were tested in sequence.

The HelloWorld smart contract was deployed on the FISCO BCOS 2.0 consortium blockchain and invoked accordingly. As shown in Figure 11, the get interface in the smart contract was successfully called using the call command, and information deployed on the FISCO BCOS 2.0 consortium blockchain was retrieved. As illustrated in Figure 12, the set interface in the smart contract was successfully invoked using the sendTransaction command, successfully updating the information on the FISCO BCOS 2.0 consortium blockchain.

The sacc smart contract was deployed on the Hyperledger Fabric 1.4 consortium blockchain and invoked accordingly. As shown in Figure 13, the get interface in the smart contract was successfully called using the call command, and information deployed on the Hyperledger Fabric 1.4 consortium blockchain was retrieved. As illustrated in Figure 14, the set interface in the smart contract was successfully invoked using the sendTransaction command, successfully updating the information on the Hyperledger Fabric 1.4 consortium blockchain.

Deploy the Interchain smart contract on the FISCO BCOS 2.0 consortium chain and the Hyperledger Fabric 1.4 consortium chain respectively. Initially, the smart contract on the source chain initiates a cross-chain request to the target chain, invoking the set interface of the target chain's smart contract to update the target chain's data. Subsequently, a callback is triggered, invoking the callback interface of the source chain and updating the data on the source chain.

As shown in Figure 15, before calling the smart contract, the data on the two consortium chains is “talk is cheap, show me the code”. After executing the sendTransaction command, the data on both consortium chains is simultaneously updated to ``HelloWorld", indicating a successful synchronization of data between heterogeneous blockchains through a single command.

Assuming the existence of two cross-chain accounts, where each account is registered on a different consortium chain: one on Hyperledger Fabric 1.4 consortium chain and the other on FISCO BCOS 2.0 consortium chain.

On the Hyperledger Fabric 1.4 consortium chain, a smart contract is deployed and instantiated. The assets of this blockchain are authorized through a custodial account. Subsequently, the address of the asset issuer and the asset balance are viewed and recorded. On the FISCO BCOS 2.0 consortium chain, a smart contract is deployed, and the asset owner needs to grant transfer permission to the smart contract.

Finally, the smart contract is initialized, and the address and balance of the asset issuer are viewed and recorded.

From Figure 16, Figure 17, Figure 18, Figure 19, the entire process of cross-chain asset transactions can be observed. Initially, the balances of the asset sender and receiver are checked separately. Subsequently, the asset sender on both blockchains sequentially creates transfer proposals, and finally, the router automatically completes the cross-chain transfer. On the Hyperledger Fabric 1.4 consortium chain, the sender and receiver transact 700 units, while on the FISCO BCOS 2.0 consortium chain, the sender and receiver transact 500 units, aligning with expectations.

Breaking the “data silos” problem between heterogeneous blockchains effectively is a significant challenge hindering the collaborative development of blockchain applications, attracting widespread attention from academia and society. In this context, this paper constructs a blockchain cross-chain collaboration platform, simulating a real cross-chain network system, and achieves the functionality of synchronizing information and exchanging assets between heterogeneous blockchains.

The research findings indicate that when using the WeCross blockchain cross-chain platform, it is necessary to implement stubs for heterogeneous blockchains to enable blockchain integration into routers and subsequently execute follow-up operations. To ensure the consistency and accuracy of operations on the blockchain, a two-phase transaction is employed. When developing business functions, rollback operations must be implemented. The blockchain cross-chain collaboration platform built using relay technology can be used to address the challenges of cross-chain interoperability, effectively enhancing interoperability between different blockchain systems, securely and efficiently enabling cross-chain asset transfer and information exchange. However, the implementation of business functions such as information synchronization and asset exchange between heterogeneous blockchains relies on the writing and deployment of smart contracts.

This paper has made significant progress in building a blockchain cross-chain collaboration platform based on relay technology, but there are still some aspects to be improved. Firstly, the current platform adopts the centralized CA technology for identity authentication, which meets the functional requirements to a certain extent, but there are certain limitations in terms of security and decentralization. In the future, we can consider using DID technology for identity authentication. DID technology assigns a unique, self-sovereign digital identity to each entity, which can greatly enhance the security of the system, prevent tampering and forgery of identity information, and further strengthen the decentralized characteristics of the cross-chain system, ensuring that each participant can interact in a fair and transparent environment.

Secondly, the cross-chain models used in this experiment are mainly single-partition single-route and single-partition multi-route models, which simplify the complexity of the problem to a certain extent. In the future, we should consider using a more complex multi-partition multi-route model to handle larger-scale transactions and data exchange, and solve problems that are closer to the complexity and diversity of real-world business.