A secure cross-domain interaction scheme for blockchain-based intelligent transportation systems

Cross-chain communication

Due to the diversity of blockchain infrastructure and the lack of unified architectural standards within the industry, research on blockchain and its interoperability solutions has become challenging (Belchior et al., 2021). In recent years, with the problem of blockchain interoperability being studied in depth, the concept of cross-blockchain communication has been considered by scholars as a necessary condition for solving blockchain interoperability. Cross-chain communication is a process that provides value to cross the barriers between chains and facilitates information transfer between one or more chains. Cross-chain communication involves two blockchains: the source and target chains. Transactions are initiated through the source chain and executed by the target chain.

Many articles have analyzed and classified cross-chain solutions. In 2016, Buterin (2016) divided cross-chain solutions into three categories, including notary mechanisms, relays, and hash locking. Based on Buterin’s research, Koens & Poll (2019) divided relays into one-way and two-way relays and evaluated these cross-chain solutions. Wang (2021) classified blockchain cross-chain research into chain-based, bridge-based, and dApp-based approaches. Qasse, Abu Talib & Nasir (2019) summarized four solutions for inter-blockchain communication, including sidechains, blockchain router, smart contracts, and industry solutions.

The cross-chain communication protocol is also an important part of achieving cross-chain interoperability. The cross-chain communication protocol refers to the process of enabling blockchain interoperability by defining a series of communication data formats, protocol specifications, and consensus protocols (Meng et al., 2022). Zamyatin et al. (2021) defined a universal cross-chain protocol as a process in which a pair of chains interact with each other to achieve synchronization and consistent states between the chains and determined the primary stages of the universal cross-chain protocol. The cross-chain communication protocol is a protocol that enables processes in the blockchain to meet validity, atomicity, and timeliness requirements.

Thus, research into the implementation of cross-chain communication technology among heterogeneous blockchains is important to the development of the cross-chain field. However, the differences in underlying standards for blockchains provide opportunities and produce many challenges to cross-chain operations.

LibP2P

LibP2P (Dias & Benet, 2016) is a modular network stack and library for building P2P networks that originated from the open-source project IPFS. The modular design of libP2P also allows it to be used as a P2P network layer for building various decentralized applications. Currently, blockchain projects such as Ethereum 2.0 (Schwarz, 2019), Polkadot (Wood, 2016), Filecoin (Psaras & Dias, 2020), BitXHub (Ye et al., 2020), chose to use the libP2P library to build the network layer of their systems. LibP2P has many excellent features, such as node discovery (i.e., the ability to discover other nodes in the P2P network), routing, support for multiple data transmission protocols, protection of transmitted data privacy, and various encryption and identity authentication mechanisms. LibP2P uses an encoding scheme called “multiaddr” to unify different protocol address formats and assigns a unique network-wide ID to the nodes in the network. By using the node ID, the issue of man-in-the-middle attacks can be effectively addressed. Due to its flexibility and scalability, libP2P has been widely used in distributed file systems and the construction of decentralized applications.

In the application scenario of blockchain, libP2P is an extremely useful tool as it enables fast data transmission. In addition, within libP2P, when two peers establish a connection, it creates a bidirectional and secure communication channel, allowing the specification of protocols used to ensure secure bidirectional communication. Experiments have demonstrated that libP2P greatly simplifies the development of P2P applications and effectively addresses most inherent issues in P2P networks (Guidi, Michienzi & Ricci, 2021).

Similarly available for building P2P networks, the BitTorrent file sharing protocol (Xia & Muppala, 2010) is mainly used for the distribution and download of large-scale files. Although both libP2P and BitTorrent can be used to build a P2P network, their main application scenarios and design goals are slightly different. LibP2P is more versatile and flexible, suitable for constructing various decentralized applications and the networking layer of blockchain projects, while BitTorrent focuses on efficient sharing and downloading of large files. It is worth noting that libP2P is committed to providing interoperability, enabling nodes with different implementations to communicate with each other. This means that libP2P can be used to build networks across different blockchain platforms or distributed applications. Therefore, in this article, libP2P is selected for interconnecting communication between relay nodes.

Smart contract

The concept of smart contracts was first proposed by Nick Szabo in 1994 and is defined as “computerized transaction protocols that execute the terms of a contract” (Szabo, 1997). However, due to limitations in computing power and application scenarios in the early days, smart contracts did not receive much attention from researchers. In 2013, Buterin (2014) introduced the Ethereum blockchain platform, which provided the Turing-complete programming language Solidity for writing smart contracts, and smart contracts were then applied to the blockchain. In blockchain technology, smart contracts can be considered a specific type of software program that is deployed and executed by a distributed ledger (Kannengießer et al., 2020). Smart contracts are crucial for facilitating, verifying, and executing transactions without the involvement of third parties in the blockchain.

Smart contracts can be classified into two types: deterministic contracts and non-deterministic contracts (Morabito, 2017). Deterministic contracts, also known as oracles, do not require external information from outside the blockchain during runtime, while non-deterministic contracts, on the contrary, rely on external information. Smart contracts can be developed and deployed on different blockchain platforms, such as Ethereum, Bitcoin, Hyperledger Fabric, and FISCO BCOS (Alharby & van Moorsel, 2017). Each platform offers smart contracts with different functionalities and programming languages. Deploying contracts on consortium blockchain platforms can provide higher performance and privacy compared to public and private blockchains.

There are also various programming languages for smart contracts, such as Solidity, Vyper, Hawk, and Serpent (Varela-Vaca & Quintero, 2021). Each language has its unique advantages and suitable scenarios. For example, Solidity is the most commonly used smart contract language on Ethereum, with extensive development tools and support. Vyper (Kaleem, Mavridou & Laszka, 2020) focuses on security and ease of analysis, while Hawk (Kosba et al., 2016) interacts with the blockchain using cryptographic primitives to protect transaction privacy. Smart contracts are critical to the operation of a blockchain because even minor errors or flaws can lead to security issues. Additionally, the privacy, performance, and scalability issues involved in smart contracts are also critical (Macrinici, Cartofeanu & Gao, 2018).

Heterogeneous cross-chain interaction mechanism based on relay nodes

To achieve trusted interconnection and sharing of data among various types of blockchains across regions and organizations in the ITS, as well as the high-throughput and low-latency transaction requirements of this application scenario, this article proposes a heterogeneous cross-chain interaction model based on relay nodes to meet the needs of cross-chain interoperability in intelligent transportation scenarios. The model uses a cross-chain architecture with multiple relay nodes, where each blockchain is connected to a corresponding relay node in a one-to-one manner, and each relay node only connects to one chain. The relay nodes are interconnected through libP2P for node-to-node communication, forming a relay node chain where nodes can connect and forward requests to each other. The cross-chain transactions in the communication process are defined according to the RNCCP cross-chain data transmission protocol, and data flow between different blockchains and secure contract calling are achieved via the interaction between relay nodes.

Figure 2 shows the detailed architecture of the heterogeneous cross-chain model based on relay nodes in ITS. The architecture consists of relay nodes, relay node blockchains, cross-domain institutions, corresponding application blockchains, and smart contracts.

The relay node chain is a blockchain cross-chain network formed by interconnecting relay nodes, and after identity authentication, nodes in the network can directly interact and communicate using libP2P.

The relay node chain includes three types of relay nodes: master node, cross-chain nodes, and light nodes. In ITS, there is only one master node in the cross-chain network, which is represented by the relay node of the transportation department chain. This node has all cross-chain transaction data and corresponding proof information and conducts identity authentication and data supervision for other relay nodes that join the cross-chain network. Nodes in the cross-chain network other than the master node can be cross-chain nodes or light nodes. The difference is that nodes participating in cross-chain interaction on both sides of the transaction are cross-chain nodes, which store the cross-chain transaction data of both parties. Other nodes that do not participate in cross-chain interaction in this transaction act as light nodes, which store only transaction data related to their own cross-chain nodes.

To meet the cross-chain communication needs of ITS, the application chains of each institution must deploy corresponding cross-chain contracts. The application chains access the cross-chain network through the relay node, use cross-chain contracts to exchange data with user contracts, and receive cross-chain requests from users, thereby achieving interchain data exchange and communication. For example, in Fig. 2, we consider transport enterprise A and transport sector B as an example. These entities deploy application chain A and application chain B, respectively, and deploy the corresponding cross-chain contracts and user contracts on the blockchain. Chains A and B are connected through the relay node chain, enabling data interaction and communication between user L of enterprise A and user Z of transport sector B.

To improve cross-chain transaction validation efficiency and cross-chain storage space utilization, this model designs different storage schemes for different types of relay nodes. First, the master node in the cross-chain network stores all cross-chain transaction information that occurs on the relay node chain, while cross-chain nodes and light nodes only must store transaction data related to themselves and save block header information for subsequent verification. Then, non-cross-chain transactions that occur only on a single blockchain do not need to be processed by the relay node and are only processed, verified, and stored by the business nodes of this blockchain. This process improves the efficiency of cross-chain transaction processing and reduces unnecessary storage costs.

Secure access and communication of IBE-based relay nodes

Relay node secure access and communication scheme

In ITS, the corresponding relay nodes of the institutional chain must undergo identity authentication before performing cross-chain operations. In the relay node access scheme based on IBE, the unique ID of the relay node is used as the public key to replace the digital certificate issued by a third party, which simplifies the authentication process.

This solution requires initialization first, and the PKG of the transportation government department runs the Setup algorithm to generate the system parameters PK $\left\{\mathrm{e},P,P_{\mathrm{p}\mathrm{u}\mathrm{b}},H_1,H_2\right\}$ and the master key MSK of the cross-chain network. $\mathrm{e}:G_1\times G_1\to G_2$ is called bilinear mapping, where G1 and G2 are two q-order cyclic groups; G1 is the additive group, G2 is the multiplicative group, and they satisfy the following equations: $\mathrm{\forall }P,Q\in G_1,\mathrm{a}\mathrm{n}\mathrm{d}\mathrm{\forall }\mathrm{a},\mathrm{b}\in Z_{\mathrm{q}},\mathrm{a}\mathrm{l}\mathrm{l}\mathrm{s}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{s}\mathrm{f}\mathrm{y} e(aP,bQ)=e(P,Q{)}^{ab}$. Then, a hash function is selected to generate keys and authenticate identities:

(5) $$\begin{gathered} H_1:\{0,1{\}}^{\ast }\to G_1 \\ {H}_2:G_2\to \{0,1{\}}^{\mathrm{n}} \end{gathered}$$when a relay node first connects to the cross-chain network, it must be authenticated by the transportation department and request a private key from the PKG in the ITS cross-chain network. This private key is used for identity verification and secure data transmission during cross-chain transactions.

By running the Extract algorithm, the PKG maps the relay node’s identity $ID\in \{0,1{\}}^{\ast }$ to a point ${\mathrm{Q}}_{\mathrm{I}\mathrm{D}}$ on an elliptic curve with order q, which is the public key $Q_{ID}=H_1(ID)$, and then generates the private key $S{K}_{ID}=\mathrm{MSK}\cdot Q_{ID}$ for the node and sends the $S{K}_{ID}$ to the relay node in a secure manner.

Once the relay node has connected to the cross-chain network, its corresponding institutional chain can directly use the relay node’s identity ID for identity verification and cross-chain data communication with other institutional chains. To ensure the security of cross-chain transactions between relay nodes, the transactions must be encrypted.

The process of encrypted communication based on IBE is as follows: when relay node A of institutional chain A sends a communication message M to relay node B of institutional chain B, the proposed method calculates $Q_{ID}=H_1(ID)$ using the identity ID of relay node B. Then, the algorithm randomly selects $\mathrm{r}\in Z_{\mathrm{q}}^{\ast }$, and the Extract algorithm is executed to generate the ciphertext $C=⟨U,V⟩$ corresponding to M based on the PK and $Q_{ID}$, where $U=\mathrm{r}P$, $V=M\oplus H_2\left({\mathrm{g}}_{\mathrm{I}\mathrm{D}}^{\mathrm{r}}\right)$, ${\mathrm{g}}_{ID}=\mathrm{e}\left(P{K}_{ID},P_{\mathrm{p}\mathrm{u}\mathrm{b}}\right)$. After receiving the ciphertext C, relay node B runs the Decrypt algorithm, utilizing its private key $S{K}_{ID}$ and PK to decrypt the C, message plaintext $\mathrm{M}=\mathrm{V}\oplus {\mathrm{H}}_2\left(\mathrm{e}\left(\mathrm{S}{\mathrm{K}}_{ID},\mathrm{U}\right)\right)$. The specific encryption communication process is shown in Fig. 3.

Cross-chain communication protocols for heterogeneous chains

As an important component of cross-chain design in the ITS, the cross-chain communication protocol allows heterogeneous blockchains to access the cross-chain platform without changing the underlying structure, and perform unified cross-chain operations. This article proposes a generic interchain message transmission protocol, the RNCCP, which can perform trusted cross-chain contract interoperability and data transmission. The protocol defines a unified data structure and operation object for cross-chain transactions, defines the lifecycle of cross-chain transactions between different heterogeneous blockchains in the ITS, and provides a consistent invocation interface to the upper-level cross-chain platform.

RNCCP data structure

The RNCCP protocol is applied to relay nodes and focuses on the RNCCP data structure, which provides a uniform definition of the necessary fields of the cross-chain transaction object constructed by the relay node, as shown in Fig. 4. The key fields are explained as follows.

CrossTxNo: This field contains the unique number corresponding to the cross-chain transaction and is composed of the source chain number, the destination chain number, and the self-incrementing number corresponding to that source and destination chain stitched together. The cross-chain transaction number is generated by the relay node; thus, all blockchains participating in cross-chain transactions must maintain a ledger with all blockchain numbers in the corresponding relay node.

SrcContractInfo and DestContractInfo: These fields contain the contract name and contract version information of the corresponding cross-chain contract, respectively.

CrossChainData are byte data that are parsed into JSON cross-chain transaction data corresponding to different transaction types.

Proof: This field contains legitimacy verification information of the cross-chain transaction, which must be constructed by multiple relay nodes in collaboration. The proof contains the block number corresponding to the cross-chain transaction, the Merkle root hash and the signature of the cross-chain node for this transaction. Proof is used for transaction atomicity verification, signature verification, block header verification, etc.

The relay node parses the cross-chain message initiated by the source chain, verifies the transaction and signs it; constructs the cross-chain message as a cross-chain transaction object that conforms to the RNCCP data structure; and sends it to the relay node of the destination chain for processing.

Lifecycle of cross-chain transactions

The RNCCP protocol defines the lifecycle of cross-chain transactions, with different transaction states corresponding to different stages. Figure 5 shows the state transition diagram for the cross-chain transaction lifecycle. The StartCrossTx state indicates the beginning of a cross-chain transaction, the Executed state indicates that the cross-chain transaction has been executed, and the Completed state indicates that the cross-chain transaction has been completed.

The state of a cross-chain transaction is created and transitioned according to the different cross-chain steps. During the cross-chain process, the cross-chain smart contract controls the transition of the cross-chain transaction lifecycle and implements the logic of the transition between the different states. When initiating a cross-chain transaction, the “current state” field is set in the transaction object’s data structure to indicate the transaction’s state. This state can be StartCrossTx, Executed, or Completed. Each independent cross-chain transaction begins in the null state, indicating that the transaction does not exist. The cross-chain transaction is created by the cross-chain contract on Chain A and initially assigned the StartCrossTx state. Then, the cross-chain transaction is executed on Chain B’s cross-chain contract and assigned the Executed state. Finally, the entire cross-chain transaction is completed by the cross-chain contract on Chain A and assigned the Completed state.

Cross-chain interaction process

The proposed cross-chain model primarily relies on the cross-chain contracts and relay nodes of both sides for cross-chain interaction. One or more corresponding cross-chain contracts must be deployed on the application chain. The application chain accesses the cross-chain network through the relay nodes, transfers data with user contracts through cross-chain contracts, and receives cross-chain requests from users.

There are three primary types of requests in the cross-chain interaction process: contract invocation, event listening, and relay node interaction. The contract invocation phase primarily involves the user, the user contract, and the cross-chain contract, providing the user with interfaces for cross-chain interaction. Event listening is for cross-chain contracts and relay nodes, and cross-chain nodes listen to cross-chain events of the contracts to process them accordingly. Relay node interactions are node calls between the blockchains involved in the cross-chain.

Considering the example of user A in transportation company chain A that conducts a one-way cross-chain data interaction with user B in transportation department chain B, the specific cross-chain process is shown in Fig. 6.

Step 1: The user of chain A creates the user contract and invokes the user contract to send the cross-chain request data.

Step 2: After receiving the cross-chain request and data from the user, the user contract calls the cross-chain contract of chain A and sends a cross-chain transaction request (CCTX request), setting the state of the cross-chain transaction to “Current-State=NULL”.

Step 3: After receiving the CCTX request, the cross-chain contract of chain A creates a unique cross-chain transaction number “CrossTxNo=[SrcChainNo:DestChainNo:Number]” by splicing the source chain number, destination chain number, and incremental code. Then, the contract generates a cross-chain transaction object and sets the state of the cross-chain transaction to “Current-State=StartCrossTx”. Finally, it sends the “startCrossTxEvent” event with the cross-chain transaction object to indicate the start of the cross-chain transaction.

Step 4: The relay node corresponding to chain A listens asynchronously for events on the blockchain.

Step 5: After listening to the “startCrossTxEvent” event and the cross-chain transaction, the relay node of chain A encapsulates the cross-chain transaction according to the defined RNCCP, and transmits the encapsulated transaction data to the relay node of chain B using libP2P.

Step 6: After receiving the cross-chain message from the node of chain A, the relay node of chain B validates the proof field of the cross-chain transaction. After verification, the relay node converts the cross-chain transaction into a transaction object that can be accepted by blockchain B according to the RNCCP. Then, the relay node calls the cross-chain contract to parse the cross-chain transaction object and perform the corresponding cross-chain operation based on the parsed cross-chain object.

Step 7: The B-chain cross-chain contract executes the cross-chain operation and records it on the blockchain. After execution, the contract sends the “ExecutedEvent” event and sets “Current-State=Executed”, indicating that the cross-chain operation has been completed.

Step 8: The relay node of chain B asynchronously listens to the “ExecutedEvent” event sent by the cross-chain contract.

Step 9: The relay node of chain B encapsulates and processes the event and the result of the cross-chain transaction and then sends the cross-chain response (CCTX response) to the cross-chain node of chain A.

Step 10: After receiving the CCTX response sent by the relay node of chain B, the relay node of chain A parses and verifies the transaction according to the RNCCP, and calls the cross-chain contract to send the transaction result.

Step 11: After receiving the cross-chain transaction result, the cross-chain contract of chain A records the transaction result on the blockchain and then calls the user contract to send the result.

Step 12: After receiving the result, the user contract of chain A returns the cross-chain result to user A.

The cross-chain transaction process is then fully executed, and user B on the blockchain can query the cross-chain result by deploying user contract B on chain B.

Cross-chain interaction smart contract

As the code in the blockchain can be automatically executed according to the event trigger, the execution logic of smart contracts is important. The cross-chain interaction smart contract designed in this article serves as a bridge connecting users, blockchains, and relay node chains (see Fig. 7), and primarily implements the cross-chain interoperability logic processing between heterogeneous chains. The cross-chain contract inherits the storage contract and contains two contract reference objects (ADD and STR-OPE) and the algorithm for cross-chain interaction.

1. Parent contract. The storage contract defines the related cross-chain contract events, contract objects, and necessary parameters in the cross-chain process. The names and descriptions of the corresponding cross-chain contract events and parameters are shown in Table 1. The data structure of the contract objects is shown in Fig. 4 in the previous section.

2. Contract objects. The ADD and STR-OPE contracts are reference objects. The ADD contract sets relevant information such as the set of relay nodes and blockchain numbers. The STR-OPE contract contains algorithms for processing string-type data for cross-chain contract data processing.

3. Cross-chain interaction algorithm. In order of execution, we describe the key algorithms involved in the cross-chain interaction process in detail as follows.

startCrossChainTx(): As shown in Algorithm 1, this algorithm is called by the user contract on the blockchain. Firstly, it determines the transaction type based on the “txType” field. Then, it creates a cross-chain transaction object to initiate the cross-chain transaction. Finally, it submits the startCrossChainTxEvent on the blockchain, which is provided for listening by the relay nodes. The input of this algorithm includes relevant information about the cross-chain transaction object. This algorithm corresponds to the “StartCrossTx” state in the cross-chain transaction lifecycle. The other two states, Executed and Completed, have similar execution and completion algorithms, with the only difference being the need for ledger-related operations in the cross-chain transaction execution algorithm.

sendAckedTx(). As shown in Algorithm 2, this algorithm is called by the relay node to submit the cross-chain acknowledgment transaction and parse the proof information. Firstly, the algorithm checks if the caller is a relay node, and then verifies if the contract version is compliant. Next, based on different transaction statuses, it parses data and constructs a cross-chain transaction object in accordance with the RNCCP structure. Finally, the algorithm sends the sendAckedEvent on the blockchain.

Relay nodes

As an important bridge that connects different regional blockchains in ITS, the cross-chain network composed of relay nodes must have the following functions: (1) secure data transmission between nodes; and (2) trusted node identity authentication. To achieve secure and interactive communication between nodes in the cross-chain network, this study uses libP2P to build a peer-to-peer communication network between nodes.

The relay node module includes communication between nodes and communication between nodes and blockchains. Communication between nodes is based on the libP2P framework, while communication between nodes and blockchains is implemented using event listening mechanisms and the blockchain SDK. The primary algorithms for node-to-node communication and node-to-blockchain communication are given below.

nodesCommunication(): As shown in Algorithm 3, this algorithm creates p2p nodes for two relay nodes A and B. We assume that node A is the server and responsible for listening, while node B is the client and responsible for connecting to the server and establishing a communication channel with the server. Node A opens a listening port, and node B connects to node A using the encoding address. Then, the two nodes can communicate in encrypted channels with multiple concurrent streams. The inputs for this algorithm are the listening port and address of node A and the host object in the P2P network. The algorithm then determines whether node A is the server or the client based on whether the node address is empty or not. If the address is empty, then it is the server, and the port listening on the server side is opened. When a client node connects, according to the protocol specified by the PID, it begins the read-and-write flow. If the address is not empty, it means that the node is a client. After parsing the address and reading the multiaddress of the server, the multiaddress of the node is added to the peerstore. Then, the communication stream is opened between the two nodes, and a non-blocking read-and-write byte stream and a read-and-write process are created to start communication.

contractEventListener(). As shown in Algorithm 4, this algorithm acts as a bridge for intercommunication between relay nodes and the blockchain. It utilizes an event listening mechanism to monitor events occurring in the contract. It calls back the client with the relevant cross-chain events that happened on the blockchain. Depending on different cross-chain events, it processes them accordingly. For example, when the startCrossChainTxEvent is detected, the source chain’s relay node forwards the cross-chain transaction information to the destination chain’s relay node. Similarly, when the “executedEvent” is detected, it indicates that the cross-chain operation has been executed in the destination chain’s contract, and the destination chain’s relay node forwards the relevant information back to the source chain’s relay node.

IBE-based authentication of relay nodes

When a relay node applies to join the network, it must communicate with the master node. After it is authenticated by the master node, it can join the cross-chain network. Once the relay node has been authenticated, its multiaddress will be added to the peerstore, and the address will be broadcast to other nodes in the network. Each node in the cross-chain network maintains a ledger with the multiple addresses of all nodes that are used for subsequent communication between the nodes.

RelayNodeAuthentication(): As shown in Algorithm 5, this algorithm is used for identity authentication of the relay node when joining the network. The algorithm is based on the IBE mechanism, which generates a public-private key pair for the node at startup and is used to encrypt and decrypt the node’s identity. Identity is authenticated by the master node corresponding to the transport department chain in the ITS. If the identity matches, the authentication is passed, and subsequent cross-chain data interaction can be performed.

Setup

In order to test the feasibility and performance of the proposed solution in this article, we use Hyperledger Fabric and FISCO BCOS to build a network environment for the heterogeneous cross-chain interaction architecture based on relay nodes. The cross-chain network consisted of 19 nodes. Specifically, the HyperLedger Fabric blockchain network was set up with 11 nodes, comprising three orderer nodes and four organizations, with each organization having two peer nodes. The Raft consensus algorithm was utilized for this blockchain network. The FISCO BCOS network was deployed with three groups, totaling eight nodes, and the Raft consensus algorithm was also chosen as the consensus mechanism for this blockchain. The experimental environment is Intel Xeon E5 CPU, 64 GB of RAM, 35 MB of L3 cache, and the Ubuntu 18.04 operating system.

We wrote and deployed smart contracts for cross-chain communication and used Java and Go languages to write corresponding relay node execution algorithms for two institutional chains. Then, we utilized the NGSIM dataset to simulate a scenario of cross-chain interaction between two heterogeneous institutional chains in ITS, and Fig. 8 shows the results of the two traffic data reads across the chains. Finally, we employed Hyperledger Caliper and JMeter tools to script performance evaluation tests for the cross-chain smart contract and the overall cross-chain process.

The NGSIM dataset includes four different scenarios from six cities in the United States: US-101, I-80, Lankershim, and Peachtree. US-101 and I-80 record the trajectories of vehicles on highways, while Lankershim and Peachtree record the trajectories of vehicles on city roads. The data fields in this dataset are explained in Table 2. For testing, we randomly selected data from this dataset to simulate 10,000 concurrent traffic services.

Complexity analysis

Before presenting the numerical evaluation results, we analyze the complexity of the five algorithms in the proposed scheme. Algorithm 1 submits an event on the blockchain after creating a cross-chain transaction object. The time complexity of this algorithm can be represented as O(1). Algorithm 2 is used by relay nodes to submit cross-chain transaction information, construct transaction objects compliant with RNCCP structure, and parse Proof information. The time complexity of these operations is also O(1); therefore, the time complexity of this algorithm can be represented as O(1). Algorithm 3 is used for communication between relay nodes, assuming that the number of relay nodes is m. Nodes connect by retrieving “multiaddr” encoded addresses. Once connected, nodes can engage in concurrent communication, and connected relay nodes can communicate directly within a fixed time, avoiding unnecessary time costs for reconnection. The time complexity of establishing connections is O(m), and the time complexity of concurrent communication is O(1). Thus, the total time complexity of this algorithm is O(m). Algorithm 4 achieves communication between relay nodes and the blockchain through event listening. Assuming that the total number of cross-chain events on a single blockchain is N, and the number of cross-chain events from the start block to the end block within the specified time is n (n<<N). This algorithm iterates through n cross-chain events and executes different cross-chain event handling methods. The time complexity of executing event handling methods is O(1), so the time complexity of Algorithm 4 is O(n). Algorithm 5 mainly involves identity encryption and decryption, as well as the transmission of ciphertext between relay nodes and main nodes. Since relay nodes can only establish connections with main nodes after identity authentication, the time complexity of this algorithm is O(m).

In summary, based on Fig. 6, the cross-chain interaction process, for a blockchain that joins this cross-chain network for the first time, incurs the longest overall cross-chain time consumption, with a time complexity of O(2m+2n).

Performance evaluation

We used widely recognized metrics in the field of cross-chain research, namely execution time and gas consumption, to evaluate the performance of our approach. The experiments in this study were divided into three groups. The first group of experiments tested the overall performance of our proposed cross-chain solution, and this group of experiments ignored the impact of transaction initiation time. The second group of experiments tested the performance of the cross-chain contract algorithm, evaluating the smart contract algorithms’ performance under different levels of concurrent traffic services. The third group of experiments tested the gas consumption required for executing cross-chain operations. This was done to evaluate the computing and storage resources consumed by cross-chain transactions. This experiment was conducted on the Ethereum platform.

To make the experimental presentation more clear, we give a detailed description of the relevant experimental parameters in Table 3.

Experiment 1. We conducted performance testing on the complete cross-chain process (from user request initiation to receiving cross-chain data) of the proposed cross-chain mechanism in this article using JMeter. To evaluate the performance of our solution, we compared the time of the complete cross-chain process with the solutions proposed by Lu et al. (2023) and Xiong et al. (2022). Furthermore, in order to better evaluate whether the proposed solution is suitable for a multi-transaction, high-concurrency ITS cross-chain network, we used the NGSIM dataset to set up 10,000 cross-chain traffic services. The number of concurrent services was set to 50, 100, and 200, respectively, and we conducted tests and statistics on the time of the complete cross-chain process. We divided the 10,000 transactions into rounds of 100 transactions each and calculated their averages for evaluation.

Based on the results shown in Figs. 9 and 10, our proposed solution demonstrated an overall cross-chain average time below 2,500 ms for concurrent transaction numbers of 50, 100, and 200, ranging from 1,868 to 2,409 ms. In comparison, the scheme presented by Lu et al. (2023) showed a stable inter-chain communication delay at around 3,000 ms, and the solution proposed by Xiong et al. (2022) remained stable at around 2,500 ms. In addition, compared with Wu (2021), due to the participation of the relay chain, the burden of inter-chain interaction is increased, and the average cross-chain time overhead of this article is about 10.47 s. In summary, our scheme is more effective than Lu et al. (2023) and Xiong et al. (2022) in terms of cross-chain performance. Furthermore, our scheme exhibits minimal fluctuations between 10–90 transaction rounds, demonstrating excellent stability and suitability for ITS cross-domain network environments.

Experiment 2. To study the efficiency of various algorithms in the cross-chain contract under different concurrent traffic service scenarios, we conducted experiments using Hyperledger Caliper. We simulate different transaction concurrency and loads by controlling the transaction sending rate (Send Rate). We set the transaction sending rate per second in the ranges (100, 650) and (1,600, 2,200), with an interval of 50 transactions per second, to test the impact of different concurrent transaction requests on the performance of the cross-chain contract. We measured the performance of different cross-chain functions, including throughput, average transaction execution time, and CPU resource consumption ratio, as shown in Figs. 11–13. The test results showed that with the increase in cross-chain transaction concurrency, the throughput of the cross-chain algorithms significantly improved. The throughput of the cross-chain read operation reached 2100 TPS, and the average execution time remained stable below 10 ms. The average execution time of the cross-chain write operation was approximately 500 ms, meeting the requirements of ITS for cross-chain read operations.

Experiment 3. We deployed the cross-chain contract on the Ethereum network to test and evaluate the cost of cross-chain transactions. Gas consumption is used to measure the transaction cost, which depends on factors such as the complexity of the smart contract, the computational resources required for execution, and the network transmission cost.

In Table 4, we list the costs of the main functional functions of the cross-chain contract, including gas consumption, corresponding ETH, and USD prices. The table is calculated based on the gas price (20 Gwei) and 1 ETH price ($1,849.84) on July 24, 2023. From the table, we can see that the deployment of the cross-chain contract incurs the highest gas cost, reaching 7,877,145 gas, but this situation only occurs once. In addition, the gas cost for initiating cross-chain transactions and submitting acknowledgment transactions is also high, as these two functions involve parsing cross-chain data, transaction creation, data verification, and complex operations related to the ledger. For sending and creating transactions, the gas spent is directly related to the size of the data contained in the transaction. For transactions such as initialization, setting relay node addresses, and obtaining cross-chain transaction objects, the gas spent is fixed, because these algorithms only need to set addresses or cross-chain transaction ID as parameters.