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

With the rapid development of information technology, logistics systems are developing towards intelligence. /e Internet of /ings (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 IoTdevices 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.


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. e Internet of ings (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) e 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) e data mining and analysis procedure is used to mine effective real-time logistics information and design a reasonable transportation scheduling scheme. (3) e application layer could provide detailed information and consulting services for logistics providers and customers [1][2][3][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 selfbuilt data center is time-consuming and expensive), the collected logistics data are likely to be outsourced to cloud servers [4][5][6].
e 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. e 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 cloudassisted scheme. (1) Cloud servers can be considered as centralized third parties with a single-point bottleneck to some extent.
us, 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.
erefore, 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. e 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 named Logisticschain. 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. ese 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 blockchainbased IoT systems. (iii) We implement the proposed Logisticschain and conduct experiments to evaluate the performance of our proposed scheme. e rest of this paper is organized as follows. In Section 2, 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.

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

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. us, 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.

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. is model divides the IoT system into a multilevel decentralized network and uses blockchain technology at all levels of the network. e authors of [24] put forward a blockchaininspired 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.

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. e consumption of resources and time of PoBT is analyzed through a set of experiments. To improve the security of the Industrial Internet of ings (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. ese 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.

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

Basic Security Functions.
ere are several basic algorithms used in our scheme, which are listed as follows: (i) Setup(1 k ): it takes as input a security parameter 1 k and returns the system parameter params, which includes the system keys v and u and a hash function H. (ii) KeyGen(params, 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 As shown in equation (2), the transaction Tx logistics contains the user identity ID U i , timestamp TS i , etc. To specific, the signature S i is signed with the private key Prik i as S i � Sign(Prik i , H(ID U i ‖Content‖Ts i )). Content in equation (2) is the specific information about logistics demands, and this parameter can be a JSON (JavaScript Object Notation) string. Besides, htxI i is the identity of Tx logistics , which can be calculated as Tx logistics is used to publish user logistics demands, which could be obtained by only authorized logistics providers. To authorize logistics providers, the authorization transaction Tx authorized should be utilized: As shown in equation (3), the user identity ID U i is contained in Tx authorized , and the Sig i is signed with the private key Prik i as Sig i � Sign(Prik i , H(ID U i ‖Env i ‖Ts i )). htxA i is the identity of Tx authorized , which can be calculated as htxA i � H(ID U i ‖Env i ‖Sig i � � � �Ts i ). Also, Env i contains the basic information of providers to be authorized, which can be defined as equation (4). Here, ID P 1,2,...,j denotes the identities of providers that need to be authorized and htxI i is the identity of Tx logistics that can be obtained by ID P 1,2,...,j .
Also, transkey i is used to encrypt and decrypt the Content field of Tx logistics .
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., Tx Data ) should be aggregated into Dblock. Tx Data contains the logistics data from IoT devices, which can be defined as Tx data � ID j , htxI j , HEIoT, Sig j , Ts j .
As shown in equation (5), ID j 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 Tx Data . Also, Sig j is the signature of the private key Prik j as Sig j � Sign(Prik j , H(ID j ‖HEIoT‖Ts j )). htxI j is the hash of all the other parts in Tx Data , which can be calculated as Note that htxI j can be used as the identity of Tx Data .

System Model and Design Goals
In this section, we introduce the system model and design goals of our proposed Logisticschain. Figure 1, the proposed Logisticschain mainly includes different components, which can be described as follows:

System Model. As illustrated in
(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 logisticsrelated 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.
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.

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. en, logistics providers should be responsible for the uploaded logistics data. All logistics data should be auditable to ensure disputes' resolution.

The Proposed Scheme
In this section, we describe the proposed scheme in detail.
e key notations used in this paper are listed in Table 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 1 k , which can be described as the following steps: (i) Step 1: big enough prime number q is chosen; then, TA generates three cyclic groups G 1 , G 2 , and G T of the same order q with generator g and bilinear map e:

Entity Registration.
Users and logistics providers should first register their identities and obtain certificates from the system. e detail process can be described as the following steps: (i) Step 1: a user or logistics provider U i sends the identity information Info i to TA through a secure channel as U i ⟶ TA: Info i . (ii) Step 2: TA should encrypt the received Info i as en, TA uploads the encrypted information CT (Info i ) to IPFS and obtains a storage credential HEInfo i , which can be used to retrieve the stored information in IPFS. (iii) Step 3: U i should generate the public and private keys as KeyGen(params, Info i ) ⟶ (Pubk i , Prik i ) and register his/her blockchain account in Userchain or Datachain to obtain the corresponding blockaddress BlockAddr i with the assistance of TA. (iv) Step 4: TA publishes a certificate to U i as TA ⟶ U i :Cert i � HEInfo i , Pubk i , BlockAddr i , Sig TA , Ts i . Once U i has completed the registration in Logisticschain, the authorized Cert i should be stored properly.

Logistics Requesting.
A user U i with the identity ID U i (i.e., HEInfo i ), starting and ending timestamp t 1 and t 2 , and a current location loc i could publish his/her logistics request transactions to Userchain so that logistics providers could obtain the real-time logistics demands. is process can be described as follows: (i) U i collects a batch of items Transitems and extracts the type of Transitems as τ � φ(Transitems). e estimated weight of Transitems is ω and the required latest delivery time is Ts l . Besides, U i should clearly define the source address sAddr and the destination address dAddr. (ii) U i defines the logistics request as REQ U i � ID U i , Env(Transitems, τ, ω, sAddr, dAddr, Ts l ), ⟶ CT (REQ U i ) using the transkey i with the assistance of terminal devices. en, U i should construct a logistics transaction as equation (2) and pack CT (REQ U i ) as the content field. (iv) Finally, U i should publish an authorization transaction Tx Authorized 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 Tx logistics .
In fact, Tx Authorized should be broadcast throughout the Userchain, but only several authorized providers could obtain the transkey i to decrypt the logistics transaction Tx logistics . Overall, the simplified process of publishing logistics transactions can be illustrated in Figure 2.

Logistics Responding.
After receiving a Tx logistics and the authorization transaction Tx authorized , a specific node Unode i in the Userchain should check the validity of Tx logistics by invoking VerifySig(Pubk i , Tx logistics .(S i )). If it holds, Unode i would extract the identities of authorized providers as IdSet � ID 1 , ID 2 , . . . , ID j from the received Tx authorized . After that, Unode i would check its connected providers whether they are in IdSet. If any authorized provider is connected to Unode i , the received Tx authorized and Tx logistics 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 provider P au j who obtains the transaction (i.e., Tx logistics or   Figure 3 shows the process of publishing response from logistics providers.

Data
Uploading from IoT Devices. When a logistics provider P au j accepts a logistics transaction Tx logistcs , the corresponding member nodes (i.e., Datachain node) should authorize the connected IoTdevices (i.e., issuing certificates to these devices). Specifically, IoT devices IotSet � iot 1 , iot 2 , . . . , iot n , 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. us, the storage process can be described as follows: (i) We define sData i � s 1 ′ , s 2 ′ , . . . , s n ′ to represent the sensing data from a specific IoT device iot i , and iot i is connected to the Dnode i (i.e., a Datachain node). Besides, iot i should store the identity of Tx logistics (i.e., htxI i ) so that the sensing data could be associated with the specific logistics request Tx logistics .
(ii) e device iot i sends a data package as dpack i � sData i , htxI i , Ts i to Dnode i through a secure channel. (iii) Dnode i first collects dpack i from iot i and aggregates the sensing data based on the contained htxI i . en, Dnode i verifies the obtained sData i and encrypts sData i with transkey i as E(transkey i , sData i ) ⟶ CT (sData i ) . (iv) Dnode i generates htxI i , CT (sData i ) , Ts, ς i , where ς i in this package is signed by P au j with the private key Prik au j . (v) ς i � Sign(Prik au j , H(htxI i ‖CT (sData i ) ‖Ts)). (vi) e generated package should be sent to the IPFS system through a secure channel; then, the storage hash HEIoT i would be returned from the IPFS system. After that, Dnode i generates a logistics data transaction as Tx data � Pubk au j , htxI j , HEIoT i , Sig j , Ts j }, where Sig j � Sign(Prik au j , H(Pubk au j ‖HEIoT i ‖Ts j )). Finally, the generated transaction Tx data 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 in Userchain 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 � Map〈htxI i ⇒LogisticsRd[ ]〉 is used to store the relationship. Here, htxI i is the identity of In the defined LogisticsRd, TransId sensing is the identity of Tx data , which is generated by Dnode i . IpAddr and BlockAddr denote the IP and the blockchain address of Dnode i , respectively. In addition, Key iot 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.

Data Auditing.
Once there are logistics disputes between users and logistics providers, a reliable audit mechanism could provide a basis for resolving these disputes. erefore, we propose a blockchain-based audit mechanism for logistics data in this study. For instance, a user U i can audit his/her logistics transaction Tx logistics as follows: (i) Step 1: in this process, we should first obtain the transaction id htxI i of the audited Tx logistics ; then, utilize htxI i to retrieve the transaction from the defined mapping variable LogisticsRecordsMap as LogisticsRecordsMap[H(htxI i )] ⟶ LogisticsRds. (ii) Step 2: we can use LogisticsRds. TransId sensing i (i.e., the identity of Tx data ) to obtain the data transaction Tx data , and then acquire the identity (i.e., Tx data . HEIoT i ) of original data from Tx data . (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 obtained Tx data . HEIoT i , 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 Algorithm 2.

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. ese 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.
erefore, 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 � nd 1 , nd 2 , . . . , nd n represents all nodes that compete for the packaging rights at time t. Here,   Table 2. Otherwise, the SYN i would be discarded by nd j . 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 agroup i , nd i ∈ agroup i 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.  (6) for obj logistics in LogisticsRdsdo (7) obj logistics . TransId sensing ⟶ IdTx data ; (8) getTransById(IdTx data , Datachain) ⟶ Tx data ; (9) Tx data . HEIoT i ⟶ storageId (IPFS) ; (10) getFileofIPFS(storageId (IPFS) ) ⟶ retfile; (11) if retfile � � (NULL or FALSE) then (12) return false; (13) end if (14) end for (15)  In fact, other nodes in agroup i should store the received Sel proposal temporarily. us, if any other node nd j has been declared as a leader during Δtp, then nd i will drop its election proposal and marks nd j as the leader of agroup i . Otherwise, the election procedure will execute Step 3. (iii) Step 3. After Δtp, all of nodes (including the node nd i ) in agroup i should aggregate the received selection proposals and choose the node with the largest Sid ∈ Sel proposal as the leader of agroup i . It is clearly that if only nd i puts forward a selection proposal or there are multiple proposals and Sid ∈ Sel proposal of nd i is the largest, then nd i will be marked as the leader. (iv) Step 4. We assume that nd i is the selected leader of agroup i ; then, nd i should generate a selection declaration Sel declaration � Pubk i , is Leader (true), Sig i , Ts i } and broadcast the generated Sel declaration to other nodes in agroup i . After receiving and verifying Sel declaration from nd i , all nodes in agroup i will remove the received selection proposals and mark nd i 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 unique Sid � H(Pubk i � � � �Ts i ) in Sel proposal .
(4) Block Generation.Leaders � ln 1 , ln 2 , . . . , ln n denotes the selected group leaders of the network, and each ln i ∈ Leaders competes for block generation through the PoW protocol [25] (i.e., compare the power of computing by large-scale mathematical calculations).
To specific, ln i ∈ 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.
In practical terms, we assume that there are N nodes in the system and would be divided into N a groups. e total computational time T t is composed of the groups partition time T g , the leaders selection time T e , and the block generation and consensus formation time T v ; then, . To be specific, T g is generally composed of gid i generation and time and SYN i generation and broadcast time; T e is composed of Sel proposal and Sel declaration generation and broadcast time. As for T v , we just consider the computational time of the target hash value. For simplicity, let us denote the entity (e.g., gid i , SYN i , and Sel proposal ) generation time as t g obj , the broadcast time as t b obj , and the hash computing time in PoW as th; then, the block generation time T t can be computed as where k is the number of nodes participating in leader election of the whole network, and the leaders' election time is T e � k i�1 (t i g (Sel (pro&dec) ) + t i b(Sel (pro&dec) ) ). Also, the consensus process is participated by leaders of all groups and the consensus formation time can be calculated as T v � N a i�1 th i . Furthermore, we can see that the time complexity of Algorithm 3 is related to the execution frequency of lines 10-13. en, we assume that the number of nodes in groups is num 1 , num 2 , . . . , num N a and

Security Analysis
In this section, we analyze the security requirements of Logisticschain based on the design goals in Section 3.

Data Security. Logistics requests and sensing data from
IoT devices usually contain sensitive information that need to be inaccessible to illegal adversaries. As for Userchain, e published logistics requests are encrypted with the transaction key transkey i , which is published by the request owner. Only the authorized logistics providers in Tx authorized could get transkey i . erefore, when transkey i is not compromised, adversaries cannot get encrypted Tx authorized .
Similarly, Da tachain only contains the hash HEIoT i of encrypted logistics data, and adversaries can only get CT (sData i ) � Enc(transkey i , sData i ) from the IPFS storage system. e sensing data should first be signed with Key iot i by IoT devices and then encrypted with transkey i in Data chain nodes. erefore, if transkey i is not compromised, adversaries cannot obtain any detail information about the logistics data. Overall, our scheme achieves to provide conditional security of logistics data.

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

Security Analysis of Group-Based PoW.
In the Group Partition and Leader Selection stages, all the messages exchanged by legal nodes needs to be signed with the hash value of its unique certificate Cert i . en, each node performs signature verification on the received messages and invokes the method Verify(.) to verify the hash value of certificate. erefore, 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. erefore, 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 by z blocks, the modified chain becomes the longer chain and succeeded in making up for the distance gap. e 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.
Input: Nodes � nd 1 , nd 2 , . . . , nd n represents all nodes, N a is the number of groups.
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. en, the probability can be calculated as 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.
As for our proposed group-based PoW, a node n i 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 N a groups. Since the group leader is elected by random proposals, the probability of node n i being selected is (N a /N). en, the probability of the modified chain gets the next new block can be defined as q g � (N a /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, q g of the malicious node should be bigger than 0.5. According to the definition of q g , it is impossible to realize data tampering by improving the computing power, especially in a large-scale network.

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. en, 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.

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 inkCentre M720) is used to run the TA procedure. Besides, we use ten desktop computers to run our proposed blockchain and the IPFS (v0.4.14) system.
We use the defined structures of Ublock and Dblock as mentioned in Section 3. e 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. e 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.
Based on the above cryptographic settings, we can calculate that the size of Tx logistics in equation (2)

Performance of Logisticschain.
For the evaluation of computational overhead, we implement a trial system based on the proposed scheme, which includes Userchain, 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. en, 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]. e 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. e 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.
Furthermore, we evaluate the off-chain performance including users' registration, logistics request/response generation, and IPFS storage. In Table 4, experimental results show that the computation incurs a few milliseconds.
To 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 Figure 6.
As illuminated in Figure 6, with the same network size, the computational cost increases as audit requests increase. e 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%. e throughput decreases with the network size increase, but does not follow a linear relationship.

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 groups N a 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 Hash(header) ≤ (MAX/difficulty)) so as to evaluate the impact of N a on consensus efficiency.
As shown in Table 5, N a has a significant impact on the efficiency of the group-based PoW. When N a � 7, the runtime reaches a lower level of 59 ms. Obviously, if the value of N a is too small or too large, the consensus efficiency decreases significantly (e.g., when N a is 2 and 5, the runtime is 99 ms and 121 ms, respectively). erefore, we should adopt an appropriate value of N a according to the size of network.
To further evaluate the performance of our group-based PoW, under the same hardware and software (go1.13.4) experimental environment. We compare the computational     Figure 7, 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 N a according to the size of network to achieve better results. Furthermore, to evaluate the resource consumption of the group-based PoW, we have designed and implemented a comparison experiment.
is experiment is built on a desktop computer (Lenovo inkCentre 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 Table 6, 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 groupbased 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.

Conclusion
In this paper, we have proposed and implemented a blockchain-based logistics scheme Logisticschain. 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.

Data Availability
e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this paper.