Blockchain Interoperability in Data Exchange Logistics Integration

Abstract

Logistics companies are increasingly adopting private blockchains for enhanced data management because of the trends in cooperation. Nevertheless, this practice poses new challenges concerning the security and sharing of data. The real-time nature and diversity of logistics data increase the difficulty of protecting the data. Additionally, when transportation information changes, downstream enterprises must promptly adjust their production plans to accommodate these alterations. The strict access controls of private blockchains can obstruct downstream enterprises from obtaining data, posing a challenge to the overall operational efficiency. In this paper, we propose an innovative logistics data protection scheme that employs private set intersection (PSI) and blockchain cross-chain technology to achieve data security. In our scheme, logistics companies within the logistics consortium are added as trusted agents to the public blockchain, enabling downstream enterprises to acquire logistics data integration from the public blockchain. Utilizing an RSA-based PSI protocol, our approach enhances exchange efficiency while protecting private data without transmitting additional information. We evaluate the performance of the proposed solution through a series of experiments, and the results demonstrate that our solution can achieve secure and efficient logistics data exchange.

1. Introduction

Blockchain technology has been integrated with the logistics industry, giving rise to new concepts like “smart logistics” or “Logistics 4.0” [1]. Technical terms are shown in

Table 1. Technology terminology table.

Term	Definition
Smart Logistics	Use of advanced technologies like Internet of Things (IoT) and Artificial Intelligence (AI) to enhance logistics efficiency and transparency.
Logistics Company	A business entity primarily responsible for the transportation and distribution of goods.
Downstream Enterprise	In this context, it specifically refers to automotive manufacturers who receive parts or raw materials from logistics companies and engage in the assembly and production of vehicles.
Logistics Data Integration	Refers to the process of integrating various logistics-related data from different sources and systems into a unified platform to enable analysis, processing, and utilization.
Blockchain	A secure, immutable distributed ledger technology enhancing transaction transparency and security.
Cross-Chain Technology	Enables interoperability and asset exchange between different blockchain systems.

. Benefiting from the key characteristics of blockchain technology, such as transparency and tamper resistance [2], logistics companies use blockchain technology to address issues related to data opacity, data leakage, and coordination [3], thereby enhancing the visibility, improving the efficiency of the logistics system, and reducing operational costs.

Due to the sensitive business and customer data in the logistics industry, protecting data security is very important. To enhance control over data access permissions and safeguard sensitive data, a considerable number of logistics companies opt to establish private blockchains. However, the utilization of private blockchains introduces certain challenges, among which is the comparative difficulty of data interaction between distinct private blockchains. For example, a logistics company uses a private blockchain to track the real-time status and location of goods, while a downstream enterprise uses a different private blockchain to manage parts inventory. If these companies need to synchronize delivery schedules and inventory levels for just-in-time manufacturing, the lack of interoperability between their blockchains can lead to delays and increased operational complexity. This is because each system may require custom integration solutions, adding to both the cost and the time needed for effective collaboration. Owing to the restrictive nature of private blockchain, which only permit access to authorized nodes, the sharing and interaction of data between different private blockchains necessitate the implementation of supplementary protocols and interfaces such as Cross-Chain Interoperability Protocol (CCIP), smart contract interfaces, and cross-chain technologies. Consequently, a myriad of challenges arises, encompassing security vulnerabilities, consistency concerns, and the intricacies of management. These challenges contribute to the emergence of data silos, impeding collaborative efforts and interoperability within the entire logistics ecosystem.

Logistics data integration refers to the integration of various data related to logistics from different sources and systems into a unified platform for analysis, processing, and utilization, as shown in Figure 1. These data include the origin and destination of goods, transportation methods and costs, transportation time, inventory and warehousing status. Using Tesla’s logistics pilot project as an example, the company collaborates with Smart Cargo, China Ocean Shipping Company (COSCO), and Shanghai International Port Group (SIPG) for the cross-border transportation of automotive components. The pilot project utilizes a blockchain platform to help Tesla accelerate the extraction speed of automotive parts, simplify the process of shipping and receiving, and achieve a paperless operation throughout, thereby enhancing process efficiency. Despite some positive progress in logistics through the use of blockchain, the project does not address the challenges associated with logistical data integration. The core issue is that Tesla is unable to efficiently and securely integrate data from various logistics companies, which precludes the meticulous oversight of the supply chain. This issue can result in a lack of transparency within the supply chain, negatively impacting the speed and quality of decision-making processes and ultimately constraining Tesla’s agility in supply chain management and its responsiveness to market shifts.

Regarding the issue of logistics data integration between private blockchains, several existing solutions employ blockchain interoperability to address it. Zhang et al. [4] proposed an efficient ring signature scheme for cross-chain data sharing in blockchain-based cold chain logistics systems, aiming to tackle the “data silo” and privacy leakage challenges. Wang et al. [5] addressed problems in traditional supply chain traceability models, such as data falsification, information sharing difficulties, and data opacity. Han et al. [6] proposed a multi-chain system that empowers efficient and authenticated provenance queries. They proposed Vassago, the first multi-chain system supporting efficient and identity-verified source queries. However, existing blockchain interoperability solutions mainly focus on data traceability and leakage prevention. They pay less attention to issues related to logistics data. One such issue is the inability of downstream enterprises to access logistics companies’ private blockchain data, which is due to the access restrictions imposed on private blockchains. Another issue arises when transportation information changes, as downstream enterprises are unable to obtain real-time logistics data integration from different logistics companies.

To address this, we propose a logistics data integration solution based on blockchain interoperability. It aims to enable downstream enterprises to obtain logistics data from private blockchains of different logistics companies, thus obtaining logistics data integration results. This integration of data enables downstream enterprises to gain comprehensive and valuable insights, thereby enhancing their production planning capabilities. Furthermore, the immutability and distributed nature of blockchain technology ensures the reliability and security of logistics data, reducing the risks of data tampering and fraud, thus providing downstream enterprises with a competitive advantage.

As a preview, the contributions in this paper can be summarized as follows:

• This paper proposes an efficient logistics data integration solution in a multi-chain mode. The solution establishes a unified interface between logistics companies’ private blockchains and the public blockchain. This is achieved by combining a unique trust agent scheme with a public blockchain for the cross-chain integration of logistics data. It ensures efficiency, as each logistics company can independently manage and update its own data, reducing the complexity of data interaction and synchronization. At the same time, downstream enterprises can obtain real-time logistics data integration results.
• We apply the PSI protocol to the alignment of logistics data across chains. This addresses the privacy concerns and data disparity challenges in the integration of logistics data between logistics companies and downstream enterprises. By utilizing the PSI protocol, logistics companies and downstream enterprises can align and compute the intersection of logistics data without revealing the actual data. The protocol ensures the secure interaction of logistics data while significantly reducing computation and communication costs and improving real-time interaction efficiency between logistics companies and downstream enterprises.
• We perform an experimental validation of the proposed logistics data integration solution, wherein we conduct a comparative evaluation to assess its performance. Initially, we compare the PSI protocol used in our solution with four commonly employed protocols. The outcomes reveal that the PSI protocol exhibits superior overall performance concerning CPU usage, memory usage, and execution time. Subsequently, we proceed to compare the overall solution with two alternative blockchain interoperability solutions. The experimental results demonstrate that our solution effectively fulfills the requirements of logistics scenarios concerning high data volume and computational efficiency, with little difference in time overhead.

2. Preliminaries and Related Work

This section presents the preliminaries required for our work, including blockchain, consensus mechanism, and Blind RSA-based PSI.

2.1. Blockchain Overview

Blockchain is a decentralized and tamper-proof distributed ledger technology (DLT). It serves as a mechanism for maintaining a public transaction ledger and can be used in shared and synchronized environments. The fragmented freight market within the logistics industry often suffers from inefficiencies due to delays and disputes. However, the application of blockchain technology can improve this situation. By promoting information sharing, blockchain can effectively assist in the transportation of goods, such as in container trade, thereby enhancing the coordination efficiency of the entire process. Due to the existence of various blockchain protocols and standards, logistics information on the blockchain cannot be freely exchanged between different blockchains. Therefore, it is necessary to implement interoperable blockchains that promote open information exchange while retaining their original functions, thereby enhancing the flexibility of the blockchain.

Currently, blockchain interoperability techniques can be categorized into three main types: notary, sidechain, and hash-locking. Notary schemes involve a trusted third-party notary who verifies the data requiring cross-chain operations. During the cross-chain process, the notary validates the authenticity of the data and declares to one chain that the information in another chain is valid. However, existing notary schemes suffer from drawbacks such as low efficiency and a lack of flexibility [7]. Sidechain solutions involve establishing an additional relay chain. This relay chain is positioned between the main chain and the target chain to facilitate the verification and execution of cross-chain transactions. When a user initiates a cross-chain request on the main chain, the relay nodes forward the cross-chain request to the relay chain and validate the transaction data. After completing the validation, consensus nodes on the relay chain construct the corresponding transaction, complete the signing process, and, finally, the relay nodes transfer the transaction to the target chain. The hash-locking method is an intelligent contract solution that enables atomic cross-chain swaps between different blockchains [8]. To ensure secure data exchange, both chains need to support relative timelock operations and possess the capability to hash and verify data blocks against a given hash. This solution exhibits fewer limitations compared to the previously mentioned cross-chain methods. It merely necessitates the execution of specific smart contracts on the two chains to facilitate cross-chain data interaction. However, it is worth noting that malicious participants have the potential to send numerous false transactions, obstruct regular communication channels, and disrupt legitimate transactions for other participants [9].

2.2. Consensus Mechanism

The consensus mechanism is implemented through a series of algorithms and protocols, which define how nodes in the network reach consensus on the validity and consistency of data. The goal of the consensus mechanism is to maintain the security, consistency, and trustworthiness of the blockchain. In a distributed system, intentional delays or interruptions by some nodes, processing errors of nodes, and the malicious behavior of nodes can disrupt the effective implementation of the consensus mechanism. Therefore, the efficient operation of a distributed system relies on an effective consensus mechanism [10]. Common consensus mechanisms include Proof of Work (PoW) [11], Proof of Stake (PoS) [12], Delegated Proof of Stake (DPoS) [13], and others. These mechanisms validate the generation and addition of blocks through participants’ computation, the holding of coins, or delegated stakes. Each consensus mechanism has its advantages, disadvantages, and suitable scenarios. Choosing the appropriate consensus mechanism depends on the requirements and goals of the blockchain network. The design and implementation of the consensus mechanism have a significant impact on the security, scalability, and decentralization of the blockchain.

In order to enable cross-chain data exchange between different blockchains while avoiding the centralization risks of notarization schemes and the implementation difficulties of relay chains, we propose a novel consensus mechanism. In this consensus mechanism, a consortium is formed by companies with shared objectives, and the consortium members participate in the public blockchain to represent themselves as their own trusted agent. Whenever a transaction is committed in a block on the public blockchain, the trusted agents of consortium members receive an event trigger and invoke the propagation contract in their private blockchain. The propagation contract’s task is to collect endorsements from consortium members, which are the digital signature certificates of each consortium member. The transaction is scheduled only when more than 2/3 of the consortium members endorse the transaction. Through this consensus mechanism, decentralized and secure cross-chain interaction can be achieved, avoiding risks associated with third parties and enabling Byzantine fault tolerance. We will provide a detailed explanation of this consensus mechanism in Section 4 of this paper.

2.3. Blind RSA-Based PSI

Privacy Set Intersection (PSI) is a cryptographic technique in Secure Multiparty Computing (MPC) that allows participating parties to compute the intersection of their data without revealing any additional information about their respective sets (beyond the intersection itself). The Blind RSA-based PSI protocol with linear complexity was proposed by De Cristofaro and Tsudik [14]. The main idea behind this protocol comes from the Ogata and Kurosawa [15] adaptive Oblivious Keyword Search.

This protocol has a significant advantage in scenarios where there is a large difference in the amount of data between the two parties. For example, if there is a difference of several orders of magnitude, the party with fewer data can generate a random number (RSA encryption), while the party with more data has the RSA private key (RSA Blind signature), which can significantly reduce computational and communication costs.

The RSA-based Blind PSI consists of a set of algorithms (KeyGen, Hash, Enc, Sign, Dec, and Ali) as well as datasets $C=\{c_1,\dots ,c_v\}$ and $S=\{s_1,\dots ,s_w\}$, as follows:

• KeyGen ($\tau$) → ($pk$, $sk$): KeyGen denotes an RSA key generation algorithm, whose input is security parameter $\tau$ and which chooses two large random primes p and q. The modulus n is constituted by the product of the prime numbers p and q, and the security parameter $\tau$ corresponds to the bit length of n. Subsequently, a large integer e is chosen for the public exponent, while the private exponent d is computed. The outputs are the public key $pk=(n,e)$ and private key $sk=(n,d)$.
• Hash($c_i$) →$h{c}_i$: Taking the element $c_i$ in the dataset C as the input, the algorithm generates the hash value $h{c}_i$, using a Full-Domain Hash function H defined as ${\{0,1\}}^{*}\to {\mathbb{Z}}_n^{*}$.
• Enc ($h{c}_i,pk$) → ($R_{c_i}$, $y_i$): Taking the hash value $h{c}_i$ and public key $pk$ as input, the algorithm generates a random number $R_{c_i}$ corresponding to the element $c_i$, where $R_{c_i}$ is chosen from ${\mathbb{Z}}_n^{*}$. Subsequently, this random number $R_{c_i}$ is encrypted using the public key $pk$, and then it is multiplied by the hash value $h{c}_i$. The algorithm returns the encrypted result $y_i$.
• Sign ($h{s}_j,sk$) → ($K_{s_j},N_{s_j}$): Sign is a signature function that takes the hash value $h{s}_j$ and the private key $sk$ as input. It returns the signature $K_{s_j}$ and the hash $N_{s_j}=H^{\prime }\left(K_{s_j}\right)$ corresponding to $h{s}_j$, where $H^{\prime }$ is a hash function defined as ${\{0,1\}}^{*}\to {\{0,1\}}^{\tau }$.
• Dec ($y_i,sk$) →$y_i^{\prime }$: Taking the encrypted result $y_i$ and private key $sk$ as input, the algorithm returns the decrypted result $y_i^{\prime }$
• Ali ($y_i^{\prime },R_{c_i}$) → ($K_{c_i},N_{c_i}^{\prime }$): Ali is a function that removes the random number and performs hashing. It takes the decrypted result $y_i^{\prime }$ and the random number $R_{c_i}$ as input, removes the random number $R_{c_i}$ from $y_i^{\prime }$ to generate $K_{c_i}$, and then returns the hash result $N_{c_i}^{\prime }=H^{\prime }\left(K_{c_i}\right)$.

The application of RSA-based Blind PSI in our solution will be detailed in Section 4.

2.4. Related Work

Smart logistics has been proposed to enhance operational processes and facilitate material tracking for users. Perboli et al. [16] developed a Hyperledger Sawtooth-based platform for the supply chain. They proposed a layered blockchain system integrated with the IoT for transportation and intelligent logistics. The study found that performance is compromised when concurrent transactions are submitted to multiple nodes. Nevertheless, it does not address the challenges of real-time data processing. He et al. [17] proposed a scheme based on Zero Knowledge Proof of Retrievability (ZKBLS-PoR) to ensure the trustworthiness of the data digest and the proofs in the blockchain. However, this scheme’s focus is primarily on security aspects without considering the efficiency of data-obtaining processes in dynamic logistic environments. Kazancoglu et al. [18] discussed the benefits of BC-T, aimed at identifying and mitigating the risks it could create, as well as guiding the establishment of resilience in reverse logistics activities of SFSCs. However, the study’s main limitation lies in its reliance on expert opinions and subjective judgments, and it offers risk recommendations tailored to specific industries, thus limiting the generalizability of the results. Zhang et al. [19] proposed a blockchain-based cold chain logistics traceability system for fresh agricultural products. This system not only enables secure cross-chain data sharing but also protects user privacy and facilitates cross-chain transactions. Although effective for traceability, the study overlooks the integration of this system with existing logistic networks and the handling of large-scale data. Each of these studies adds valuable insights to the application of blockchain technology in smart logistics. However, previous research has primarily concentrated on engineering applications, with little emphasis on the challenges of data-obtaining processes in logistics. Therefore, our research proposes a new solution that improves real-time decision-making and increases operational transparency throughout the logistics chain.

3. Design Concept

Through the logistics data provided by logistics companies, downstream enterprises can effectively develop production plans. Therefore, logistics companies must ensure the reliability of their logistics data. Additionally, they need to guarantee timeliness to meet the requirements of downstream enterprises. In this section, we introduce the definitions of data transmission and the threat model.

3.1. Definition of Data Transmission

In this paper, our objective is to propose a mechanism that facilitates data exchange among multiple logistics companies and downstream enterprises. We propose the formation of a logistics consortium by integrating the private blockchains of these companies. We define the data transmission between the logistics consortium and downstream enterprises as follows:

Definition 1 

(Security of data transmission). It is necessary to ensure the security of data interaction between downstream enterprises and the logistics consortium. When logistics companies transmit logistics data to downstream enterprises through the public blockchain, anyone on the blockchain can read this information, which may pose a risk of privacy data leakage. Additionally, there may be risks such as eavesdropping attacks during the transmission process.

Definition 2 

(Efficiency of transaction processing). It is crucial to ensure that the logistics consortium promptly handles all requests submitted by downstream enterprises. Due to the uncertainties and risks involved in logistics processes, downstream enterprises require that logistics information is obtained in real-time in order to adjust their production plans promptly based on the logistics conditions. Therefore, logistics companies should respond promptly to all requests from downstream enterprises and provide effective feedback to avoid prolonged waiting times and other related issues. To achieve this, we need to establish efficient communication and collaboration mechanisms. These will ensure timely and accurate data exchange between downstream enterprises and logistics companies, thereby providing better logistics services to downstream enterprises.

Definition 3 

(Efficiency of data transmission). In the logistics process, logistics companies need to record and report a large amount of information related to logistics, such as the current location of goods, logistics progress, package status, delivery records, etc., so that downstream enterprises can use them to query and track the logistics process of goods. As a result, the data volume in the request messages sent by downstream enterprises is relatively small, but the data volume returned by logistics companies is relatively large. Moreover, logistics companies store a significantly larger amount of logistics data compared to downstream enterprises. How to reduce computational and communication costs is an issue that we need to pay attention to.

Definition 4 

(Verifiability of transaction responses). When the logistics consortium returns all requested data, these data will be forwarded to a public blockchain for downstream enterprises to verify the authenticity of the data. This is because logistics companies may engage in non-compliant behaviors such as tampering with logistics information or intentionally delaying deliveries, which can impact the judgment and decision-making of downstream enterprises. Therefore, downstream enterprises need to verify the authenticity of logistics information submitted by logistics companies. This verification on the public blockchain ensures the accuracy and credibility of the logistics information.

3.2. Threat Model

In practical applications, the process of logistics data exchange between downstream enterprises and logistics companies may encounter issues such as data tampering and loss, negatively impacting the security and reliability of the data. To ensure its security and reliability, we need to consider various potential attacks that could affect data exchange.

Specifically, these attacks may include the following:

Byzantine participants: We believe that there may be Byzantine problems between different logistics companies, meaning that there may be malicious participants in the system who engage in deception, tampering, denial, and other behaviors to disrupt or sabotage the normal operation of the system. These malicious participants can collude to alter the results of data transmission, misleading the downstream enterprises and obtaining incorrect information.

Eavesdropping attacks: During the data transmission process, attackers may use eavesdropping methods to obtain sensitive data that are being transmitted. For example, attackers may use network sniffers or intercept network traffic to obtain targeted information.

Data tampering attacks: In the data transmission between the downstream enterprises and logistics companies, attackers may modify or delete transmitted data to cause the receiver to obtain incorrect information. Attackers can use various techniques to modify data, such as using man-in-the-middle attacks, replay attacks, or spoofing attacks.

Impersonation attacks: The communication between downstream enterprises and logistics companies is conducted on an open and insecure channel. Therefore, sensitive information such as certificates and contact information may be leaked.

4. Our Solution

We propose a logistics data integration solution based on blockchain interoperability. We decompose the data integration obtain solution into three manageable stages. In the first phase, we establish a public blockchain for relaying transmissions and initialize the parameters. Downstream enterprises are responsible for establishing the public blockchain, while logistics companies utilize the RSA algorithm to generate encryption keys. In the second phase, logistics companies obtain endorsements for logistics data query requests. When downstream enterprises initiate a logistics query request for the first time, we utilize the consensus mechanism proposed in Section 2 to ensure that the private blockchain of logistics companies receives endorsements from downstream enterprises. Throughout the data transmission process, we employ the RSA-based PSI protocol to ensure the secure transmission and retrieval of logistics data. In the third phase, formal data exchange commences between the downstream enterprise and logistics companies. The downstream enterprise submits logistics query requests through the public blockchain, while logistics companies within the logistics consortium obtain these requests through event triggers of their trusted agents on the public blockchain. The logistics data are encrypted and signed by the logistics companies before being published on the public blockchain. Then, the downstream enterprise performs data alignment to obtain the required logistics data integration. The overall process flowchart is shown in Figure 2.

In this section, we provide a detailed demonstration of our approach. First, to ensure reliable data interaction between downstream enterprises and the logistics consortium, we introduce the public blockchain for relaying transmissions and initialize the parameters in Section 4.1. Next, in Section 4.2, we explain how query request endorsements are obtained. Finally, in Section 4.3, we provide a detailed explanation of the process through which downstream enterprises obtain logistics data integration from the logistics consortium.

4.1. Establish Public Blockchain and Initialize the Parameters

4.1.1. Establish Public Blockchain for Relaying Transmissions

Downstream enterprises are responsible for establishing a public blockchain for relaying transmissions. By leveraging blockchain technology, downstream enterprises can send logistics data query requests. This allows them to obtain relevant information about key logistics data, which includes logistics progress, tracking numbers, and expected arrival times, among others. The public blockchain utilizes smart contracts to automate and streamline the process of data verification and confirmation, ensuring the accuracy and integrity of the data. Additionally, the public blockchain facilitates collaboration and trust among participants by providing a shared and immutable record of all logistics activities. This enables downstream enterprises to track and trace products throughout the entire logistics process, improving operational efficiency, reducing delays, and aiding in the timely detection and resolution of issues. By adopting blockchain technology and establishing a robust logistics data exchange platform, downstream enterprises can enhance transparency, streamline operations, and ultimately provide better services to customers.

The logistics consortium, composed of various logistics companies, adopts an innovative approach to handling data by only signing the data without exchanging private information. This allows each logistics company to protect its privacy data while ensuring the transparency and verifiability of the data. In this logistics consortium, logistics companies participate in the public blockchain as trusted agents. This means that each logistics company is responsible for validating and confirming its own data and adding it to the blockchain. As a result, logistics data becomes an immutable record that can only be accessed and verified by downstream enterprises. This approach will drive the development of the logistics industry and foster greater efficiency and trust.

4.1.2. Parameter Initialization

In the scheme, different logistics companies form a logistics consortium, with each logistics company ${\mathcal{L}}_c$ having a logistics dataset $L_c=\{l_1,\dots ,l_w\}$ and the downstream enterprise $\mathcal{D}$ having a query dataset $D=\{d{e}_1,\dots ,d{e}_v\}$. Our notation is reflected in

Table 2. Notation.

Items	Comments
$\tau$	Security parameter
$\mathcal{D},{\mathcal{L}}_c$	Downstream enterprise and logistics company c
$D,L_c$	The datasets of the downstream enterprise $\mathcal{D}$ and logistics company ${\mathcal{L}}_c$, respectively
$n_c,e_c,d_c$	RSA modulus, public and private exponents of logistics company ${\mathcal{L}}_c$
$p{k}_c,s{k}_c$	Public key $(n_c,e_c)$ and private key $(n_c,d_c)$ of logistics company ${\mathcal{L}}_c$
$p,q$	Large primes, where $q=k(p-1)$ for some integer k
$H\left(\right)$	Cryptographic hash function; codomain depends on context
$H^{\prime }\left(\right)$	Cryptographic hash function $H^{\prime }:{\{0,1\}}^{*}\to {\{0,1\}}^{\tau }$
$v,w$	Sizes of the datasets for D and $L_c$, respectively
$d{e}_i,l_j$	ith and jth elements of datasets D and $L_c$, respectively
$R_{d{e}_i}$	ith random value generated by downstream enterprise $\mathcal{D}$

.

Each logistics company ${\mathcal{L}}_c$ uses $KeyGen(\tau$) to generate the corresponding public key $p{k}_c=(n_c,e_c)$ and private key $s{k}_c=(n_c,d_c)$.

4.2. Query Preparation Stage

4.2.1. Pre-Approval Inquiry

Downstream enterprises send logistics query requests on the public blockchain through the client. These query requests are formed as transactions to a smart contract deployed on the public blockchain. This smart contract acts as a bridge connecting downstream enterprises and logistics companies. Subsequently, the query request transaction is added to a block in the ledger through the blockchain consensus mechanism. This be seen as Step 1 in Figure 3.

4.2.2. Endorsement Collection

When members of the logistics consortium receive query requests from downstream enterprises through the event listener on the public blockchain, they first check if there is a corresponding endorsement from the downstream enterprise in the private blockchain’s ledger. If there is no endorsement, they will utilize the endorsement initialization, endorsement propagation, and commitment mechanisms proposed below to collect endorsements and request approvals. We see this as Steps 2–3 in Figure 3.

Endorsement Initialization: If there is no such endorsement record, consortium members will initiate an endorsement counter and start collecting endorsement signatures for the downstream enterprise, submitting the signed endorsements to the private ledger.

Endorsement Propagation: When other members of the consortium also receive the same query request through the event listener of the public blockchain, they will execute the propagation contract and add their signed endorsements, while increasing the endorsement counter. This way, every member of the logistics consortium can endorse the query request, thereby enhancing the reliability and security of the transaction. Once a sufficient number of endorsements are reached, the logistics query request is approved. This approach ensures both the accuracy and trustworthiness of data and improves the efficiency and reliability of request processing.

Commitment: The number of endorsements for a request goes up until it reaches greater than two-thirds of the logistics consortium members. At this point, it is considered the formal initiation of data interaction from the logistics consortium to the downstream enterprise. Consequently, the downstream enterprise request is marked as approved and ready to be scheduled.

4.2.3. Collective Signature

In terms of verifiability, downstream enterprises validate the information effectively signed by the collective signatures of the logistics consortium members. Collective signatures is a distributed signature protocol that allows multiple participants to sign the same data without revealing their private keys. We utilize the Boneh–Lynn–Shacham (BLS) cryptosystem [20] to collect and aggregate signatures from individual logistics companies. Once the query request from a downstream enterprise is approved, the trusted agents of the logistics consortium members construct a signature request message as $sign\{H\left(M\right),B,{\left[H\left(M\right)\right]}_{S_B}\}$ based on the consortium information M and forward it to all other consortium members, where B is a bitmap indicating which members have signed the message and ${\left[H\left(M\right)\right]}_{S_B}$ is the aggregated collective signature on the hash of the message M. Upon receiving the signature request message, each consortium member adds their own signature through multiplication. We see this as Step 4 in Figure 3.

4.2.4. Approval Results

Once signatures from over two-thirds of the members are aggregated, the final response request message $\{M,H\left(M\right),B,{\left[H\left(M\right)\right]}_{S_B}\}$ and the public key $p{k}_c$ of each logistics company ${\mathcal{L}}_c$ are published on the public blockchain. Downstream enterprises only accept information with a number of signatures greater than two-thirds and the correct hash value. They verify the authenticity of the message using the public key and perform integrity checks by comparing and computing the hash value of M. At this point, downstream enterprises can formally begin obtaining logistics data integration. We see this as Step 5 in Figure 3.

4.3. Formal Query Stage

Downstream enterprises and logistics companies obtain public keys and corresponding endorsements, respectively. Subsequently, when the downstream enterprises perform queries and data retrieval, both parties are not required to repeat the aforementioned steps but may directly use the keys for encryption, decryption, and signing without regenerating them. In this section, the downstream enterprise and logistics companies commence formal data exchange, as shown in Figure 4.

4.3.1. Generate Random Numbers

The downstream enterprise $\mathcal{D}$ uses $Hash(d{e}_i$) and $Enc(H\left(d{e}_i\right),p{k}_c$) for executing hashing and encryption computations upon $c_i$, first generating associated random numbers $R_{d{e}_i}\in {\mathbb{Z}}_n^{*}$ for each element $d{e}_i$ in the downstream enterprise’s dataset D to protect the dataset elements. Then it uses the hash function H provided by the logistics company ${\mathcal{L}}_c$ to hash the downstream enterprise’s dataset $D=\{d{e}_1,\dots ,d{e}_v\}$, resulting in the set $\{H\left(d{e}_1\right),\dots ,H\left(d{e}_v\right)\}$. Subsequently, the public key $p{k}_c$ is used to encrypt each hash element, yielding the set $\{y_1,\dots ,y_v\}$. At this point, the random numbers $R_{d{e}_i}$ generated are kept, and this step is executed off-chain.

The process is defined as Step 1 in Figure 4. As shown in Equation (1), $y_i$ represents the value encrypted by the downstream enterprise using the logistics company’s public key $p{k}_c$. Here, performing RSA encryption on $R_{d{e}_i}$ is intended to facilitate the removal of $R_{d{e}_i}$ in the fifth step of the process.

$$y_i={\mathrm{Enc}}_{p{k}_c}\left(H\left(d{e}_i\right)\right)=H\left(d{e}_i\right)·{\left(R_{d{e}_i}\right)}^{e_c}modn$$

(1)

4.3.2. Logistics Query

The downstream enterprise $\mathcal{D}$ sends the logistics query to the logistics consortium through the public blockchain in the following format. We see this as Step 2 in Figure 4.

$$(\{y_1,\dots ,y_v\},{\mathcal{L}}_1,\dots ,{\mathcal{L}}_c)$$

4.3.3. Data Signature

Upon receiving the logistics query $\{y_1,\dots ,y_v\}$ from the downstream enterprise $\mathcal{D}$ via an event listener, the logistics consortium members ${\mathcal{L}}_c$ use $Hash(l_j$) and $Sign(H\left(l_j\right),s{k}_c$) to hash and sign $l_j$ and then employ $Dec(y_i,s{k}_c$) to decrypt $y_i$. First, each logistics company ${\mathcal{L}}_c$ uses the hash function H to hash their respective logistics datasets $L_c=\{l_1,\dots ,l_w\}$, resulting in the set $\{H\left(l_1\right),\dots ,H\left(l_w\right)\}$. Then, utilizing their respective private keys $s{k}_c$, the elements are both signed and hashed, yielding $K_{l_j}$ and $N_{l_j}$, respectively. Finally, they decrypt the received query requests and perform computations to derive $y_i^{\prime }$.

$$K_{l_j}={\mathrm{Sign}}_{s{k}_c}\left(H\left(l_j\right)\right)=H{\left(l_j\right)}^{d_c}modn$$

(2)

$$N_{l_j}=H^{\prime }\left(K_{l_j}\right)$$

(3)

$$y_i^{\prime }={\mathrm{Dec}}_{s{k}_c}\left(y_i\right)={\left(y_i\right)}^{d_c}modn$$

(4)

This is depicted as Step 3 in Figure 4. The computation can be formalized with the following formula, where $K_{l_j}$ is the RSA encryption result for $l_j$. After individually blind-signing their respective logistics data, the logistics consortium members utilize the collective signature described in Section 4.2.3 for signing.

4.3.4. Query Results

The logistics consortium sends the logistics data integration results to the downstream enterprises through the public blockchain. We can see this as Step 4 in Figure 4. The data are sent by each logistics company in the logistics consortium to the downstream enterprise: $\{y_1^{\prime },\dots ,y_v^{\prime }\},\{N_{l_1},\dots ,N_{l_w}\}$.

To see that the present protocol is correct, consider the following:

$$K_{d{e}_i}=y_i^{\prime }/R_{d{e}_i}={(H\left(d{e}_i\right)·{\left(R_{d{e}_i}\right)}^{e_c})}^{d_c}/R_{d{e}_i}=H{\left(d{e}_i\right)}^{d_c}\Rightarrow K_{d{e}_i}=K_{l_j}\mathrm{if}H\left(d{e}_i\right)=H\left(l_j\right)$$

(5)

4.3.5. Data Alignment

After obtaining the logistics data integration results, the downstream enterprise uses $Ali(y_i^{\prime },R_{d{e}_i})$ for computation. First, it performs a de-blinding operation on the elements in the set $\{y_1^{\prime },\dots ,y_v^{\prime }\}$ to obtain $K_{d{e}_i}$; this step is executed off-chain. Then, the downstream enterprise needs to align the signature of each logistics company’s $\{H\left(l_1\right),\dots ,H\left(l_w\right)\}$ with its own signatures $\{H\left(d{e}_1\right),\dots ,H\left(d{e}_v\right)\}$ to obtain the queried data. It can be calculated using the following formula. We can consider it as Step 5 in Figure 4. $N_{l_w}$ represents the logistics company’s signature on the logistics data, $N_{d{e}_v}^{\prime }$ represents the result of downstream enterprise unblinding the queried data, and $\{N_{l_i},\dots ,N_{l_j}\}$ represents the data set formed after alignment processing.

$$K_{d{e}_i}=y_i^{\prime }/R_{d{e}_i}\mathrm{and}{N}_{d{e}_i}^{\prime }=H^{\prime }\left(K_{d{e}_i}\right)$$

(6)

$$\{N_{l_1},\dots ,N_{l_w}\}\cap \{N_{d{e}_1}^{\prime },\dots ,N_{d{e}_v}^{\prime }\}=\{N_{l_i},\dots ,N_{l_j}\}$$

(7)

The logistics company sends the corresponding data $l_j$ from this set to the downstream enterprise, thus enabling the downstream enterprise to acquire the logistics data integration $\{l_i,\dots ,l_j\}$. Through data alignment, the downstream enterprise can obtain logistics data integration, which includes logistics order numbers, sender information, recipient information, and logistics progress.

5. Security Analysis

5.1. Security Analysis of the PSI Protocol

In terms of the linear computation and communication complexity of the Blind RSA-based PSI Protocol between logistics companies and downstream enterprises, the online computation cost for downstream enterprises is $O\left(v\right)$ exponentiation, the computation cost for the logistics company is $O\left(w\right)$ multiplication, and the communication cost for both is $O(v+w)$.

For the formula in Section 4.3.3, we conducted the following deduction to demonstrate its accuracy.

$$\begin{array}{cc}\hfill y_i^{\prime }& ={Dec}_{s{k}_c}\left(y_i\right)\hfill \\ \hfill & ={\left(y_i\right)}^{d_c}modn\hfill \\ \hfill & ={(H\left(d{e}_i\right)·{\left(R_{d{e}_i}\right)}^{e_c}modn)}^{d_c}modn\hfill \\ \hfill & ={(H\left(d{e}_i\right)·\left({\left(R_{d{e}_i}\right)}^{e_c}modn\right))}^{d_c}modn\hfill \\ \hfill & =(H{\left(d{e}_i\right)}^{d_c}·{\left({\left(R_{d{e}_i}\right)}^{e_c}modn\right)}^{d_c})modn\hfill \\ \hfill & =\left(H{\left(d{e}_i\right)}^{d_c}modn\right)·\left({\left({\left(R_{d{e}_i}\right)}^{e_c}modn\right)}^{d_c}modn\right)modn\hfill \\ \hfill & =(\left(H{\left(d{e}_i\right)}^{d_c}modn\right)·\left(R_{d{e}_i}\right))modn\hfill \end{array}$$

(8)

For the formula in Section 4.3.5, we conducted the following deduction to demonstrate its accuracy.

$$\begin{array}{cc}\hfill K_{d{e}_i}& =y_i^{\prime }/R_{d{e}_i}\hfill \\ \hfill & =(\left((\left(H{\left(d{e}_i\right)}^{d_c}modn\right)·\left(R_{d{e}_i}\right))modn\right)\hfill \\ & \ast \left(R_{d{e}_i}^{\phi \left(n\right)-1}modn\right))modn\hfill \\ \hfill & =((\left(H{\left(d{e}_i\right)}^{d_c}modn\right)·\left(R_{d{e}_i}\right))·\left(R_{d{e}_i}^{\phi \left(n\right)-1}\right))modn\hfill \\ \hfill & =(\left(H{\left(d{e}_i\right)}^{d_c}modn\right)·(\left(R_{d{e}_i}\right)·\left(R_{d{e}_i}^{\phi \left(n\right)-1}\right))modn\hfill \\ \hfill & =(\left(H{\left(d{e}_i\right)}^{d_c}modnmodn\right)\hfill \\ \hfill & \ast (\left(R_{d{e}_i}\right)·\left(R_{d{e}_i}^{\phi \left(n\right)-1}\right)modn)modn\hfill \\ \hfill & =H{\left(d{e}_i\right)}^{d_c}modn\hfill \end{array}$$

(9)

In this way, downstream enterprises can achieve data alignment with the data from logistics companies.

5.2. Security Analysis of Our Scheme

Completeness. When the logistics consortium and downstream enterprises exchange data, they need to use public blockchain for data interaction and request. However, if either party has doubts about the accuracy of the data, they can retrieve the transmission records of the current or previous transactions through the public blockchain. Based on the advantages of blockchain, such as traceability and tamper resistance, this ensures the authenticity and integrity of the data. Additionally, to ensure the reliability of logistics data, the collective signature mechanism is employed for data interaction from logistics companies to downstream enterprises. This ensures that only requests approved by consortium members are processed, and only logistics data integration signed by more than two-thirds of the consortium members is accepted by the downstream enterprises. The purpose of this arrangement is to prevent inaccuracies in data interaction caused by malicious members within the logistics consortium. This mechanism guarantees the security and reliability of data interactions, effectively safeguarding the interests of both the logistics consortium and downstream enterprises.

Soundness. When a logistics company re-joins the logistics consortium, downstream enterprises update data, or if the logistics company experiences a malicious attack resulting in the loss or invalidation of endorsements regarding downstream enterprises, the downstream enterprises have the option to initiate a new query permission request and re-establish a connection with the logistics companies in the consortium. Previous requests and transmission records are also stored in the public blockchain. As long as the downstream enterprises securely store their private keys, they can decrypt and obtain the information.

Security. To ensure the security of logistics data interaction, we employ the PSI protocol for data transfer. Without accessing the actual datasets of both parties, the PSI protocol computes the intersection of their data, enabling downstream enterprises to obtain logistics data integration. The logistics consortium then collectively signs this data. In the case of unauthorized downstream enterprises, during the query permission request stage, logistics companies within the consortium will not find endorsements for the querying enterprise, and the consortium will reject the query request.

6. Performance Evaluation

In this section, we will evaluate the performance of the solution from the perspectives of computation and communication overhead. In addition, we compare the PSI protocol we used with other existing protocols to demonstrate the feasibility of our protocol.

6.1. Experimental Environment

Our experimental setup is as follows: the CPU is an AMD Ryzen 7 4700U with Radeon Graphics 2.00 GHz, running on the Win10 operating system. We also use a VMware Workstation Pro virtual machine, running on the ubuntu-20.04 operating system. The virtual machine has 4 GB of memory and the CPU is an Intel Core i9-11900K @ 3.50 GHz x 4. The software versions used in the experiment include Python version 3.9, npm version 6.14.8, and Node version v14.13.1.

Our experiment implemented cross-chain logistics information transmission between Ethereum and Hyperledger Fabric [21]. Each logistics company participating in cross-chain interaction, which is a private blockchain, selects some notaries (also called validators) who are responsible for verifying the validity of cross-chain interaction and recording the validation results. The Ethereum test network was built using Ganache [22], which can simulate the Ethereum mainnet, create a local Ethereum test network, and provide a list of private keys and addresses. These addresses and private keys can be used to deploy and test smart contracts. Hyperledger Fabric runs on Ubuntu 20.4 and uses Certificate Authority to manage identity authentication and access control. It provides a certificate-based identity authentication and access control mechanism that allows users to access resources in the Fabric network using certificates. The Fabric network consists of multiple organizations, each with two Peer nodes. The designed chaincode includes functions such as data uploading, reading, and data encryption and uses LevelDB database for data storage and maintenance. This article uses the ganache-2.7.0-linux-x86_64 environment to set up an Ethereum simulation environment and Hyperledger Fabric version 2.2 to build a consortium chain environment.

6.2. Performance Testing

Privacy protection is crucial in the logistics data exchange. To ensure data privacy, encryption calculations are required for cross-chain data transmission, which can result in computation and communication overheads. Specifically, we used the PSI protocol on the blockchain, which incurs certain overheads. To better evaluate the impact of such overheads, we conducted a series of experiments, analyzing the blockchain in detail from three aspects: CPU usage, memory usage, and average time consumption, as shown in Figure 5, Figure 6 and Figure 7. Through these experiments, we can more accurately evaluate the performance of the PSI protocol used in cross-chain data transmission, providing better solutions for privacy protection in the logistics data exchange.

Increasing the number of requests in parallel computing is generally believed to improve computing performance. However, experimental results have shown that as the number of parallel requests increases, the average time consumption exhibits an upward trend, indicating that parallel processing capability does not increase linearly. This may be due to factors such as communication, synchronization, and competition between processes. When the number of parallel requests increases to a certain level, the growth rate of the average time consumption becomes faster, indicating that the experimental number of parallel requests has reached the optimal threshold acceptable in the experimental environment, leading to a slower computing speed. In parallel computing, it is important to consider not only computing performance but also the utilization of system resources. By examining the average CPU usage and memory usage, as shown in Figure 6 and Figure 7, we can evaluate the effectiveness of parallel computing more comprehensively.

In Figure 5, Figure 6 and Figure 7, the number of logistics companies represents the quantity of different logistics companies requested by downstream enterprises. Based on the data in the figures, it can be observed that as the number of parallel requests increases, the overall execution time, CPU usage, and memory usage show an upward trend, leading to increased computational consumption.

In the Blind signature section, the execution time is minimally affected by the increase in the number of parallel requests. This is because blind signature is performed off-chain, without involving the invocation of Fabric and Ethereum smart contracts, resulting in minimal communication time. Therefore, regardless of how many requests are increased, the overall execution time and computational consumption are minimally affected.

In the Sever Encryption section, the execution time and memory usage increase at the fastest rate. Under a single request, the execution time is 376 ms. Sever Encryption involves extensive server-side data encryption calculations and cross-chain data operations, leading to an increase in time. Thus, as the number of parallel requests increases, the rate of increase in execution time and computational consumption also accelerates accordingly.

In the Intersection calculation section, a significant amount of intersection calculations on data is required, with the need for communication and synchronization. Therefore, as the number of parallel requests increases, the overhead of communication and synchronization also increases, resulting in a faster increase in execution time and computational consumption. In the entire process, the Intersection calculation section incurs significant computational and communication overhead, while other sections have relatively lower demands on performance.

In conclusion, the impact of increasing the number of parallel requests on the overall execution time and computational consumption varies across different sections. In different sections, increasing the number of parallel requests may have different effects.

We conducted experimental comparisons between Blind RSA-based private set intersection (RSA-PSI) and four other PSI protocols, including Differential Privacy-based private set intersection (DP-PSI) [23], Encryption-based private set intersection (Enc-PSI) [24], Hash-based private set intersection (Hash-PSI) [14], and Bloom filter-based private set intersection (BF-PSI) [25], and analyzed their strengths and weaknesses in the logistics data exchange scenario. First, we will briefly introduce these five PSI protocols:

• In BF-PSI protocol, two participants each construct their own Bloom filter and send it to the other participant. A Bloom filter is a fast and efficient data structure commonly used for checking whether an element exists in a set. The receiver uses their own Bloom filter to match against the sender’s Bloom filter to determine the intersection of the two sets.
• In the Hash-PSI protocol, two participants each construct their own hash table and send it to the other participant.
• In the Enc-PSI protocol, two participants each encrypt their own set and send the encrypted sets to the other participant.
• In the DP-PSI protocol, two participants each apply differential privacy techniques to their own set and send the processed sets to the other participant.
• In the RSA-PSI protocol, two participants each generate random values from their own set and use the Blind RSA algorithm to blind these values. The blinded random values can be sent to the other participant without revealing the original data. The receiver uses their own RSA private key to un-blind the blinded random values sent by the sender, obtaining the random values from the sender’s set, and then computes the intersection of the two sets.

Based on the observations from Figure 8, we can conclude that RSA-PSI performs better than traditional Enc-PSI and DP-PSI protocols in terms of time consumption. This superiority is attributed to RSA-PSI’s utilization of the Blind RSA algorithm, which exhibits lower computational complexity and eliminates the need for complex noise handling. Therefore, it exhibits superior performance in terms of time consumption. In contrast, Hash-PSI and BF-PSI, while possessing lower computational complexity, incorporate operations such as hashing functions and Bloom filters, which lead to diminished performance in time consumption.

In the context of logistics, we utilize the PSI protocol to facilitate the flow of logistics data between downstream enterprises and logistics companies. There may be significant differences in the volume of data between these entities, and there are high requirements for computational efficiency, privacy protection level, and scalability. In this scenario, the RSA-PSI protocol demonstrates favorable overall performance. With the adoption of the RSA algorithm, the RSA-PSI protocol exhibits lower computational complexity, enabling the efficient processing of large-scale datasets. Additionally, this protocol provides a higher level of privacy protection, ensuring the effective safeguarding of sensitive data during the sharing process. Moreover, the protocol demonstrates good scalability and is capable of handling the intersection of multiple sets, thus meeting the requirements for multi-party data sharing in the logistics context.

The single chain solution is currently one of the most common blockchain solutions, with the main advantage of being simple and easy to implement, requiring only one blockchain network to complete all operations. Yakubu et al. [26] proposed a framework, RiceChain, which is capable of tracking and monitoring all interactions and transactions among all stakeholders in the rice chain ecosystem through smart contracts. Zhang et al. [4] proposed a cross-chain data sharing scheme in a blockchain-based cold chain logistics system (ColdChain). It incorporates a transaction ring-signing model with a multi-chain fusion mechanism and a ring signature scheme. This scheme aims to facilitate secure cross-chain data sharing while protecting user privacy. Similar to our approach, both of these solutions address practical issues related to logistics and ensure secure data sharing. However, ColdChain leans more towards a signature scheme. Therefore, we will compare the performance of the aforementioned two schemes with our own approach. Our evaluation focuses on two crucial metrics: transaction throughput and latency, which are compared against our proposed solution. The results of this comparison are presented in Figure 9 and Figure 10.

Our analysis indicates that, due to the need for cross-chain operations in both our scheme and the ColdChain, the throughput and latency during the initialization, query, and transaction processes are not as good as those of the single-chain scheme, RiceChain. These performance differences can be attributed to the increased computational and communication overhead associated with cross-chain operations, resulting in a certain level of performance degradation. Due to the overly complex signature mechanism in ColdChain, it resulted in relatively poorer performance in terms of throughput and latency. However, it is important to note that despite the observed performance gap, the disparities in transaction throughput and latency between our proposed solution and the single chain solution (RiceChain) are not statistically significant.

Another important aspect that deserves attention is security. Our proposed solution enjoys a clear advantage in terms of security over the single chain solution. The single-chain solution carries inherent security risks, such as vulnerability to 51% attacks. In contrast, our solution effectively mitigates these potential security threats by employing mechanisms such as PSI and collective signatures. As a result, our solution not only achieves comparable performance to the single-chain solution but also provides security.

In addition, due to the similarity between our solution and the relay chain, we compared our approach with the heterogeneous blockchain operation platform based on a side-relay chain (BitXHub) proposed by Ye et al. [27], which further proves the feasibility of our solution. The BitXHub consists of a relay chain, application chains, and cross-chain gateways, which enables the transfer of assets and data sharing among different blockchains, ensuring the security, flexibility, and reliability of cross-chain transactions. Both our proposed solution and BitXHub are blockchain interoperability solutions that guarantee asynchronous distributed transactions between heterogeneous blockchains. They both exhibit high performance with high throughput, low latency, and low overhead. Therefore, we will compare our solution with BitXHub. The performance evaluation of these two schemes is presented in Figure 11. The BitXHub exhibited lower throughput due to the additional operations it entailed. The results indicate that our solution excels in the context of blockchain-based logistics data, satisfying business requirements.

The overall time cost of achieving blockchain interoperability encompasses computation and communication overheads, which are influenced by the size of data transmitted. Therefore, we compared the time costs of the following two cross-chain solutions: (1) the direct cross-chain solution, which requires establishing a secure point-to-point communication channel between two blockchains while ensuring the mutual invocation of smart contracts on both chains. The interoperability solution proposed by Zhou and Lee [28] for homogeneous blockchains is based on a cross-chain transmission protocol similar to TCP; this protocol is solely responsible for forwarding cross-chain messages. (2) The shared address cross-chain solution, which deploys the same smart contract on different chains and uses the same address as the identifier of assets on the chains, enabling asset interoperability through smart contracts. Li et al.’s proposed cross-chain solution for sidechain privacy protection introduces a cross-chain protocol based on shared addresses [29]. Its design aims to ensure that honest payers do not lose their currency. Additionally, it utilizes zero-knowledge proof protocols to verify transactions in confirmed blocks without revealing transaction information.

We compared the aforementioned cross-chain solutions by Zhou and Lee [28] and Li et al. [29] with our proposed logistics information cross-chain solution in through comparative testing. In order to further validate the performance of the proposed logistics data integration solution, we conduct five comparative experiments under the same hardware environment, covering different data sizes of 128 B, 256 B, 1 KB, 2 KB, and 4 KB. The experimental results are shown in Figure 12. It can be observed from the graph that the proposed logistics data cross-chain solution exhibits minimal responsiveness to changes in data size, indicating good stability. At the same time, the solution demonstrates comparable time costs to the other two alternatives. Therefore, the cross-chain solution based on the RSA-PSI protocol performs exceptionally well in logistics scenarios, meeting the requirements of handling large data volumes and achieving high computational efficiency. Compared to other cross-chain solutions, the proposed solution shows minimal differences in time overhead, thereby enabling the efficient and secure flow of logistics data.

7. Conclusions

This paper presents a secure and efficient logistics data integration solution in a multi-chain mode. It tackles the challenge of obtaining logistics data integration and enables real-time querying and the secure obtainment of logistics data.

Compared to existing solutions, our solution has the following innovations: (1) Establishing a unified interface between the public blockchain and private blockchains of logistics companies using a unique trusted agent scheme for logistics data integration. (2) Applying the PSI protocol in logistics, logistics companies, and downstream enterprises can align and compute the intersection of logistics data without revealing the actual data. The protocol ensures the secure interaction of logistics data while significantly reducing computation and communication costs and improving real-time interaction efficiency between logistics companies and downstream enterprises.

Theoretical analysis and experiments demonstrate that our solution can achieve the real-time querying of logistics data while ensuring data privacy for downstream enterprises. Compared to existing logistics data exchange solutions, our solution offers the advantages of low cost, high security, and high reliability. In the future, we will continue to explore how to more effectively balance security, efficiency, and cost and conduct in-depth studies on scalability issues brought about by increased data volumes. At the same time, we plan to closely collaborate with logistics companies, striving to better integrate our proposed solutions into practical applications to truly meet the specific needs of the logistics industry.