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.
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 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. 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 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.
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.
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): it takes as input a security parameter and returns the system parameter , which includes the system keys and a hash function .(ii): it takes as input a public system parameter and a user identity and then returns the public and private keys of user .(iii): this function is used to generate a fixed-length hash code of message .(iv): this function is used to generate a digital signature of message using user private key .(v): this function is used to verify the validity of the signature . Here, the is signed by the corresponding private key of . Outputs are if the verifications hold or otherwise.(vi): this function takes the system parameter and a specific public key as input parameters to verify the validity of the input certificate .(vii): this function is used to encrypt a plain text by a key and returns the corresponding cipher text . This function is suitable for both symmetric and asymmetric encryption.(viii): this function is used to decrypt a cipher text by a key and returns the corresponding plain text . 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 aswhere is the hash value of parent block and blocks are linked to each other through this parameter, is defined as Merkle Patricia Tries root of transactions, is the hash value of , is the MPT (Merkle Patricia Tries) root formed by accounts, and and are the number and the generated time of Ublock, respectively.
The block body only contains logistics transactions, which are usually published by User nodes, and can be defined as
As shown in equation (2), the transaction contains the user identity , timestamp TSi, etc. To specific, the signature Si is signed with the private key as . in equation (2) is the specific information about logistics demands, and this parameter can be a JSON (JavaScript Object Notation) string. Besides, is the identity of , which can be calculated as .
is used to publish user logistics demands, which could be obtained by only authorized logistics providers. To authorize logistics providers, the authorization transaction should be utilized:
As shown in equation (3), the user identity is contained in , and the is signed with the private key as . is the identity of , which can be calculated as . Also, contains the basic information of providers to be authorized, which can be defined as equation (4). Here, denotes the identities of providers that need to be authorized and is the identity of that can be obtained by . Also, is used to encrypt and decrypt the field of .
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 .
In detail, only one type transaction (i.e., ) should be aggregated into Dblock. contains the logistics data from IoT devices, which can be defined as
As shown in equation (5), is the identity of logistics provider who provides logistics services using IoT devices. To reduce the storage overhead, only the hash (i.e., ) of the encrypted IoT data should be contained in . Also, is the signature of the private key as . is the hash of all the other parts in , which can be calculated as . Note that can be used as the identity of .
4. System Model and Design Goals
In this section, we introduce the system model and design goals of our proposed Logisticschain.
4.1. System Model
As illustrated in Figure 1, 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.
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 Table 1.
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 , which can be described as the following steps:(i)Step 1: big enough prime number is chosen; then, TA generates three cyclic groups , , and of the same order with generator and bilinear map .(ii)Step 2: chooses hash function : .(iii)Step 3: chooses a symmetric encryption function, such as AES, , and an asymmetric encryption function , such as ECC and RSA algorithms.(iv)Step 4: finally, publishes the system parameters as .
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 provider sends the identity information to through a secure channel as .(ii)Step 2: should encrypt the received as . Then, uploads the encrypted information to IPFS and obtains a storage credential , which can be used to retrieve the stored information in IPFS.(iii)Step 3: should generate the public and private keys as (, ) and register his/her blockchain account in Userchain or Datachain to obtain the corresponding blockaddress with the assistance of .(iv)Step 4: publishes a certificate to as :.
Once has completed the registration in Logisticschain, the authorized should be stored properly.
5.3. Logistics Requesting
A user with the identity (i.e., ), starting and ending timestamp and , and a current location 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) collects a batch of items and extracts the type of as . The estimated weight of is and the required latest delivery time is . Besides, should clearly define the source address and the destination address .(ii) defines the logistics request as , where .(iii) is encrypted as using the with the assistance of terminal devices. Then, should construct a logistics transaction as equation (2) and pack as the content field.(iv)Finally, should publish an authorization transaction 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 .
In fact, should be broadcast throughout the Userchain, but only several authorized providers could obtain the to decrypt the logistics transaction . Overall, the simplified process of publishing logistics transactions can be illustrated in Figure 2.
5.4. Logistics Responding
After receiving a and the authorization transaction , a specific node in the should check the validity of by invoking . If it holds, would extract the identities of authorized providers as from the received . After that, would check its connected providers whether they are in . If any authorized provider is connected to , the received and 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 who obtains the transaction (i.e., or ) would check if the transaction has expired by verifying . If has expired, the transaction would be discarded.(ii)Step 2: checks the validity of by verifying . If it holds, could extract transaction keys from as .(iii)Step 3: could obtain the original logistics request as . Moreover, verifies the validity of the received by computing .(iv)Step 4: should generate a response to the received . In detail, we can define as , where in can be calculated as .(v)Step 5: is encrypted as . Thus, we can define the response package as , which should be sent to through terminal devices. In fact, would be packed into a transaction and broadcast throughout the blockchain (i.e., Userchain).
Figure 3 shows the process of publishing response from logistics providers.
5.5. Data Uploading from IoT Devices
When a logistics provider accepts a logistics transaction , the corresponding member nodes (i.e., Datachain node) should authorize the connected IoT devices (i.e., issuing certificates to these devices). Specifically, IoT devices , which may be temperature and humidity sensors, and member nodes are responsible for filtering and summarizing information from 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 . Thus, the storage process can be described as follows:(i)We define to represent the sensing data from a specific IoT device , and is connected to the (i.e., a Datachain node). Besides, should store the identity of (i.e., ) so that the sensing data could be associated with the specific logistics request .(ii)The device sends a data package as to through a secure channel.(iii) first collects from and aggregates the sensing data based on the contained . Then, verifies the obtained and encrypts with as .(iv) generates , where in this package is signed by with the private key .(v).(vi)The generated package should be sent to the IPFS system through a secure channel; then, the storage hash would be returned from the IPFS system. After that, generates a logistics data transaction as , where . Finally, the generated transaction would be published to the .
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 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 is used to store the relationship. Here, is the identity of logistics request transaction, and we can define the LogisticsRd as follows:
Typedefine Struct LogisticsRd {: String, : String, : String, : String, : Address, : Long }.
In the defined LogisticsRd, is the identity of , which is generated by . and denote the IP and the blockchain address of , respectively. In addition, 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.
|
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 user can audit his/her logistics transaction as follows:(i)Step 1: in this process, we should first obtain the transaction id of the audited ; then, utilize to retrieve the transaction from the defined mapping variable as .(ii)Step 2: we can use (i.e., the identity of ) to obtain the data transaction , and then acquire the identity (i.e., ) of original data from .(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 , 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.
|
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 represents all nodes that compete for the packaging rights at time . Here, we attempt to divide these nodes into groups.(2)Group Partition. Each node generates a random number and calculates its group id as Mod. After that, will exchange its group id in the P2P (Peer-to-Peer) network by broadcasting a synchronization message . When a node with the group id receives , it should verify the validity of and check . If it holds, will generate a group item and add into its group table, as shown in Table 2. Otherwise, the would be discarded by . After the group synchronization of has been completed within duration, all of these nodes will eventually obtain its entire group table.(3)Leader Selection. For the autonomous group , 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. could participate in the election of leader after the network is stable. Here, we set a network waiting time (e.g., 5s or 15s) for . If the number of member nodes in does not change during , then is considered to be in a stable state. Furthermore, if no node in is declared as a leader during , then should perform Step 2.(ii)Step 2. generates a selection proposal and sets a propagation time . will be broadcast to other nodes in according to the generated group table. In fact, other nodes in should store the received temporarily. Thus, if any other node has been declared as a leader during , then will drop its election proposal and marks as the leader of . Otherwise, the election procedure will execute Step 3.(iii)Step 3. After , all of nodes (including the node ) in should aggregate the received selection proposals and choose the node with the largest as the leader of . It is clearly that if only puts forward a selection proposal or there are multiple proposals and of is the largest, then will be marked as the leader.(iv)Step 4. We assume that is the selected leader of ; then, should generate a selection declaration and broadcast the generated to other nodes in . After receiving and verifying from , all nodes in will remove the received selection proposals and mark 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 in .(4)Block Generation. denotes the selected group leaders of the network, and each competes for block generation through the PoW protocol [25] (i.e., compare the power of computing by large-scale mathematical calculations). To specific, 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 nodes in the system and would be divided into groups. The total computational time is composed of the groups partition time , the leaders selection time , and the block generation and consensus formation time ; then, . To be specific, is generally composed of generation and time and generation and broadcast time; is composed of and generation and broadcast time. As for , we just consider the computational time of the target hash value. For simplicity, let us denote the entity (e.g., , , and ) generation time as , the broadcast time as , and the hash computing time in PoW as ; then, the block generation time can be computed aswhere is the number of nodes participating in leader election of the whole network, and the leaders’ election time is . Also, the consensus process is participated by leaders of all groups and the consensus formation time can be calculated as . 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 and . Hence, the execution frequency of lines 10–13 is . Thus, the time complexity of Algorithm 3 is . Note that if , our group-based PoW consensus is equivalent to the traditional PoW method.
|
6. Security Analysis
In this section, we analyze the security requirements of Logisticschain based on the design goals in Section 3.
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 for , only authorized users could access the . The published logistics requests are encrypted with the transaction key , which is published by the request owner. Only the authorized logistics providers in could get . Therefore, when is not compromised, adversaries cannot get encrypted .
Similarly, only contains the hash of encrypted logistics data, and adversaries can only get from the IPFS storage system. The sensing data should first be signed with by IoT devices and then encrypted with in Data chain nodes. Therefore, if 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 adversary attempts to impersonate a legitimate entity . In general, each entity in our scheme should register its information, and the system will authenticate any operation of with its valid certificate. However, does not register basic information in IPFS without a unique certificate issued by TA. Therefore, if the certificate of is not compromised, the adversary cannot get any valid information by impersonating a legitimate . Since each legitimate entity has its unique certificate 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 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 . Then, each node performs signature verification on the received messages and invokes the method 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 by 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). = block distance between the honest chain and the modified chain. = probability the honest chain gets the next new block. = probability the modified chain gets the next new block. and represent the probability of mutually exclusive events and . = probability the modified chain catches up from blocks behind.
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
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 needs to become the leader of its group to participate in the competition for block packaging. We assume that the current network has nodes, which are divided into groups. Since the group leader is elected by random proposals, the probability of node being selected is . Then, the probability of the modified chain gets the next new block can be defined as , 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, of the malicious node should be bigger than 0.5. According to the definition of , 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 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. The length of and are both set as 64 bytes; and are both with the length of 40 bytes; and 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.
Based on the above cryptographic settings, we can calculate that the size of in equation (2) is about 528 Bytes and the size of and are 328 Bytes and 292 Bytes, respectively. Hence, we can conclude that Ublock of 1M Bytes could contain about 1985 or 3196 and Dblock of 1M Bytes contains 3590 . Assuming the generation time of Ublock and Dblock is set to 1 minute, the throughput can reach about 33 per second or 53 per second, and as for the Dblock, the throughput can reach about 59 .
7.2. Performance of Logisticschain
For the evaluation of computational overhead, we implement a trial system based on the proposed scheme, which includes , , 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.
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. 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 groups 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 ) so as to evaluate the impact of on consensus efficiency.
As shown in Table 5, has a significant impact on the efficiency of the group-based PoW. When , the runtime reaches a lower level of 59 ms. Obviously, if the value of is too small or too large, the consensus efficiency decreases significantly (e.g., when is 2 and 5, the runtime is 99 ms and 121 ms, respectively). Therefore, we should adopt an appropriate value of 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 overhead of our group-based PoW with that of the traditional PoW and PoS, respectively. From the results in 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 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. 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 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 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.
8. 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
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.