# Logisticschain: A Blockchain-Based Secure Storage Scheme for Logistics Data

Authors: Hongzhi Li; Dezhi Han; Mingdong Tang
Journal: Mobile Information Systems
 (2021)

---

## Abstract

With the rapid development of information technology, logistics systems are developing towards intelligence. The Internet of Things (IoT) devices throughout the logistics network could provide strong support for smart logistics. However, due to the limited computing and storage resources of IoT devices, logistics data with user sensitive information are generally stored in a centralized cloud center, which could easily cause privacy leakage. In this paper, we propose Logisticschain, a blockchain-based secure storage scheme for logistics data. In this scheme, the sensing data from IoT devices should be encrypted for fine-grained access control, and a customized blockchain structure is proposed to improve the storage efficiency of systems. Also, an efficient consensus mechanism is introduced to improve the efficiency of the consensus process in the blockchain. Specific to the logistics process, the sensing data generated from IoT devices will be encrypted and aggregated into the blockchain to ensure data security. Moreover, the stored logistics records can be securely audited by leveraging the blockchain network; both IoT data and logistics demands cannot be deleted or tampered to avoid disputes. Finally, we analyze the security and privacy properties of our Logisticschain and evaluate its performance in terms of computational costs by developing an experimental platform.


---

## Body

## 1. Introduction

Smart logistics systems have been proposed to significantly improve efficiency and accuracy, break geographical restrictions to achieve remote logistics monitoring, and ensure timely delivery of information to users. The Internet of Things (IoT) is a promising technology that provides important support for the construction of the smart logistics system. Generally, a smart logistics system is mainly composed of data collection and classification, data mining and analysis, and application layer. Specifically, we can briefly describe these components as follows. (1) The data collection procedure based on IoT is responsible for solving the real-time information collection issue, which constitutes the basis of smart logistics systems. (2) The data mining and analysis procedure is used to mine effective real-time logistics information and design a reasonable transportation scheduling scheme. (3) The application layer could provide detailed information and consulting services for logistics providers and customers [1–4].In a smart logistics system, IoT devices (e.g., RFID, GPS sensors, temperature, and humidity sensors) are utilized to keep collecting logistics records during the logistics process. Usually, these logistics data are sent to a local gateway to perform further data processing and aggregation and then sent to the smart logistics system for analysis so that customers or users can track the real-time status. In fact, due to the limitations of IoT devices (e.g., limited battery supply and storage capabilities) and other economic factors (e.g., large-scale built-in storage for sensors is expensive and self-built data center is time-consuming and expensive), the collected logistics data are likely to be outsourced to cloud servers [4–6].The use of cloud servers can significantly improve the efficiency of smart logistics systems compared with traditional systems [13]. Specifically, traditional logistics systems are generally based on physical sensing devices and database systems and need to rely on manual data entry. The traditional scheme is usually only suitable for small-scale logistics systems, which is not conducive to large-scale data management because the traditional database system cannot realize the flexible management of storage resources. However, there are still several disadvantages of the cloud-assisted scheme. (1) Cloud servers can be considered as centralized third parties with a single-point bottleneck to some extent. Thus, if cloud servers are compromised or break down, all users might be affected. Furthermore, for large-scale edge computing with wide geographical distribution, the centralized cloud storage usually requires higher network bandwidth and leads to high response time. (2) Logistics data usually contain sensitive information about users, which should be well protected. However, cloud servers may sniff user privacy for commercial benefits. For instance, cloud service providers may be interested in the address information, contact information (e.g., identity, telephone, email, and location) of users, and transportation paths. (3) Logistics records stored in the cloud may still be tampered, and the credibility of the stored records cannot be guaranteed. Therefore, the cloud-assisted logistics system cannot provide reliable solutions to logistics disputes.Blockchain technology, which is first applied in the financial field, such as Bitcoin [7] and Ethereum [8], can be used to provide a decentralized and trusted environment. With the development of blockchain technology, especially the widespread use of Ethereum and Hyperledger Fabric [9], blockchain has become one of the key technologies for IoT scenarios. The ledger of blockchain consists of a series of blocks, which are connected as a linked list, and each block contains several transactions. Since there is no centralized node in the blockchain network, it is impossible to modify the stored content in the blockchain.Blockchain technology provides a promising solution to the security challenges of logistics data. However, the existing blockchain technology for the financial field is not suitable for IoT-based logistics scenarios. Moreover, there is no mature and feasible data protection scheme for logistics systems based on the blockchain network.In this work, we propose a secure storage scheme for logistics data, which is namedLogisticschain. In our scheme, users can submit logistics demands to the blockchain as transactions. Smart devices are responsible for collecting status information during the logistics process. These logistics records are usually published to the blockchain as transactions for security concerns. However, it should be noted that the complete logistics record could not be stored in the blockchain due to the limited resources of blockchain nodes. Depending on specific scenarios, a conventional DBMS (e.g., Mysql or MongoDB), a storage cloud service (e.g., S3, AWS, or Azure), or a distributed storage system (e.g., IPFS or Storj) can be used for original records’ storage [10, 11]. Specifically, the main contributions of this study can be summarized as follows:(i)
We propose a blockchain-assisted secure storage scheme for logistics data, named Logisticschain. In Logisticschain, users are enabled to submit their logistics demands as transactions and logistics providers are authorized to provide logistics services. Also, logistics records are stored in the blockchain to ensure that the entire logistics process can be audited.(ii)
We propose a group-based PoW consensus mechanism, which can significantly improve the efficiency of traditional PoW consensus. It can effectively improve the throughput of blockchain-based IoT systems.(iii)
We implement the proposed Logisticschain and conduct experiments to evaluate the performance of our proposed scheme.The rest of this paper is organized as follows. In Section2, we briefly introduce the related work. In Section 3, we introduce the necessary background and technologies. Also, we propose the design of the system model in Section 4. We depict the proposed scheme in Section 5. In Section 6, we present the security analysis of Logisticschain. In Section 7, we analyze the performance of Logisticschain based on experimental results. Finally, we conclude this study in Section 8.


## 2. Related Work

In this section, we survey the related work in three parts. Firstly, we present background information about logistics systems. Then, some literatures about blockchain applications in IoT scenarios are introduced. Finally, several representative consensus algorithms are discussed.


### 2.1. Smart Logistics System

With the development of e-commerce and the new retail industry, logistics has become an indispensable part of the modern supply chain. Many research studies focus on improving the performance of logistics systems. Lin et al. [12] introduced fog computing to the logistics centers. It aims to solve the problem that the centralized cloud computing system cannot bear the heavy computing load from thousands of IoT devices in factories. Furthermore, an efficient deployment model of fog computing is proposed in [12] to reduce the computational cost of IoT devices. In 2018, Zhang et al. [13] introduced the Internet of things and cloud-based storage technologies into the device layer interconnection design and data processing to solve the problem of energy waste and long waiting time in the process of integration of production and logistics in industrial workshops. A smart logistics framework is proposed in [14], and this framework adopts cyber-physical systems and industrial Internet of things (IIoT) to solve the problem of resource coordination in the process of logistics. In addition, the efforts of [15] focus on solving the integrated planning problem of smart food logistics systems, and a fuzzy logic method is used to optimize the logistics planning. Recently, blockchain technology as a promising approach is used to improve the performance of logistics systems. Perboli et al. [16] proposed a digital backbone logistics network based on the blockchain. Since the blockchain can ensure data immutability and public accessibility of data streams, the use of blockchain can increase the efficiency, reliability, and transparency of the overall supply chain. Wang et al. [17] proposed a smart contract-based scheme for logistics systems, and an event response mechanism is utilized to trigger the defined smart contracts. Thus, all product transferring histories are perpetually recorded in a distributed ledger by using smart contracts. Aiming at the current issues of security threats and privacy leak in the smart logistics system, a scheme on applying blockchain in smart logistics systems is proposed in [18]. Smart contracts and blockchain ledgers are used to improve the traceability of logistics systems.


### 2.2. Blockchain for IoT

Blockchain has become one of the promising technologies for building secure Internet of things (IoT). Some research efforts are devoted to demonstrating the advantages of blockchain. Yang et al. [19] proposed a decentralized trust management system in vehicular networks based on blockchain techniques. In such a system, vehicles can validate the received messages from neighboring vehicles using the Bayesian Inference Model. To solve the difficulties of traditional centralized storage on the Internet of Vehicles, Jiang et al. [20] investigated how to extend the blockchain to the application of vehicle networks and proposed a model of the outward transmission of the blockchain data. Also, an integrated IoT blockchain platform for sensing data was proposed in [21], and the platform aims to afford the device owner a practical application that provides a comprehensive, immutable log and allows easy access to devices. Moreover, Ma et al. [22] proposed a blockchain-based trusted data management scheme (called BlockTDM) in edge computing. In the proposed BlockTDM, conditional access and decryption queries of the protected blockchain data have been designed, and a user-defined sensitive data encryption approach is utilized to achieve privacy protection. In [23], the authors proposed a multilayer secure IoT model based on the blockchain. This model divides the IoT system into a multilevel decentralized network and uses blockchain technology at all levels of the network. The authors of [24] put forward a blockchain-inspired IoT architecture, which is designed for creating a transparent food supply chain. RFID is used to identify food and other things, and the blockchain is employed to store the food-related sensitive information from IoT devices. In general, the blockchain technology is currently being applied to various IoT application scenarios so as to improve the security of IoT-based systems.


### 2.3. Consensus for IoT-Based Blockchain

Recent studies have utilized different consensus algorithms to establish blockchain-enabled networks for data storage. Proof of Work (PoW) [25] is first used in public blockchains. However, the rapid growth of transactions generated by IoT devices are different from public blockchains, and the traditional PoW algorithm is both resources and time consumption, which may not be suitable for IoT. Puthal et al. [26] presented a novel consensus algorithm called Proof-of-Authentication (PoAh), which introduces a cryptographic authentication mechanism to replace PoW for resource-constrained devices. Furthermore, in [27], the authors proposed a novel lightweight Proof of Block & Trade (PoBT) consensus algorithm for blockchain-based IoT systems, which validates not only the transactions but also the created blocks. Besides, in [27], a complete working solution for the integration of PoBT and Hyperledger Fabric is presented. The consumption of resources and time of PoBT is analyzed through a set of experiments. To improve the security of the Industrial Internet of Things (IIoT), Huang et al. [28] investigated how to extend the blockchain technology to the resource-constrained IoT environment. In detail, a credit-based Proof-of-Work (PoW) mechanism for IoT devices is proposed in [28], which guarantees the system security and the transaction efficiency simultaneously. Liu et al. [29] proposed an anonymous reputation system for IIoT-enabled retail marketing. In detail, the reputation management in the consumer-retailer system is the focus of this work and a blockchain-based reputation management scheme is proposed to provide high-level privacy protection. These accumulated reputation scores are treated as stakes of the corresponding blockchain account. Finally, a PoS-based consensus mechanism is proposed, which utilizes reputation scores to improve the efficiency of systems.


## 2.1. Smart Logistics System

With the development of e-commerce and the new retail industry, logistics has become an indispensable part of the modern supply chain. Many research studies focus on improving the performance of logistics systems. Lin et al. [12] introduced fog computing to the logistics centers. It aims to solve the problem that the centralized cloud computing system cannot bear the heavy computing load from thousands of IoT devices in factories. Furthermore, an efficient deployment model of fog computing is proposed in [12] to reduce the computational cost of IoT devices. In 2018, Zhang et al. [13] introduced the Internet of things and cloud-based storage technologies into the device layer interconnection design and data processing to solve the problem of energy waste and long waiting time in the process of integration of production and logistics in industrial workshops. A smart logistics framework is proposed in [14], and this framework adopts cyber-physical systems and industrial Internet of things (IIoT) to solve the problem of resource coordination in the process of logistics. In addition, the efforts of [15] focus on solving the integrated planning problem of smart food logistics systems, and a fuzzy logic method is used to optimize the logistics planning. Recently, blockchain technology as a promising approach is used to improve the performance of logistics systems. Perboli et al. [16] proposed a digital backbone logistics network based on the blockchain. Since the blockchain can ensure data immutability and public accessibility of data streams, the use of blockchain can increase the efficiency, reliability, and transparency of the overall supply chain. Wang et al. [17] proposed a smart contract-based scheme for logistics systems, and an event response mechanism is utilized to trigger the defined smart contracts. Thus, all product transferring histories are perpetually recorded in a distributed ledger by using smart contracts. Aiming at the current issues of security threats and privacy leak in the smart logistics system, a scheme on applying blockchain in smart logistics systems is proposed in [18]. Smart contracts and blockchain ledgers are used to improve the traceability of logistics systems.


## 2.2. Blockchain for IoT

Blockchain has become one of the promising technologies for building secure Internet of things (IoT). Some research efforts are devoted to demonstrating the advantages of blockchain. Yang et al. [19] proposed a decentralized trust management system in vehicular networks based on blockchain techniques. In such a system, vehicles can validate the received messages from neighboring vehicles using the Bayesian Inference Model. To solve the difficulties of traditional centralized storage on the Internet of Vehicles, Jiang et al. [20] investigated how to extend the blockchain to the application of vehicle networks and proposed a model of the outward transmission of the blockchain data. Also, an integrated IoT blockchain platform for sensing data was proposed in [21], and the platform aims to afford the device owner a practical application that provides a comprehensive, immutable log and allows easy access to devices. Moreover, Ma et al. [22] proposed a blockchain-based trusted data management scheme (called BlockTDM) in edge computing. In the proposed BlockTDM, conditional access and decryption queries of the protected blockchain data have been designed, and a user-defined sensitive data encryption approach is utilized to achieve privacy protection. In [23], the authors proposed a multilayer secure IoT model based on the blockchain. This model divides the IoT system into a multilevel decentralized network and uses blockchain technology at all levels of the network. The authors of [24] put forward a blockchain-inspired IoT architecture, which is designed for creating a transparent food supply chain. RFID is used to identify food and other things, and the blockchain is employed to store the food-related sensitive information from IoT devices. In general, the blockchain technology is currently being applied to various IoT application scenarios so as to improve the security of IoT-based systems.


## 2.3. Consensus for IoT-Based Blockchain

Recent studies have utilized different consensus algorithms to establish blockchain-enabled networks for data storage. Proof of Work (PoW) [25] is first used in public blockchains. However, the rapid growth of transactions generated by IoT devices are different from public blockchains, and the traditional PoW algorithm is both resources and time consumption, which may not be suitable for IoT. Puthal et al. [26] presented a novel consensus algorithm called Proof-of-Authentication (PoAh), which introduces a cryptographic authentication mechanism to replace PoW for resource-constrained devices. Furthermore, in [27], the authors proposed a novel lightweight Proof of Block & Trade (PoBT) consensus algorithm for blockchain-based IoT systems, which validates not only the transactions but also the created blocks. Besides, in [27], a complete working solution for the integration of PoBT and Hyperledger Fabric is presented. The consumption of resources and time of PoBT is analyzed through a set of experiments. To improve the security of the Industrial Internet of Things (IIoT), Huang et al. [28] investigated how to extend the blockchain technology to the resource-constrained IoT environment. In detail, a credit-based Proof-of-Work (PoW) mechanism for IoT devices is proposed in [28], which guarantees the system security and the transaction efficiency simultaneously. Liu et al. [29] proposed an anonymous reputation system for IIoT-enabled retail marketing. In detail, the reputation management in the consumer-retailer system is the focus of this work and a blockchain-based reputation management scheme is proposed to provide high-level privacy protection. These accumulated reputation scores are treated as stakes of the corresponding blockchain account. Finally, a PoS-based consensus mechanism is proposed, which utilizes reputation scores to improve the efficiency of systems.


## 3. Preliminaries

In this part, we briefly introduce the necessary background and technologies used in our scheme.


### 3.1. Basic Security Functions

There are several basic algorithms used in our scheme, which are listed as follows:(i)
Setup1k: it takes as input a security parameter 1k and returns the system parameter params, which includes the system keys vandu and a hash function H.(ii)
KeyGenparams,id: it takes as input a public system parameter params and a user identity id and then returns the public and private keys of user AKi=Prik,Pubk.(iii)
Hm: this function is used to generate a fixed-length hash code T of message m.(iv)
SignPrik,m: this function is used to generate a digital signature Sig of message m using user private key Prik.(v)
VerifySigPubk,SigText: this function is used to verify the validity of the signature SigText. Here, the SigText is signed by the corresponding private key of Pubk. Outputs are true if the verifications hold or false otherwise.(vi)
Verifyparams,Pubk,HCert: this function takes the system parameter params and a specific public key Pubk as input parameters to verify the validity of the input certificate Cert.(vii)
EncryptKey,PTm: this function is used to encrypt a plain text PTm by a key Key and returns the corresponding cipher text CTm. This function is suitable for both symmetric and asymmetric encryption.(viii)
DecryptKey,CTm: this function is used to decrypt a cipher text CTm by a key Key and returns the corresponding plain text PTm. Also, this function is suitable for symmetric and asymmetric decryptions.


### 3.2. Related Data Structure

Ublock: Ublock (the block of Userchain) contains transactions about logistics requests. Similar to the block structure of Ethereum, Ublock consists of a block header and a block body. As the core part of blockchain, the block header contains some important parameters about the blockchain, which can be defined as(1)Uheader=ParentHash,Ind,TxHash,Root,Num,Ts,where ParentHash is the hash value of parent block and blocks are linked to each other through this parameter, TxHash is defined as Merkle Patricia Tries root of transactions, Ind is the hash value of Uheader, Root is the MPT (Merkle Patricia Tries) root formed by accounts, and Num and Ts are the number and the generated time of Ublock, respectively.The block body only contains logistics transactions, which are usually published byUser nodes, and can be defined as(2)Txlogistics=IDUi,Si,htxIi,Content,Tsi,As shown in equation (2), the transaction Txlogistics contains the user identity IDUi, timestamp TSi, etc. To specific, the signature Si is signed with the private key Priki as Si=SignPriki,HIDUiContentTsi. Content in equation (2) is the specific information about logistics demands, and this parameter can be a JSON (JavaScript Object Notation) string. Besides, htxIi is the identity of Txlogistics, which can be calculated as htxIi=HIDUi‖Si‖Content‖Tsi.Txlogistics is used to publish user logistics demands, which could be obtained by only authorized logistics providers. To authorize logistics providers, the authorization transaction Txauthorized should be utilized:(3)Txauthorized=IDUi,Envi,Sigi,htxAi,Tsi,(4)Envi=IDP1,2,…,j,htxIi,transkeyi.As shown in equation (3), the user identity IDUi is contained in Txauthorized, and the Sigi is signed with the private key Priki as Sigi=SignPriki,HIDUiEnviTsi. htxAi is the identity of Txauthorized, which can be calculated as htxAi=HIDUiEnviSigi‖Tsi. Also, Envi contains the basic information of providers to be authorized, which can be defined as equation (4). Here, IDP1,2,…,j denotes the identities of providers that need to be authorized and htxIi is the identity of Txlogistics that can be obtained by IDP1,2,…,j. Also, transkeyi is used to encrypt and decrypt the Content field of Txlogistics.Dblock. Similar to Ublock, Dblock can be divided into block header and block body. Here, the design of Dblock is the same as the Ublock, which can be defined as Dheader=ParentHash,Ind,TxHash,Root,Num,Ts.In detail, only one type transaction (i.e.,TxData) should be aggregated into Dblock. TxData contains the logistics data from IoT devices, which can be defined as(5)Txdata=IDj,htxIj,HEIoT,Sigj,Tsj.As shown in equation (5), IDj is the identity of logistics provider who provides logistics services using IoT devices. To reduce the storage overhead, only the hash (i.e., HEIoT) of the encrypted IoT data should be contained in TxData. Also, Sigj is the signature of the private key Prikj as Sigj=SignPrikj,HIDjHEIoTTsj. htxIj is the hash of all the other parts in TxData, which can be calculated as htxIj=HIDjHEIoTSigj‖Tsj. Note that htxIj can be used as the identity of TxData.


## 3.1. Basic Security Functions

There are several basic algorithms used in our scheme, which are listed as follows:(i)
Setup1k: it takes as input a security parameter 1k and returns the system parameter params, which includes the system keys vandu and a hash function H.(ii)
KeyGenparams,id: it takes as input a public system parameter params and a user identity id and then returns the public and private keys of user AKi=Prik,Pubk.(iii)
Hm: this function is used to generate a fixed-length hash code T of message m.(iv)
SignPrik,m: this function is used to generate a digital signature Sig of message m using user private key Prik.(v)
VerifySigPubk,SigText: this function is used to verify the validity of the signature SigText. Here, the SigText is signed by the corresponding private key of Pubk. Outputs are true if the verifications hold or false otherwise.(vi)
Verifyparams,Pubk,HCert: this function takes the system parameter params and a specific public key Pubk as input parameters to verify the validity of the input certificate Cert.(vii)
EncryptKey,PTm: this function is used to encrypt a plain text PTm by a key Key and returns the corresponding cipher text CTm. This function is suitable for both symmetric and asymmetric encryption.(viii)
DecryptKey,CTm: this function is used to decrypt a cipher text CTm by a key Key and returns the corresponding plain text PTm. Also, this function is suitable for symmetric and asymmetric decryptions.


## 3.2. Related Data Structure

Ublock: Ublock (the block of Userchain) contains transactions about logistics requests. Similar to the block structure of Ethereum, Ublock consists of a block header and a block body. As the core part of blockchain, the block header contains some important parameters about the blockchain, which can be defined as(1)Uheader=ParentHash,Ind,TxHash,Root,Num,Ts,where ParentHash is the hash value of parent block and blocks are linked to each other through this parameter, TxHash is defined as Merkle Patricia Tries root of transactions, Ind is the hash value of Uheader, Root is the MPT (Merkle Patricia Tries) root formed by accounts, and Num and Ts are the number and the generated time of Ublock, respectively.The block body only contains logistics transactions, which are usually published byUser nodes, and can be defined as(2)Txlogistics=IDUi,Si,htxIi,Content,Tsi,As shown in equation (2), the transaction Txlogistics contains the user identity IDUi, timestamp TSi, etc. To specific, the signature Si is signed with the private key Priki as Si=SignPriki,HIDUiContentTsi. Content in equation (2) is the specific information about logistics demands, and this parameter can be a JSON (JavaScript Object Notation) string. Besides, htxIi is the identity of Txlogistics, which can be calculated as htxIi=HIDUi‖Si‖Content‖Tsi.Txlogistics is used to publish user logistics demands, which could be obtained by only authorized logistics providers. To authorize logistics providers, the authorization transaction Txauthorized should be utilized:(3)Txauthorized=IDUi,Envi,Sigi,htxAi,Tsi,(4)Envi=IDP1,2,…,j,htxIi,transkeyi.As shown in equation (3), the user identity IDUi is contained in Txauthorized, and the Sigi is signed with the private key Priki as Sigi=SignPriki,HIDUiEnviTsi. htxAi is the identity of Txauthorized, which can be calculated as htxAi=HIDUiEnviSigi‖Tsi. Also, Envi contains the basic information of providers to be authorized, which can be defined as equation (4). Here, IDP1,2,…,j denotes the identities of providers that need to be authorized and htxIi is the identity of Txlogistics that can be obtained by IDP1,2,…,j. Also, transkeyi is used to encrypt and decrypt the Content field of Txlogistics.Dblock. Similar to Ublock, Dblock can be divided into block header and block body. Here, the design of Dblock is the same as the Ublock, which can be defined as Dheader=ParentHash,Ind,TxHash,Root,Num,Ts.In detail, only one type transaction (i.e.,TxData) should be aggregated into Dblock. TxData contains the logistics data from IoT devices, which can be defined as(5)Txdata=IDj,htxIj,HEIoT,Sigj,Tsj.As shown in equation (5), IDj is the identity of logistics provider who provides logistics services using IoT devices. To reduce the storage overhead, only the hash (i.e., HEIoT) of the encrypted IoT data should be contained in TxData. Also, Sigj is the signature of the private key Prikj as Sigj=SignPrikj,HIDjHEIoTTsj. htxIj is the hash of all the other parts in TxData, which can be calculated as htxIj=HIDjHEIoTSigj‖Tsj. Note that htxIj can be used as the identity of TxData.


## 4. System Model and Design Goals

In this section, we introduce the system model and design goals of our proposedLogisticschain.


### 4.1. System Model

As illustrated in Figure1, the proposed Logisticschain mainly includes different components, which can be described as follows:(i)
Users: users should first become legitimate members of the Userchain and submit their logistics requests through terminal devices (e.g., smartphones or desktop computers). In fact, these logistics requests would be collected and encrypted to the Userchain. It is important to note that users do not participate in the construction of blockchain and just connect to blockchain nodes through terminal devices.(ii)
Logistics providers: usually, logistics providers should choose logistics requests based on their abilities to provide logistics services.(iii)
IoT devices: these devices may be RFID, GPS sensors, and scanner devices. In fact, these devices are deployed in warehouses and logistics centers; each of these is connected to one and only one data node as its management node. Besides, these devices are responsible for collecting various logistics-related information to the data node periodically.(iv)
Logistics centers: logistics centers are responsible for receiving and processing logistics items. Enterprises usually deploy computing and storage devices in these centers to process logistics data.(v)
Userchain and Datachain: the proposed Userchain and Datachain are both consortium blockchains (i.e., permissioned blockchains). In this work, blockchains are usually deployed in logistics centers with enough computing and storage resources.(vi)
IPFS storage: the complete logistics records, which include logistics requests from users and sensing data from IoT devices, should be encrypted and stored in the off-blockchain storage system. Here, IPFS (InterPlanetary File System) is used to store complete records due to its decentralized design and storage performance.(vii)
Trusted Authority (TA): as the initializer of our system, any entity which attempts to join the blockchain should register its identity information and obtain the public and private keys.Figure 1
System model.Overview. Users (customers) and logistics providers should complete the identity registration in the TA. During logistics, users could submit logistics demands through terminal devices, and these logistics demands will be packaged into transactions and submitted to the Userchain. Generally, logistics providers could obtain the logistics request from the Userchain, and then the logistics provider is responsible for managing the specific transportation process. IoT devices deployed in transportation vehicles and logistics centers are responsible for collecting logistics status information (e.g., temperature, humidity, and geographical location information). To be specific, the generated logistics records will be aggregated and packaged as transactions into the Datachain.


### 4.2. Design Goals

In this work, we aim to achieve the secure storage of logistics data and the following design goals should be met:(i)
Supporting IoT devices: for the smart logistics system, more and more IoT devices will be connected to generate logistics data. With these devices, users are enabled to monitor logistics information in time, and the system should be able to connect massive IoT devices.(ii)
Data security: logistics data can be treated as the digital assets of users; thus, the sensitive information related to personal privacy should be protected.(iii)
Efficiency: logistics records need to be analyzed and stored in time. Hence, the system should satisfy the practical access requirements on effectiveness and scalability.(iv)
Auditable: it is used to prevent disputes between users and logistics providers. Then, logistics providers should be responsible for the uploaded logistics data. All logistics data should be auditable to ensure disputes’ resolution.


## 4.1. System Model

As illustrated in Figure1, the proposed Logisticschain mainly includes different components, which can be described as follows:(i)
Users: users should first become legitimate members of the Userchain and submit their logistics requests through terminal devices (e.g., smartphones or desktop computers). In fact, these logistics requests would be collected and encrypted to the Userchain. It is important to note that users do not participate in the construction of blockchain and just connect to blockchain nodes through terminal devices.(ii)
Logistics providers: usually, logistics providers should choose logistics requests based on their abilities to provide logistics services.(iii)
IoT devices: these devices may be RFID, GPS sensors, and scanner devices. In fact, these devices are deployed in warehouses and logistics centers; each of these is connected to one and only one data node as its management node. Besides, these devices are responsible for collecting various logistics-related information to the data node periodically.(iv)
Logistics centers: logistics centers are responsible for receiving and processing logistics items. Enterprises usually deploy computing and storage devices in these centers to process logistics data.(v)
Userchain and Datachain: the proposed Userchain and Datachain are both consortium blockchains (i.e., permissioned blockchains). In this work, blockchains are usually deployed in logistics centers with enough computing and storage resources.(vi)
IPFS storage: the complete logistics records, which include logistics requests from users and sensing data from IoT devices, should be encrypted and stored in the off-blockchain storage system. Here, IPFS (InterPlanetary File System) is used to store complete records due to its decentralized design and storage performance.(vii)
Trusted Authority (TA): as the initializer of our system, any entity which attempts to join the blockchain should register its identity information and obtain the public and private keys.Figure 1
System model.Overview. Users (customers) and logistics providers should complete the identity registration in the TA. During logistics, users could submit logistics demands through terminal devices, and these logistics demands will be packaged into transactions and submitted to the Userchain. Generally, logistics providers could obtain the logistics request from the Userchain, and then the logistics provider is responsible for managing the specific transportation process. IoT devices deployed in transportation vehicles and logistics centers are responsible for collecting logistics status information (e.g., temperature, humidity, and geographical location information). To be specific, the generated logistics records will be aggregated and packaged as transactions into the Datachain.


## 4.2. Design Goals

In this work, we aim to achieve the secure storage of logistics data and the following design goals should be met:(i)
Supporting IoT devices: for the smart logistics system, more and more IoT devices will be connected to generate logistics data. With these devices, users are enabled to monitor logistics information in time, and the system should be able to connect massive IoT devices.(ii)
Data security: logistics data can be treated as the digital assets of users; thus, the sensitive information related to personal privacy should be protected.(iii)
Efficiency: logistics records need to be analyzed and stored in time. Hence, the system should satisfy the practical access requirements on effectiveness and scalability.(iv)
Auditable: it is used to prevent disputes between users and logistics providers. Then, logistics providers should be responsible for the uploaded logistics data. All logistics data should be auditable to ensure disputes’ resolution.


## 5. The Proposed Scheme

In this section, we describe the proposed scheme in detail. The key notations used in this paper are listed in Table1.Table 1
Key notations.
NotationDescriptionk,p,GSecurity parameter, prime number, and cyclic groupH.Keyed hash functionIDi, UiIdentity of the useriREQi, RESiLogistics request and responseCertiCertificate of the nodeiTsTimestampPubki,PrikiPublic key and private key of the nodeisAddr, dAddrDestination and source addresses of itemsDnodei, UnodeiMember node of the blockchainTxdata,TxlogisticsBlockchain transactions used in this schemeCTxEncrypted content forxPaujThe logistics service providerjtranskeyiKey to encrypt logistics data in transactions.Encrypt., E.Encryption functionsNaNumber of nodes’ group


### 5.1. System Initialization

TA (Trusted Authority) as the system administrator is responsible for system initialization. TA publishes the system parameters with a given security parameter 1k, which can be described as the following steps:(i)
Step 1: big enough prime numberq is chosen; then, TA generates three cyclic groups G1, G2, and GT of the same order q with generator g and bilinear map e:G1×G2⟶GT.(ii)
Step 2:TA chooses hash function H: 0,1∗⟶Zq∗.(iii)
Step 3:TA chooses a symmetric encryption function, such as AES, E:0,1∗⟶0,1∗, and an asymmetric encryption function Encrypt., such as ECC and RSA algorithms.(iv)
Step 4: finally,TA publishes the system parameters as q,G1,G2,GT,e,H,E,Encrypt.


### 5.2. Entity Registration

Users and logistics providers should first register their identities and obtain certificates from the system. The detail process can be described as the following steps:(i)
Step 1: a user or logistics providerUi sends the identity information Infoi to TA through a secure channel as Ui⟶TA:Infoi.(ii)
Step 2:TA should encrypt the received Infoi as EKeyTA,Infoi‖Tsi⟶CTInfoi. Then, TA uploads the encrypted information CTInfoi to IPFS and obtains a storage credential HEInfoi, which can be used to retrieve the stored information in IPFS.(iii)
Step 3:Ui should generate the public and private keys as KeyGenparams,Infoi⟶ (Pubki, Priki) and register his/her blockchain account in Userchain or Datachain to obtain the corresponding blockaddress BlockAddri with the assistance of TA.(iv)
Step 4:TA publishes a certificate to Ui as TA⟶Ui:Certi=HEInfoi,Pubki,BlockAddri,SigTA,Tsi.OnceUi has completed the registration in Logisticschain, the authorized Certi should be stored properly.


### 5.3. Logistics Requesting

A userUi with the identity IDUi (i.e., HEInfoi), starting and ending timestamp t1 and t2, and a current location loci could publish his/her logistics request transactions to Userchain so that logistics providers could obtain the real-time logistics demands. This process can be described as follows:(i)
Ui collects a batch of items Transitems and extracts the type of Transitems as τ=φTransitems. The estimated weight of Transitems is ω and the required latest delivery time is Tsl. Besides, Ui should clearly define the source address sAddr and the destination address dAddr.(ii)
Ui defines the logistics request as REQUi=IDUi,EnvTransitems,τ,ω,sAddr,dAddr,Tsl,SigUi, where SigUi=SignPriki,HREQUi.(iii)
REQUi is encrypted as Encrypttranskeyi,REQUi⟶CTREQUi using the transkeyi with the assistance of terminal devices. Then, Ui should construct a logistics transaction as equation (2) and pack CTREQUi as the content field.(iv)
Finally,Ui should publish an authorization transaction TxAuthorized as equation (3), which includes identities of the logistics providers to be authorized. Note that one authorization transaction can be used to decrypt only one Txlogistics.In fact,TxAuthorized should be broadcast throughout the Userchain, but only several authorized providers could obtain the transkeyi to decrypt the logistics transaction Txlogistics. Overall, the simplified process of publishing logistics transactions can be illustrated in Figure 2.Figure 2
Flowchart of publishing logistics transactions.


### 5.4. Logistics Responding

After receiving aTxlogistics and the authorization transaction Txauthorized, a specific node Unodei in the Userchain should check the validity of Txlogistics by invoking VerifySigPubki,Txlogistics.Si. If it holds, Unodei would extract the identities of authorized providers as IdSet=ID1,ID2,…,IDj from the received Txauthorized. After that, Unodei would check its connected providers whether they are in IdSet. If any authorized provider is connected to Unodei, the received Txauthorized and Txlogistics would be sent to the provider through a secure channel, and the generation process of response can be described as follows:(i)
Step 1: an authorized providerPauj who obtains the transaction (i.e., Txlogistics or Txauthorized) would check if the transaction has expired by verifying Tsnow−Txlogistics.Tsi<Δt. If Txlogistics has expired, the transaction would be discarded.(ii)
Step 2:Pauj checks the validity of Txauthorized by verifying Txauthorized.Envi.htxIi=?Txlogistics.htxIi. If it holds, Pauj could extract transaction keys from Txauthorized as ObtainTranskeysTxauthorized⟶transkeyi.(iii)
Step 3:Pauj could obtain the original logistics request REQi as Decrypttranskeyi,Txlogistics.Content⟶REQi. Moreover, Pauj verifies the validity of the received Pauj by computing VerifySigPubki,REQi.SigUi.(iv)
Step 4:Pauj should generate a response RESj to the received Txlogistics. In detail, we can define RESj as Pauj,Feedbackj⟶iaccept/decline,htxIi,Tsj,Sigauj, where Sigauj in REQj can be calculated as Sigauj=SignPrikauj,HPauj‖Feedbackj⟶ihtxIiTsj.(v)
Step 5:RESj is encrypted as Etranskeyi,RESj⟶CTRESj. Thus, we can define the response package as ℜ=CTRESj,Htranskey‖CTRESj, which should be sent to Unodei through terminal devices. In fact, ℜ would be packed into a transaction and broadcast throughout the blockchain (i.e., Userchain).Figure3 shows the process of publishing response from logistics providers.Figure 3
Flowchart of publishing logistics response.


### 5.5. Data Uploading from IoT Devices

When a logistics providerPauj accepts a logistics transaction Txlogistcs, the corresponding member nodes (i.e., Datachain node) should authorize the connected IoT devices (i.e., issuing certificates to these devices). Specifically, IoT devices IotSet=iot1,iot2,…,iotn, which may be temperature and humidity sensors, and member nodes are responsible for filtering and summarizing information from IotSet in distributed warehouse centers. In Logisticschain, the data storage function consists of the original records storage based on IPFS and the hash value storage based on Datachain. Thus, the storage process can be described as follows:(i)
We definesDatai=s1′,s2′,…,sn′ to represent the sensing data from a specific IoT device ioti, and ioti is connected to the Dnodei (i.e., a Datachain node). Besides, ioti should store the identity of Txlogistics (i.e., htxIi) so that the sensing data could be associated with the specific logistics request Txlogistics.(ii)
The deviceioti sends a data package as dpacki=sDatai,htxIi,Tsi to Dnodei through a secure channel.(iii)
Dnodei first collects dpacki from ioti and aggregates the sensing data based on the contained htxIi. Then, Dnodei verifies the obtained sDatai and encrypts sDatai with transkeyi as Etranskeyi,sDatai⟶CTsDatai.(iv)
Dnodei generates htxIi,CTsDatai,Ts,ςi, where ςi in this package is signed by Pauj with the private key Prikauj.(v)
ςi=SignPrikauj,HhtxIiCTsDataiTs.(vi)
The generated package should be sent to the IPFS system through a secure channel; then, the storage hashHEIoTi would be returned from the IPFS system. After that, Dnodei generates a logistics data transaction as Txdata=Pubkauj,htxIj,HEIoTi,Sigj,Tsj, where Sigj=SignPrikauj,HPubkaujHEIoTiTsj. Finally, the generated transaction Txdata would be published to the Datachain.After completing the storage process of logistics data, another important thing is to update and maintain the mapping between the published logistics request and the stored logistics sensing data. A smart contract should be defined and deployed inUserchain to maintain the relationship between logistics requests and sensing data. To be specific, such a smart contract can be executed by authorized blockchain nodes and a mapping type variable LogisticsRecordsMap=MaphtxIi⇒LogisticsRd is used to store the relationship. Here, htxIi is the identity of logistics request transaction, and we can define the LogisticsRd as follows:Typedefine Struct LogisticsRd {TransIdsensing: String, Keyiot: String, PubkPauj: String, IpAddr: String, BlockAddr: Address, Timestamp: Long }.In the definedLogisticsRd, TransIdsensing is the identity of Txdata, which is generated by Dnodei. IpAddr and BlockAddr denote the IP and the blockchain address of Dnodei, respectively. In addition, Keyiot is the public key of the specific device that generates the sensing data. Algorithm 1 presents the functionality when a member node tends to set up mapping records.Algorithm 1:LogisticsRd storage process.
Input: Rdi denotes one of mapping records,LogisticsRecordsMap is a mapping array variable,htxIi is a transaction id of Txlogistics.Output: Boolean.(1)
ifmsg.sender does not exist then(2)
return false;(3)
end if(4)
ifRdi is NULL or htxIi is NULL then(5)
return false;(6)
end if(7)
HhtxIi⟶index;(8)
if empty(LogisticsRecordsMapindex) then(9)
LogisticsRecordsMapindex= new LogisticsRd [];(10)
end if(11)
HRdi⟶Rindex;(12)
ifRindexinLogisticsRecordsMapindexthen(13)
return false;(14)
end if(15)
LogisticsRecordsMapindexRindex=Rdi;(16)
return true;


### 5.6. Data Auditing

Once there are logistics disputes between users and logistics providers, a reliable audit mechanism could provide a basis for resolving these disputes. Therefore, we propose a blockchain-based audit mechanism for logistics data in this study. For instance, a userUi can audit his/her logistics transaction Txlogistics as follows:(i)
Step 1: in this process, we should first obtain the transaction idhtxIi of the audited Txlogistics; then, utilize htxIi to retrieve the transaction from the defined mapping variable LogisticsRecordsMap as LogisticsRecordsMapHhtxIi⟶LogisticsRds.(ii)
Step 2: we can useLogisticsRds.TransIdsensingi (i.e., the identity of Txdata) to obtain the data transaction Txdata, and then acquire the identity (i.e., Txdata.HEIoTi ) of original data from Txdata.(iii)
Step 3: because the IPFS system is based on content addressing (i.e., the access address of a file is generated by hashing the content of the file), if we could obtain the sensing data from the IPFS system using the obtainedTxdata.HEIoTi, then the stored original logistics data are still reliable and have not been modified. Otherwise, the data are untrustworthy.Based on the decentralized environment provided by our scheme, we can strictly audit all logistics data stored in the IPFS system, as shown in Algorithm2.Algorithm 2: Data auditing process.
Input: htxIi is a transaction id of the logistics request,LogisticsRecordsMap is a mapping array variable.Output: Boolean.(1)
ifhtxIi is NULL or empty(LogisticsRecordsMap)then(2)
return false;(3)
end if(4)
HhtxIi⟶index;(5)
LogisticsRecordsMapindex⟶LogisticsRds;(6)
forobjlogistics in LogisticsRdsdo(7)
objlogistics.TransIdsensing⟶IdTxdata;(8)
getTransByIdIdTxdata,Datachain⟶Txdata;(9)
Txdata.HEIoTi⟶storageIdIPFS;(10)
getFileofIPFSstorageIdIPFS⟶retfile;(11)
ifretfile  = = (NULL or FALSE) then(12)
return false;(13)
end if(14)
end for(15)
return true;


### 5.7. Group-Based PoW Mechanism

In our proposed scheme, each member node can participate in block packaging. A consensus protocol is the core of blockchain, which can determine the ownership of block packaging rights. As we know, the famous PoW and PoS consensuses are widely used in blockchain applications (e.g., Bitcoin, Ethereum, and EoS). However, the PoW consensus usually leads to unnecessary cost of computational resources, and the PoS consensus would reduce the decentralization of the blockchain network. These issues may affect the performance and security of the blockchain-based systems. Specific to our scheme, the efficiency and security of the employed blockchain should be guaranteed because the logistics data are relevant to customer benefits and privacy. Therefore, under the premise of ensuring the decentralization of blockchain, we propose a novel group-based PoW consensus, which allows nodes to be grouped freely to avoid large-scale hash computing and reduce the number of participating nodes. To make our proposed consensus better understood, we introduce the consensus process as follows:(1)
Basic Setting. We can assume that Nodes=nd1,nd2,…,ndn represents all nodes that compete for the packaging rights at time t. Here, we attempt to divide these nodes into Na1≤Na≤N groups.(2)
Group Partition. Each node ndi∈Nodes generates a random number randNumi and calculates its group id asgidi=randNumi⊕Pubki⊕TsiModNa. After that, ndi will exchange its group id in the P2P (Peer-to-Peer) network by broadcasting a synchronization message SYNi=gidi,HCerti,BlockAddri,Sigi,TsiIDi. When a node ndj∈Nodes with the group id gidj receives SYNi, it should verify the validity of SYNi and check gidi=?gidj. If it holds, ndj will generate a group item gtj⟶i=numi,IPAddri,BlockAddri,Signodej,Tsj and add gtj⟶i into its group table, as shown in Table 2. Otherwise, the SYNi would be discarded by ndj. After the group synchronization of Nodes has been completed within ΔT duration, all of these nodes will eventually obtain its entire group table.(3)
Leader Selection. For the autonomous group agroupi, ndi∈agroupi could participate in the group leader selection. Specifically, the selection process can be briefly divided into the selection proposal and selection declaration stages, and we can describe the selection process as the following steps.(i)
Step 1.ndi could participate in the election of leader after the network is stable. Here, we set a network waiting time Δtw (e.g., 5s or 15s) for ndi. If the number of member nodes in agroupi does not change during Δtw, then agroupi is considered to be in a stable state. Furthermore, if no node in agroupi is declared as a leader during Δtw, then ndi should perform Step 2.(ii)
Step 2.ndi generates a selection proposal Selproposal=Sid=HPubki‖Tsi,isLeaderfalse,Sigi,Tsi and sets a propagation time Δtp. Selproposal will be broadcast to other nodes in agroupi according to the generated group table. In fact, other nodes in agroupi should store the received Selproposal temporarily. Thus, if any other node ndj has been declared as a leader during Δtp, then ndi will drop its election proposal and marks ndj as the leader of agroupi. Otherwise, the election procedure will execute Step 3.(iii)
Step 3. After Δtp, all of nodes (including the node ndi) in agroupi should aggregate the received selection proposals and choose the node with the largest Sid∈Selproposal as the leader of agroupi. It is clearly that if only ndi puts forward a selection proposal or there are multiple proposals and Sid∈Selproposal of ndi is the largest, then ndi will be marked as the leader.(iv)
Step 4. We assume that ndi is the selected leader of agroupi; then, ndi should generate a selection declaration Seldeclaration=Pubki,is Leadertrue,Sigi,Tsi and broadcast the generated Seldeclaration to other nodes in agroupi. After receiving and verifying Seldeclaration from ndi, all nodes in agroupi will remove the received selection proposals and mark ndi as their leader locally.It is important to note that only one round of selection is needed to determine a leader node due to the uniqueSid=HPubki‖Tsi in Selproposal.(4)
Block Generation.Leaders=ln1,ln2,…,lnn denotes the selected group leaders of the network, and each lni∈Leaders competes for block generation through the PoW protocol [25] (i.e., compare the power of computing by large-scale mathematical calculations). To specific, lni∈Leaders that has obtained the block packaging rights should aggregate transactions into a new block and notify member nodes to synchronize the generated block. Once the blockchain has been updated, all the autonomous groups would be cancelled. In the next round of block generation, autonomous groups need to be rebuilt to avoid the nodes with strong computing power controlling the whole network. Here, we can summarize the above selection process, as shown in Algorithm 3.Table 2
Sample content of the group table.
NodeNumIPBlockchainAddressTimestamp0192.168.112.230x46c0c3795914 fB…15829687611192.168.112.260x6c0A4A4F08730…15829688952192.168.112.560x2dAbo2820A11 A…1582968453…………n192.168.112.950xEE89c5b213e07e…1582968542In practical terms, we assume that there areN nodes in the system and would be divided into Na groups. The total computational time Tt is composed of the groups partition time Tg, the leaders selection time Te, and the block generation and consensus formation time Tv; then, Tt=∑Ti,i∈g,e,v. To be specific, Tg is generally composed of gidi generation and time and SYNi generation and broadcast time; Te is composed of Selproposal and Seldeclaration generation and broadcast time. As for Tv, we just consider the computational time of the target hash value. For simplicity, let us denote the entity (e.g., gidi, SYNi, and Selproposal) generation time as tgobj, the broadcast time as tbobj, and the hash computing time in PoW as th; then, the block generation time Tt can be computed as(6)Tt=∑i=1Ntggid&SYNi+tbgid&SYNi+∑i=1k¯tgSeli+tbSeli+∑i=1Nathi,where k¯ is the number of nodes participating in leader election of the whole network, and the leaders’ election time is Te=∑i=1k¯tgSelpro&deci+tbSelpro&deci. Also, the consensus process is participated by leaders of all groups and the consensus formation time can be calculated as Tv=∑i=1Nathi. Furthermore, we can see that the time complexity of Algorithm 3 is related to the execution frequency of lines 10–13. Then, we assume that the number of nodes in groups is num1,num2,…,numNa and ∑i=1Nanumi=N. Hence, the execution frequency of lines 10–13 is Fn=4∗∑i=1Nanumi=4∗N. Thus, the time complexity of Algorithm 3 is ON. Note that if Na=N, our group-based PoW consensus is equivalent to the traditional PoW method.Algorithm 3: Group-based PoW consensus.
Input: Nodes=nd1,nd2,…,ndn represents all nodes,Na is the number of groups.(1)
nd1,nd2,…,ndn⟶Nodes, groups, Na;(2)
forndi∈Nodesdo(3)
ndi.generateRandom⟶randomNum;(4)
gidi=randomNum⊕Pubki⊕Tsi%Na;(5)
ndi.broadcastNetworkgidi,Nodes;(6)
ndi.obtainGroup⟶groups,groupTableg1,…,gn;(7)
end for(8)
forgi∈groupsdo(9)
forndj∈gidoΔLeader Selection(10)
waittoStableΔtw;(11)
Selproposal=ndj.genProposal;(12)
ndj.broadcastSelproposal,groupTablegi;(13)
waitPropagationΔtp;(14)
end for(15)
li=getLeaderSelproposal1,…,Selproposaln;(16)
Seldeclaration=li.genDeclaration;(17)
li.broadcastTogroupsSeldeclaration,gi;(18)
leaders.addli;(19)
freeSelproposal1,…,Selproposaln;(20)
end for(21)
forli∈leadersdo(22)
executePoWprotocol⟶miner;(23)
end for(24)
miner.generateBlock;(25)
miner.notify;(26)
freegroups;


## 5.1. System Initialization

TA (Trusted Authority) as the system administrator is responsible for system initialization. TA publishes the system parameters with a given security parameter 1k, which can be described as the following steps:(i)
Step 1: big enough prime numberq is chosen; then, TA generates three cyclic groups G1, G2, and GT of the same order q with generator g and bilinear map e:G1×G2⟶GT.(ii)
Step 2:TA chooses hash function H: 0,1∗⟶Zq∗.(iii)
Step 3:TA chooses a symmetric encryption function, such as AES, E:0,1∗⟶0,1∗, and an asymmetric encryption function Encrypt., such as ECC and RSA algorithms.(iv)
Step 4: finally,TA publishes the system parameters as q,G1,G2,GT,e,H,E,Encrypt.


## 5.2. Entity Registration

Users and logistics providers should first register their identities and obtain certificates from the system. The detail process can be described as the following steps:(i)
Step 1: a user or logistics providerUi sends the identity information Infoi to TA through a secure channel as Ui⟶TA:Infoi.(ii)
Step 2:TA should encrypt the received Infoi as EKeyTA,Infoi‖Tsi⟶CTInfoi. Then, TA uploads the encrypted information CTInfoi to IPFS and obtains a storage credential HEInfoi, which can be used to retrieve the stored information in IPFS.(iii)
Step 3:Ui should generate the public and private keys as KeyGenparams,Infoi⟶ (Pubki, Priki) and register his/her blockchain account in Userchain or Datachain to obtain the corresponding blockaddress BlockAddri with the assistance of TA.(iv)
Step 4:TA publishes a certificate to Ui as TA⟶Ui:Certi=HEInfoi,Pubki,BlockAddri,SigTA,Tsi.OnceUi has completed the registration in Logisticschain, the authorized Certi should be stored properly.


## 5.3. Logistics Requesting

A userUi with the identity IDUi (i.e., HEInfoi), starting and ending timestamp t1 and t2, and a current location loci could publish his/her logistics request transactions to Userchain so that logistics providers could obtain the real-time logistics demands. This process can be described as follows:(i)
Ui collects a batch of items Transitems and extracts the type of Transitems as τ=φTransitems. The estimated weight of Transitems is ω and the required latest delivery time is Tsl. Besides, Ui should clearly define the source address sAddr and the destination address dAddr.(ii)
Ui defines the logistics request as REQUi=IDUi,EnvTransitems,τ,ω,sAddr,dAddr,Tsl,SigUi, where SigUi=SignPriki,HREQUi.(iii)
REQUi is encrypted as Encrypttranskeyi,REQUi⟶CTREQUi using the transkeyi with the assistance of terminal devices. Then, Ui should construct a logistics transaction as equation (2) and pack CTREQUi as the content field.(iv)
Finally,Ui should publish an authorization transaction TxAuthorized as equation (3), which includes identities of the logistics providers to be authorized. Note that one authorization transaction can be used to decrypt only one Txlogistics.In fact,TxAuthorized should be broadcast throughout the Userchain, but only several authorized providers could obtain the transkeyi to decrypt the logistics transaction Txlogistics. Overall, the simplified process of publishing logistics transactions can be illustrated in Figure 2.Figure 2
Flowchart of publishing logistics transactions.


## 5.4. Logistics Responding

After receiving aTxlogistics and the authorization transaction Txauthorized, a specific node Unodei in the Userchain should check the validity of Txlogistics by invoking VerifySigPubki,Txlogistics.Si. If it holds, Unodei would extract the identities of authorized providers as IdSet=ID1,ID2,…,IDj from the received Txauthorized. After that, Unodei would check its connected providers whether they are in IdSet. If any authorized provider is connected to Unodei, the received Txauthorized and Txlogistics would be sent to the provider through a secure channel, and the generation process of response can be described as follows:(i)
Step 1: an authorized providerPauj who obtains the transaction (i.e., Txlogistics or Txauthorized) would check if the transaction has expired by verifying Tsnow−Txlogistics.Tsi<Δt. If Txlogistics has expired, the transaction would be discarded.(ii)
Step 2:Pauj checks the validity of Txauthorized by verifying Txauthorized.Envi.htxIi=?Txlogistics.htxIi. If it holds, Pauj could extract transaction keys from Txauthorized as ObtainTranskeysTxauthorized⟶transkeyi.(iii)
Step 3:Pauj could obtain the original logistics request REQi as Decrypttranskeyi,Txlogistics.Content⟶REQi. Moreover, Pauj verifies the validity of the received Pauj by computing VerifySigPubki,REQi.SigUi.(iv)
Step 4:Pauj should generate a response RESj to the received Txlogistics. In detail, we can define RESj as Pauj,Feedbackj⟶iaccept/decline,htxIi,Tsj,Sigauj, where Sigauj in REQj can be calculated as Sigauj=SignPrikauj,HPauj‖Feedbackj⟶ihtxIiTsj.(v)
Step 5:RESj is encrypted as Etranskeyi,RESj⟶CTRESj. Thus, we can define the response package as ℜ=CTRESj,Htranskey‖CTRESj, which should be sent to Unodei through terminal devices. In fact, ℜ would be packed into a transaction and broadcast throughout the blockchain (i.e., Userchain).Figure3 shows the process of publishing response from logistics providers.Figure 3
Flowchart of publishing logistics response.


## 5.5. Data Uploading from IoT Devices

When a logistics providerPauj accepts a logistics transaction Txlogistcs, the corresponding member nodes (i.e., Datachain node) should authorize the connected IoT devices (i.e., issuing certificates to these devices). Specifically, IoT devices IotSet=iot1,iot2,…,iotn, which may be temperature and humidity sensors, and member nodes are responsible for filtering and summarizing information from IotSet in distributed warehouse centers. In Logisticschain, the data storage function consists of the original records storage based on IPFS and the hash value storage based on Datachain. Thus, the storage process can be described as follows:(i)
We definesDatai=s1′,s2′,…,sn′ to represent the sensing data from a specific IoT device ioti, and ioti is connected to the Dnodei (i.e., a Datachain node). Besides, ioti should store the identity of Txlogistics (i.e., htxIi) so that the sensing data could be associated with the specific logistics request Txlogistics.(ii)
The deviceioti sends a data package as dpacki=sDatai,htxIi,Tsi to Dnodei through a secure channel.(iii)
Dnodei first collects dpacki from ioti and aggregates the sensing data based on the contained htxIi. Then, Dnodei verifies the obtained sDatai and encrypts sDatai with transkeyi as Etranskeyi,sDatai⟶CTsDatai.(iv)
Dnodei generates htxIi,CTsDatai,Ts,ςi, where ςi in this package is signed by Pauj with the private key Prikauj.(v)
ςi=SignPrikauj,HhtxIiCTsDataiTs.(vi)
The generated package should be sent to the IPFS system through a secure channel; then, the storage hashHEIoTi would be returned from the IPFS system. After that, Dnodei generates a logistics data transaction as Txdata=Pubkauj,htxIj,HEIoTi,Sigj,Tsj, where Sigj=SignPrikauj,HPubkaujHEIoTiTsj. Finally, the generated transaction Txdata would be published to the Datachain.After completing the storage process of logistics data, another important thing is to update and maintain the mapping between the published logistics request and the stored logistics sensing data. A smart contract should be defined and deployed inUserchain to maintain the relationship between logistics requests and sensing data. To be specific, such a smart contract can be executed by authorized blockchain nodes and a mapping type variable LogisticsRecordsMap=MaphtxIi⇒LogisticsRd is used to store the relationship. Here, htxIi is the identity of logistics request transaction, and we can define the LogisticsRd as follows:Typedefine Struct LogisticsRd {TransIdsensing: String, Keyiot: String, PubkPauj: String, IpAddr: String, BlockAddr: Address, Timestamp: Long }.In the definedLogisticsRd, TransIdsensing is the identity of Txdata, which is generated by Dnodei. IpAddr and BlockAddr denote the IP and the blockchain address of Dnodei, respectively. In addition, Keyiot is the public key of the specific device that generates the sensing data. Algorithm 1 presents the functionality when a member node tends to set up mapping records.Algorithm 1:LogisticsRd storage process.
Input: Rdi denotes one of mapping records,LogisticsRecordsMap is a mapping array variable,htxIi is a transaction id of Txlogistics.Output: Boolean.(1)
ifmsg.sender does not exist then(2)
return false;(3)
end if(4)
ifRdi is NULL or htxIi is NULL then(5)
return false;(6)
end if(7)
HhtxIi⟶index;(8)
if empty(LogisticsRecordsMapindex) then(9)
LogisticsRecordsMapindex= new LogisticsRd [];(10)
end if(11)
HRdi⟶Rindex;(12)
ifRindexinLogisticsRecordsMapindexthen(13)
return false;(14)
end if(15)
LogisticsRecordsMapindexRindex=Rdi;(16)
return true;


## 5.6. Data Auditing

Once there are logistics disputes between users and logistics providers, a reliable audit mechanism could provide a basis for resolving these disputes. Therefore, we propose a blockchain-based audit mechanism for logistics data in this study. For instance, a userUi can audit his/her logistics transaction Txlogistics as follows:(i)
Step 1: in this process, we should first obtain the transaction idhtxIi of the audited Txlogistics; then, utilize htxIi to retrieve the transaction from the defined mapping variable LogisticsRecordsMap as LogisticsRecordsMapHhtxIi⟶LogisticsRds.(ii)
Step 2: we can useLogisticsRds.TransIdsensingi (i.e., the identity of Txdata) to obtain the data transaction Txdata, and then acquire the identity (i.e., Txdata.HEIoTi ) of original data from Txdata.(iii)
Step 3: because the IPFS system is based on content addressing (i.e., the access address of a file is generated by hashing the content of the file), if we could obtain the sensing data from the IPFS system using the obtainedTxdata.HEIoTi, then the stored original logistics data are still reliable and have not been modified. Otherwise, the data are untrustworthy.Based on the decentralized environment provided by our scheme, we can strictly audit all logistics data stored in the IPFS system, as shown in Algorithm2.Algorithm 2: Data auditing process.
Input: htxIi is a transaction id of the logistics request,LogisticsRecordsMap is a mapping array variable.Output: Boolean.(1)
ifhtxIi is NULL or empty(LogisticsRecordsMap)then(2)
return false;(3)
end if(4)
HhtxIi⟶index;(5)
LogisticsRecordsMapindex⟶LogisticsRds;(6)
forobjlogistics in LogisticsRdsdo(7)
objlogistics.TransIdsensing⟶IdTxdata;(8)
getTransByIdIdTxdata,Datachain⟶Txdata;(9)
Txdata.HEIoTi⟶storageIdIPFS;(10)
getFileofIPFSstorageIdIPFS⟶retfile;(11)
ifretfile  = = (NULL or FALSE) then(12)
return false;(13)
end if(14)
end for(15)
return true;


## 5.7. Group-Based PoW Mechanism

In our proposed scheme, each member node can participate in block packaging. A consensus protocol is the core of blockchain, which can determine the ownership of block packaging rights. As we know, the famous PoW and PoS consensuses are widely used in blockchain applications (e.g., Bitcoin, Ethereum, and EoS). However, the PoW consensus usually leads to unnecessary cost of computational resources, and the PoS consensus would reduce the decentralization of the blockchain network. These issues may affect the performance and security of the blockchain-based systems. Specific to our scheme, the efficiency and security of the employed blockchain should be guaranteed because the logistics data are relevant to customer benefits and privacy. Therefore, under the premise of ensuring the decentralization of blockchain, we propose a novel group-based PoW consensus, which allows nodes to be grouped freely to avoid large-scale hash computing and reduce the number of participating nodes. To make our proposed consensus better understood, we introduce the consensus process as follows:(1)
Basic Setting. We can assume that Nodes=nd1,nd2,…,ndn represents all nodes that compete for the packaging rights at time t. Here, we attempt to divide these nodes into Na1≤Na≤N groups.(2)
Group Partition. Each node ndi∈Nodes generates a random number randNumi and calculates its group id asgidi=randNumi⊕Pubki⊕TsiModNa. After that, ndi will exchange its group id in the P2P (Peer-to-Peer) network by broadcasting a synchronization message SYNi=gidi,HCerti,BlockAddri,Sigi,TsiIDi. When a node ndj∈Nodes with the group id gidj receives SYNi, it should verify the validity of SYNi and check gidi=?gidj. If it holds, ndj will generate a group item gtj⟶i=numi,IPAddri,BlockAddri,Signodej,Tsj and add gtj⟶i into its group table, as shown in Table 2. Otherwise, the SYNi would be discarded by ndj. After the group synchronization of Nodes has been completed within ΔT duration, all of these nodes will eventually obtain its entire group table.(3)
Leader Selection. For the autonomous group agroupi, ndi∈agroupi could participate in the group leader selection. Specifically, the selection process can be briefly divided into the selection proposal and selection declaration stages, and we can describe the selection process as the following steps.(i)
Step 1.ndi could participate in the election of leader after the network is stable. Here, we set a network waiting time Δtw (e.g., 5s or 15s) for ndi. If the number of member nodes in agroupi does not change during Δtw, then agroupi is considered to be in a stable state. Furthermore, if no node in agroupi is declared as a leader during Δtw, then ndi should perform Step 2.(ii)
Step 2.ndi generates a selection proposal Selproposal=Sid=HPubki‖Tsi,isLeaderfalse,Sigi,Tsi and sets a propagation time Δtp. Selproposal will be broadcast to other nodes in agroupi according to the generated group table. In fact, other nodes in agroupi should store the received Selproposal temporarily. Thus, if any other node ndj has been declared as a leader during Δtp, then ndi will drop its election proposal and marks ndj as the leader of agroupi. Otherwise, the election procedure will execute Step 3.(iii)
Step 3. After Δtp, all of nodes (including the node ndi) in agroupi should aggregate the received selection proposals and choose the node with the largest Sid∈Selproposal as the leader of agroupi. It is clearly that if only ndi puts forward a selection proposal or there are multiple proposals and Sid∈Selproposal of ndi is the largest, then ndi will be marked as the leader.(iv)
Step 4. We assume that ndi is the selected leader of agroupi; then, ndi should generate a selection declaration Seldeclaration=Pubki,is Leadertrue,Sigi,Tsi and broadcast the generated Seldeclaration to other nodes in agroupi. After receiving and verifying Seldeclaration from ndi, all nodes in agroupi will remove the received selection proposals and mark ndi as their leader locally.It is important to note that only one round of selection is needed to determine a leader node due to the uniqueSid=HPubki‖Tsi in Selproposal.(4)
Block Generation.Leaders=ln1,ln2,…,lnn denotes the selected group leaders of the network, and each lni∈Leaders competes for block generation through the PoW protocol [25] (i.e., compare the power of computing by large-scale mathematical calculations). To specific, lni∈Leaders that has obtained the block packaging rights should aggregate transactions into a new block and notify member nodes to synchronize the generated block. Once the blockchain has been updated, all the autonomous groups would be cancelled. In the next round of block generation, autonomous groups need to be rebuilt to avoid the nodes with strong computing power controlling the whole network. Here, we can summarize the above selection process, as shown in Algorithm 3.Table 2
Sample content of the group table.
NodeNumIPBlockchainAddressTimestamp0192.168.112.230x46c0c3795914 fB…15829687611192.168.112.260x6c0A4A4F08730…15829688952192.168.112.560x2dAbo2820A11 A…1582968453…………n192.168.112.950xEE89c5b213e07e…1582968542In practical terms, we assume that there areN nodes in the system and would be divided into Na groups. The total computational time Tt is composed of the groups partition time Tg, the leaders selection time Te, and the block generation and consensus formation time Tv; then, Tt=∑Ti,i∈g,e,v. To be specific, Tg is generally composed of gidi generation and time and SYNi generation and broadcast time; Te is composed of Selproposal and Seldeclaration generation and broadcast time. As for Tv, we just consider the computational time of the target hash value. For simplicity, let us denote the entity (e.g., gidi, SYNi, and Selproposal) generation time as tgobj, the broadcast time as tbobj, and the hash computing time in PoW as th; then, the block generation time Tt can be computed as(6)Tt=∑i=1Ntggid&SYNi+tbgid&SYNi+∑i=1k¯tgSeli+tbSeli+∑i=1Nathi,where k¯ is the number of nodes participating in leader election of the whole network, and the leaders’ election time is Te=∑i=1k¯tgSelpro&deci+tbSelpro&deci. Also, the consensus process is participated by leaders of all groups and the consensus formation time can be calculated as Tv=∑i=1Nathi. Furthermore, we can see that the time complexity of Algorithm 3 is related to the execution frequency of lines 10–13. Then, we assume that the number of nodes in groups is num1,num2,…,numNa and ∑i=1Nanumi=N. Hence, the execution frequency of lines 10–13 is Fn=4∗∑i=1Nanumi=4∗N. Thus, the time complexity of Algorithm 3 is ON. Note that if Na=N, our group-based PoW consensus is equivalent to the traditional PoW method.Algorithm 3: Group-based PoW consensus.
Input: Nodes=nd1,nd2,…,ndn represents all nodes,Na is the number of groups.(1)
nd1,nd2,…,ndn⟶Nodes, groups, Na;(2)
forndi∈Nodesdo(3)
ndi.generateRandom⟶randomNum;(4)
gidi=randomNum⊕Pubki⊕Tsi%Na;(5)
ndi.broadcastNetworkgidi,Nodes;(6)
ndi.obtainGroup⟶groups,groupTableg1,…,gn;(7)
end for(8)
forgi∈groupsdo(9)
forndj∈gidoΔLeader Selection(10)
waittoStableΔtw;(11)
Selproposal=ndj.genProposal;(12)
ndj.broadcastSelproposal,groupTablegi;(13)
waitPropagationΔtp;(14)
end for(15)
li=getLeaderSelproposal1,…,Selproposaln;(16)
Seldeclaration=li.genDeclaration;(17)
li.broadcastTogroupsSeldeclaration,gi;(18)
leaders.addli;(19)
freeSelproposal1,…,Selproposaln;(20)
end for(21)
forli∈leadersdo(22)
executePoWprotocol⟶miner;(23)
end for(24)
miner.generateBlock;(25)
miner.notify;(26)
freegroups;


## 6. Security Analysis

In this section, we analyze the security requirements of Logisticschain based on the design goals in Section3.


### 6.1. Data Security

Logistics requests and sensing data from IoT devices usually contain sensitive information that need to be inaccessible to illegal adversaries. As forUserchain, only authorized users could access the Userchain. The published logistics requests are encrypted with the transaction key transkeyi, which is published by the request owner. Only the authorized logistics providers in Txauthorized could get transkeyi. Therefore, when transkeyi is not compromised, adversaries cannot get encrypted Txauthorized.Similarly,Datachain only contains the hash HEIoTi of encrypted logistics data, and adversaries can only get CTsDatai=Enctranskeyi,sDatai from the IPFS storage system. The sensing data should first be signed with Keyioti by IoT devices and then encrypted with transkeyi in Data chain nodes. Therefore, if transkeyi is not compromised, adversaries cannot obtain any detail information about the logistics data. Overall, our scheme achieves to provide conditional security of logistics data.


### 6.2. Entity Authentication

We assume that an external adversaryUa attempts to impersonate a legitimate entity Ui. In general, each entity in our scheme should register its information, and the system will authenticate any operation of Ui with its valid certificate. However, Ua does not register basic information in IPFS without a unique certificate issued by TA. Therefore, if the certificate of Ui is not compromised, the adversary Ua cannot get any valid information by impersonating a legitimate Ui. Since each legitimate entity Ui has its unique certificate Certi issued by TA, it is almost impossible for malicious nodes to pretend multiple identities illegitimately by forging certificates.


### 6.3. Security Analysis of Group-Based PoW

In theGroup Partition and Leader Selection stages, all the messages exchanged by legal nodes needs to be signed with the hash value of its unique certificate Certi. Then, each node performs signature verification on the received messages and invokes the method Verify. to verify the hash value of certificate. Therefore, we can effectively prevent the spread of fake messages from damaging the consensus process in this way.Considering such a scenario that a malicious node in the blockchain modifies the data stored in a block on its node, the malicious node links the modified block to form a chain by competing for new blocks. Hence, there are two versions of blockchain, namely, the honest chain and the modified chain. Therefore, if the malicious node attempts to tamper successfully, it must make the modified chain become the longest chain. Assuming that the length between the modified chain and the honest chain differs byz blocks, the modified chain becomes the longer chain and succeeded in making up for the distance gap. The possibility of this process can be approximately considered as Gambler’s Ruin problem [30] and can be calculated as equation (7).z = block distance between the honest chain and the modified chain.p = probability the honest chain gets the next new block.q = probability the modified chain gets the next new block.p and q represent the probability of mutually exclusive events and p+q=1.qz = probability the modified chain catches up from z blocks behind.(7)qz=1,p<=q,qpz,p>q.Assuming that the blockchain generates a new block per the average expected time, the extended length of the modified chain will be a Poisson distribution. Then, the probability can be calculated as(8)pa=∑k=0∞λke−λk!∗qpz−k,k<=z,1,k>z.We use matlab to simulate the above process based on equation (8), and the results are shown in Figure 4. We can see that when q = 0.5 or more, it is possible to control all the data of the entire blockchain and break through the consensus algorithm.Figure 4
Data tampering success probability.As for our proposed group-based PoW, a nodeni needs to become the leader of its group to participate in the competition for block packaging. We assume that the current network has N nodes, which are divided into Na groups. Since the group leader is elected by random proposals, the probability of node ni being selected is Na/N. Then, the probability of the modified chain gets the next new block can be defined as qg=Na/N∗q, where q is used in equation (8) to indicate the ability of a node to acquire blocks in a pure PoW competitive environment. According to the above analysis, to achieve data tampering, qg of the malicious node should be bigger than 0.5. According to the definition of qg, it is impossible to realize data tampering by improving the computing power, especially in a large-scale network.


## 6.1. Data Security

Logistics requests and sensing data from IoT devices usually contain sensitive information that need to be inaccessible to illegal adversaries. As forUserchain, only authorized users could access the Userchain. The published logistics requests are encrypted with the transaction key transkeyi, which is published by the request owner. Only the authorized logistics providers in Txauthorized could get transkeyi. Therefore, when transkeyi is not compromised, adversaries cannot get encrypted Txauthorized.Similarly,Datachain only contains the hash HEIoTi of encrypted logistics data, and adversaries can only get CTsDatai=Enctranskeyi,sDatai from the IPFS storage system. The sensing data should first be signed with Keyioti by IoT devices and then encrypted with transkeyi in Data chain nodes. Therefore, if transkeyi is not compromised, adversaries cannot obtain any detail information about the logistics data. Overall, our scheme achieves to provide conditional security of logistics data.


## 6.2. Entity Authentication

We assume that an external adversaryUa attempts to impersonate a legitimate entity Ui. In general, each entity in our scheme should register its information, and the system will authenticate any operation of Ui with its valid certificate. However, Ua does not register basic information in IPFS without a unique certificate issued by TA. Therefore, if the certificate of Ui is not compromised, the adversary Ua cannot get any valid information by impersonating a legitimate Ui. Since each legitimate entity Ui has its unique certificate Certi issued by TA, it is almost impossible for malicious nodes to pretend multiple identities illegitimately by forging certificates.


## 6.3. Security Analysis of Group-Based PoW

In theGroup Partition and Leader Selection stages, all the messages exchanged by legal nodes needs to be signed with the hash value of its unique certificate Certi. Then, each node performs signature verification on the received messages and invokes the method Verify. to verify the hash value of certificate. Therefore, we can effectively prevent the spread of fake messages from damaging the consensus process in this way.Considering such a scenario that a malicious node in the blockchain modifies the data stored in a block on its node, the malicious node links the modified block to form a chain by competing for new blocks. Hence, there are two versions of blockchain, namely, the honest chain and the modified chain. Therefore, if the malicious node attempts to tamper successfully, it must make the modified chain become the longest chain. Assuming that the length between the modified chain and the honest chain differs byz blocks, the modified chain becomes the longer chain and succeeded in making up for the distance gap. The possibility of this process can be approximately considered as Gambler’s Ruin problem [30] and can be calculated as equation (7).z = block distance between the honest chain and the modified chain.p = probability the honest chain gets the next new block.q = probability the modified chain gets the next new block.p and q represent the probability of mutually exclusive events and p+q=1.qz = probability the modified chain catches up from z blocks behind.(7)qz=1,p<=q,qpz,p>q.Assuming that the blockchain generates a new block per the average expected time, the extended length of the modified chain will be a Poisson distribution. Then, the probability can be calculated as(8)pa=∑k=0∞λke−λk!∗qpz−k,k<=z,1,k>z.We use matlab to simulate the above process based on equation (8), and the results are shown in Figure 4. We can see that when q = 0.5 or more, it is possible to control all the data of the entire blockchain and break through the consensus algorithm.Figure 4
Data tampering success probability.As for our proposed group-based PoW, a nodeni needs to become the leader of its group to participate in the competition for block packaging. We assume that the current network has N nodes, which are divided into Na groups. Since the group leader is elected by random proposals, the probability of node ni being selected is Na/N. Then, the probability of the modified chain gets the next new block can be defined as qg=Na/N∗q, where q is used in equation (8) to indicate the ability of a node to acquire blocks in a pure PoW competitive environment. According to the above analysis, to achieve data tampering, qg of the malicious node should be bigger than 0.5. According to the definition of qg, it is impossible to realize data tampering by improving the computing power, especially in a large-scale network.


## 7. Performance Evaluation

To validate the effectiveness and feasibility of Logisticschain, we have carried out a series of experiments. In this section, we first introduce the experimental environment and the capacity of Ublock and Dblock. Then, we analyze the generation time of transactions and compare the efficiency of our scheme with that of other schemes. Finally, we evaluate the performance of the group-based PoW and compare it with well-known consensus protocols.


### 7.1. Experimental Environment and Block Capacity

A trial system of Logisticschain has been implemented to evaluate its efficiency and effectiveness. To implement the trial system, we simulate users and logistics providers with smart phones, and a desktop computer (Lenovo ThinkCentre M720) is used to run theTA procedure. Besides, we use ten desktop computers to run our proposed blockchain and the IPFS (v0.4.14) system.We use the defined structures ofUblock and Dblock as mentioned in Section 3. The length of ParentHash and Ind are both set as 64 bytes; TxHash and Root are both with the length of 40 bytes; Num and Ts are set as 4 bytes. The length settings of block header are shown in Table 3. We choose 1024 bits RSA and 160 bits ECC for asymmetric encryption and signature, 256 bit AES for symmetric encryption, and SHA-256 for hash computing.Table 3
Setting of the block header.
ParametersParentHashIndTxHashRootNumTsLength (bytes)6464404044Based on the above cryptographic settings, we can calculate that the size ofTxlogistics in equation (2) is about 528 Bytes and the size of Txauthorized and Txdata are 328 Bytes and 292 Bytes, respectively. Hence, we can conclude that Ublock of 1M Bytes could contain about 1985 Txlogistics or 3196 Txauthorized and Dblock of 1M Bytes contains 3590 Txdata. Assuming the generation time of Ublock and Dblock is set to 1 minute, the throughput can reach about 33 Txlogistics per second or 53 Txauthorized per second, and as for the Dblock, the throughput can reach about 59 Txdata.


### 7.2. Performance of Logisticschain

For the evaluation of computational overhead, we implement a trial system based on the proposed scheme, which includesUserchain, Datachain, and IPFS system. Our evaluation test is based on the Apache JMeter 5.2. We simulated 500, 1000, and 1500 logistics requests, respectively, to Userchain and the same number of transaction requests to Datachain. Then, we set the number of test threads as 50, 100, and 150, and for each thread, set the loop count as 10. Furthermore, we compare the computational costs of the proposed scheme with that of [23, 28]. The results are shown in Figure 5, from which we can see that our scheme performs better than the other two schemes. To deploy the blockchain platform, we use ten desktop computers where the system configuration is Ubuntu 16.04 (64 bits) with an Intel(R) Core(TM) i7-6700 CPU 3.40 GHZ and 3 GB RAM to construct a network with 20 virtual nodes. As for Userchain, the computational cost of our scheme is at a low level and remains stable. For instance, when the number of requests reaches 800, the average run time of each transaction request is 13.56 ms, while the methods in [23, 28] are about 17.4 ms and 26.1 ms, respectively. The throughput of Datachain is slightly higher than that of Userchain, since Datachain only contains the hash value of sensing data and the storage overhead of sensing data in the IPFS is not included. Compared with the schemes used in this experiment, our Logisticschain reduces the processing time of logistics data due to the customized transaction structure.Figure 5
Comparision of computational overhead.Furthermore, we evaluate the off-chain performance including users’ registration, logistics request/response generation, and IPFS storage. In Table4, experimental results show that the computation incurs a few milliseconds.Table 4
Off-chain overhead.
OperationsInvolved entitiesTime (ms)Users registrationUser/Providers521RES/REQ generationUserchain678IPFS storageUserchain/Datachain439SHA-256 signingUserchain/Datachain125AES encryptionUserchain/Datachain207To evaluate the efficiency of the audit mechanism, which is used to avoid logistics disputes, we conduct a performance test that simulated audit requests from 100 to 1000 (including valid transactions and some tampered transactions), and the results are shown in Figure6.Figure 6
Runtime of audit requests.As illuminated in Figure6, with the same network size, the computational cost increases as audit requests increase. The highest TPS is over 200, and the auditing consumption remains stable. Besides, the throughput of audit requests is affected by the network size. We can observe that the throughput of the network of 20 node is higher than that of the network of 40 node about 21.2%. The throughput decreases with the network size increase, but does not follow a linear relationship.


### 7.3. Performance of Group-Based PoW Consensus

In our scheme, the proposed group-based PoW consensus takes into consideration of the limited computing resources. To evaluate the performance of our group-based PoW, we have designed and implemented a comparison test with traditional PoW and PoS consensus protocols. In this test, we use multithreading technology to simulate member nodes. In fact, the number of node groupsNa has a certain influence on the efficiency of group-based PoW consensus. Here, we simulate user nodes with 100 threads and set the difficulty of PoW to 4 (i.e., the computational target is Hashheader≤MAX/difficulty) so as to evaluate the impact of Na on consensus efficiency.As shown in Table5, Na has a significant impact on the efficiency of the group-based PoW. When Na=7, the runtime reaches a lower level of 59 ms. Obviously, if the value of Na is too small or too large, the consensus efficiency decreases significantly (e.g., when Na is 2 and 5, the runtime is 99 ms and 121 ms, respectively). Therefore, we should adopt an appropriate value of Na according to the size of network.Table 5
Runtime with differentNa.
Na2345678Runtime (ms)9996761211105981To further evaluate the performance of our group-based PoW, under the same hardware and software (go1.13.4) experimental environment. We compare the computational overhead of our group-based PoW with that of the traditional PoW and PoS, respectively. From the results in Figure7, it can be clearly seen that our group-based PoW performs better than traditional PoW consensus [25] and PoS consensus [29]. Specifically, we have simulated a network of nodes from 10 to 300, the average consensus time of our group-based PoW is still less than 67 ms. Meanwhile, the average consensus time of traditional PoW is about 84 ms, which is about 19% higher than that of the group-based PoW. In fact, under the same difficulty setting, our group-based PoW has better performance than the traditional PoW because our proposed consensus can greatly reduce the hash calculations while maintaining decentralization. As for the PoS consensus in this test, we use random number in a given range (e.g., 100–1000) to represent the stake of virtual nodes, and then the nodes compete for block packaging through its own stakes. As shown in Figure 7, the performance of our proposed consensus is similar to that of PoS algorithm, both of which have high computing efficiency. It should be noted that we need to adjust Na according to the size of network to achieve better results.Figure 7
Comparison with other consensuses.Furthermore, to evaluate the resource consumption of the group-based PoW, we have designed and implemented a comparison experiment. This experiment is built on a desktop computer (Lenovo ThinkCentre M720) with Intel Core i7-7500 2.7 GHz processor and 32 GB. We have simulated virtual nodes from 100 to 300 using multithreading technology, and Go language is utilized for implementing algorithms in the experiment. Specifically, we evaluate the resource consumption of algorithms in terms of memory consumption and CPU usage and use VisualVM 1.4.4 as a measurement tool to monitor the memory and CPU usage.As shown in Table6, we can see that our proposed consensus performs better than the other two methods and the memory usage of group-based PoW is less than 2 MB, while for the traditional PoW, the maximum memory usage is more than 15 MB. In terms of the CPU usage, the group-based PoW is significantly lower than the PoW. For our consensus, the highest CPU usage is 4.4% (the number of virtual nodes is 300), which is lower than the lowest value of PoW (when the number of virtual nodes is 100, the CPU usage is 5.7%). Since the group-based PoW only contains a small amount of hash calculations, such as PoS, it is less dependent on CPU computing resources. So, these two methods are relatively close in CPU consumption. Besides, the memory consumption of our proposed consensus is slightly higher than that of traditional PoS; this is because our scheme needs to maintain the group table and other data structures in memory.Table 6
Comparison of resources’ consumption.
ConsensusVirtual nodesMEM (MB)CPU (%)Group-based PoW1000.821.42001.132.13001.324.4PoW in [25]1005.535.72006.9613.430016.219.5PoS in [29]1000.501.72001.142.93001.274.2


## 7.1. Experimental Environment and Block Capacity

A trial system of Logisticschain has been implemented to evaluate its efficiency and effectiveness. To implement the trial system, we simulate users and logistics providers with smart phones, and a desktop computer (Lenovo ThinkCentre M720) is used to run theTA procedure. Besides, we use ten desktop computers to run our proposed blockchain and the IPFS (v0.4.14) system.We use the defined structures ofUblock and Dblock as mentioned in Section 3. The length of ParentHash and Ind are both set as 64 bytes; TxHash and Root are both with the length of 40 bytes; Num and Ts are set as 4 bytes. The length settings of block header are shown in Table 3. We choose 1024 bits RSA and 160 bits ECC for asymmetric encryption and signature, 256 bit AES for symmetric encryption, and SHA-256 for hash computing.Table 3
Setting of the block header.
ParametersParentHashIndTxHashRootNumTsLength (bytes)6464404044Based on the above cryptographic settings, we can calculate that the size ofTxlogistics in equation (2) is about 528 Bytes and the size of Txauthorized and Txdata are 328 Bytes and 292 Bytes, respectively. Hence, we can conclude that Ublock of 1M Bytes could contain about 1985 Txlogistics or 3196 Txauthorized and Dblock of 1M Bytes contains 3590 Txdata. Assuming the generation time of Ublock and Dblock is set to 1 minute, the throughput can reach about 33 Txlogistics per second or 53 Txauthorized per second, and as for the Dblock, the throughput can reach about 59 Txdata.


## 7.2. Performance of Logisticschain

For the evaluation of computational overhead, we implement a trial system based on the proposed scheme, which includesUserchain, Datachain, and IPFS system. Our evaluation test is based on the Apache JMeter 5.2. We simulated 500, 1000, and 1500 logistics requests, respectively, to Userchain and the same number of transaction requests to Datachain. Then, we set the number of test threads as 50, 100, and 150, and for each thread, set the loop count as 10. Furthermore, we compare the computational costs of the proposed scheme with that of [23, 28]. The results are shown in Figure 5, from which we can see that our scheme performs better than the other two schemes. To deploy the blockchain platform, we use ten desktop computers where the system configuration is Ubuntu 16.04 (64 bits) with an Intel(R) Core(TM) i7-6700 CPU 3.40 GHZ and 3 GB RAM to construct a network with 20 virtual nodes. As for Userchain, the computational cost of our scheme is at a low level and remains stable. For instance, when the number of requests reaches 800, the average run time of each transaction request is 13.56 ms, while the methods in [23, 28] are about 17.4 ms and 26.1 ms, respectively. The throughput of Datachain is slightly higher than that of Userchain, since Datachain only contains the hash value of sensing data and the storage overhead of sensing data in the IPFS is not included. Compared with the schemes used in this experiment, our Logisticschain reduces the processing time of logistics data due to the customized transaction structure.Figure 5
Comparision of computational overhead.Furthermore, we evaluate the off-chain performance including users’ registration, logistics request/response generation, and IPFS storage. In Table4, experimental results show that the computation incurs a few milliseconds.Table 4
Off-chain overhead.
OperationsInvolved entitiesTime (ms)Users registrationUser/Providers521RES/REQ generationUserchain678IPFS storageUserchain/Datachain439SHA-256 signingUserchain/Datachain125AES encryptionUserchain/Datachain207To evaluate the efficiency of the audit mechanism, which is used to avoid logistics disputes, we conduct a performance test that simulated audit requests from 100 to 1000 (including valid transactions and some tampered transactions), and the results are shown in Figure6.Figure 6
Runtime of audit requests.As illuminated in Figure6, with the same network size, the computational cost increases as audit requests increase. The highest TPS is over 200, and the auditing consumption remains stable. Besides, the throughput of audit requests is affected by the network size. We can observe that the throughput of the network of 20 node is higher than that of the network of 40 node about 21.2%. The throughput decreases with the network size increase, but does not follow a linear relationship.


## 7.3. Performance of Group-Based PoW Consensus

In our scheme, the proposed group-based PoW consensus takes into consideration of the limited computing resources. To evaluate the performance of our group-based PoW, we have designed and implemented a comparison test with traditional PoW and PoS consensus protocols. In this test, we use multithreading technology to simulate member nodes. In fact, the number of node groupsNa has a certain influence on the efficiency of group-based PoW consensus. Here, we simulate user nodes with 100 threads and set the difficulty of PoW to 4 (i.e., the computational target is Hashheader≤MAX/difficulty) so as to evaluate the impact of Na on consensus efficiency.As shown in Table5, Na has a significant impact on the efficiency of the group-based PoW. When Na=7, the runtime reaches a lower level of 59 ms. Obviously, if the value of Na is too small or too large, the consensus efficiency decreases significantly (e.g., when Na is 2 and 5, the runtime is 99 ms and 121 ms, respectively). Therefore, we should adopt an appropriate value of Na according to the size of network.Table 5
Runtime with differentNa.
Na2345678Runtime (ms)9996761211105981To further evaluate the performance of our group-based PoW, under the same hardware and software (go1.13.4) experimental environment. We compare the computational overhead of our group-based PoW with that of the traditional PoW and PoS, respectively. From the results in Figure7, it can be clearly seen that our group-based PoW performs better than traditional PoW consensus [25] and PoS consensus [29]. Specifically, we have simulated a network of nodes from 10 to 300, the average consensus time of our group-based PoW is still less than 67 ms. Meanwhile, the average consensus time of traditional PoW is about 84 ms, which is about 19% higher than that of the group-based PoW. In fact, under the same difficulty setting, our group-based PoW has better performance than the traditional PoW because our proposed consensus can greatly reduce the hash calculations while maintaining decentralization. As for the PoS consensus in this test, we use random number in a given range (e.g., 100–1000) to represent the stake of virtual nodes, and then the nodes compete for block packaging through its own stakes. As shown in Figure 7, the performance of our proposed consensus is similar to that of PoS algorithm, both of which have high computing efficiency. It should be noted that we need to adjust Na according to the size of network to achieve better results.Figure 7
Comparison with other consensuses.Furthermore, to evaluate the resource consumption of the group-based PoW, we have designed and implemented a comparison experiment. This experiment is built on a desktop computer (Lenovo ThinkCentre M720) with Intel Core i7-7500 2.7 GHz processor and 32 GB. We have simulated virtual nodes from 100 to 300 using multithreading technology, and Go language is utilized for implementing algorithms in the experiment. Specifically, we evaluate the resource consumption of algorithms in terms of memory consumption and CPU usage and use VisualVM 1.4.4 as a measurement tool to monitor the memory and CPU usage.As shown in Table6, we can see that our proposed consensus performs better than the other two methods and the memory usage of group-based PoW is less than 2 MB, while for the traditional PoW, the maximum memory usage is more than 15 MB. In terms of the CPU usage, the group-based PoW is significantly lower than the PoW. For our consensus, the highest CPU usage is 4.4% (the number of virtual nodes is 300), which is lower than the lowest value of PoW (when the number of virtual nodes is 100, the CPU usage is 5.7%). Since the group-based PoW only contains a small amount of hash calculations, such as PoS, it is less dependent on CPU computing resources. So, these two methods are relatively close in CPU consumption. Besides, the memory consumption of our proposed consensus is slightly higher than that of traditional PoS; this is because our scheme needs to maintain the group table and other data structures in memory.Table 6
Comparison of resources’ consumption.
ConsensusVirtual nodesMEM (MB)CPU (%)Group-based PoW1000.821.42001.132.13001.324.4PoW in [25]1005.535.72006.9613.430016.219.5PoS in [29]1000.501.72001.142.93001.274.2


## 8. Conclusion

In this paper, we have proposed and implemented a blockchain-based logistics schemeLogisticschain. To be specific, logistics requests from users are aggregated into Userchain; then, logistics providers could choose logistics orders according to their demands. Furthermore, the logistics data from IoT devices are collected and aggregated into Datachain to ensure that all the stored logistics data cannot be tampered. Also, the group-based PoW is proposed, which can significantly reduce the computational overhead while ensuring the decentralization of the blockchain. Several simulations are carried out to evaluate the performance of our system. Analysis and evaluation show that our proposed scheme is effective and feasible for the storage of logistics data. Further studies are still needed in the future. For example, how to evaluate the reputation of logistics providers participating in Logisticschain is an open issue to be further studied.



---

*Source: 8840399-2021-02-03.xml*