Abstract
Blockchain can effectively deal with the security and trust issues in Internet of Things (IoT) due to its salient features including decentralization, immutability, traceability, openness, and transparency. However, most IoT devices have too limited computing, storage, and bandwidth resources to maintain the complete operation of a blockchain system. To this end, we propose a hierarchical blockchain framework called HLOChain for IoT scenarios. First, according to computing and storage capabilities, the IoT devices are classified into three levels, i.e., high, medium, and low. They are deployed on different layers. In this way, a hierarchical blockchain architecture is designed. Second, we propose a lightweight proof of random (PoR) consensus mechanism to provide low-energy block mining, so that even the medium nodes can participate in the consensus task. Third, in order to reduce the ledger storage overhead, we design a blockchain storage optimization strategy based on the account model. Finally, the security analysis demonstrates that our HLOChain is secure against double-spend attack, Sybil attack, and so on. The experimental evaluation shows that our HLOChain achieves better performance in ledger storage cost, consensus computing cost, throughput, and transaction confirmation latency.
1. Introduction
The Internet of Things (IoT) [1] is a network where objects can connect to the Internet through information sensing devices. The objects exchange information and communicate to realize intelligent recognition, tracking, positioning, and so on. At present, the IoT is widely used in smart home, smart city, medical care, logistics, transportation, and other fields to provide users with convenient services, efficient and reliable management control. However, the IoT is a trustless environment. Considering that the mass data generated in IoT are exposed in the network, some security and privacy concerns are rising. In traditional security protocols, network nodes communicate with each other through a centralized entity. This kind of centralized protocol not only increases network delay and interaction times but is also prone to single-point failures. Furthermore, most IoT devices are resource-constrained. Most of the resources of IoT devices [2] are used to perform core functions such as collecting, processing, and transmitting data. They cannot afford the resource consumption of existing security techniques [3]. A low-energy and decentralized approach is needed to realize security and privacy preservation in the IoT.
Blockchain is a new type of distributed ledger technology that combines the P2P network, smart contract, consensus mechanism, and cryptography. Its decentralization feature makes a trust foundation come true under a trustless scenario. It can provide a new idea for solving the security and trust problems existing in the traditional service architecture. As we know, the traditional blockchain relies on computation-intensive consensus algorithms and highly redundant storage to provide transaction security. A typical application field is cryptocurrency [4]. With the development of blockchain, people try to apply the blockchain into financial economy [5], Internet of Things (IoT) [6, 7], supply chain [8], healthcare [9], and other fields. However, there are many resource-constrained devices in these application areas, such as sensors, smart home devices, and so on. They cannot afford the computation-intensive consensus algorithms and highly redundant storage of traditional blockchain.
Edge computing is decentralized and owns rich computation, storage, and communication resources. Thus, it can provide a natural solution to overcome the aforementioned resource-poor situation [10, 11]. Edge nodes with rich computing, storage, and communication capabilities can take on the role of blockchain miners. Integrated edge computing is expected to make blockchain technology widely used in resource-constrained scenarios.
Some related works on the combination of blockchain and edge computing have been carried out so far. Liu et al. [12] proposed a wireless blockchain framework supporting mobile edge computing. In this framework, the computationally intensive block mining work is undertaken by the edge nodes, and the ledger is stored on the edge servers. Chen et al. [13] proposed a collaborative and distributed computing offloading algorithm for the blockchain-driven Industrial Internet of Things (IIoT), where both data processing tasks and mining tasks are taken into consideration. Groupchain [14] is a novel double-chain structure blockchain. It improves the scalability of blockchain and fog computing integration. Lang et al. [15] proposed a blockchain-based data sharing architecture for vehicular edge computing networks. It uses the collaborative computing offloading method to offload some computing and storage tasks to edge nodes. In this way, it enables efficient data sharing between smart vehicles and service providers. Xu et al. [16] proposed a blockchain-based edge computing architecture by integrating edge computing and blockchain into the IoT. It not only realizes secure and scalable IoT transactions but also provides ample data storage space. Guo et al. [17] combined blockchain edge computing and blockchain and proposed a distributed and trusted authentication system. To improve authentication efficiency, the smart contracts are deployed on the edge nodes to provide name resolution and distribute authentication services. In these aforementioned schemes, the resource-constrained devices do not directly participate in consensus but operate as light nodes. The maintenance of the blockchain depends on the edge nodes.
In this study, we also introduce edge computing into deploying the blockchain system. The first motivation is that the edge computing is distributed, which is consistent with the blockchain’s decentralized characteristic. The second motivation is that edge computing can provide abundant computation, storage, and communication resources for maintaining a blockchain system, especially for some resource-constrained IoT scenarios. Nevertheless, combining edge computing and blockchain is not straightforward. It faces the following challenge.
1.1. Challenge
The direct integration of blockchain and edge computing cannot completely solve the problem of resource-constrained devices participating in the blockchain. Those low-resource devices do not always work as light nodes. They also wish to participate in consensus as full nodes and maintain the blockchain. In addition, existing consensus mechanisms, such as PoW, PoS, and PBFT, cannot be directly applied to the IoT. In order to enable resource-constrained devices to participate in consensus, it is necessary to design a more efficient and low-energy consensus mechanism. The conflict between relieving storage pressure and protecting ledger data integrity also urgently needs to be solved.
1.2. Main Contributions
To address the previous challenges, this study proposes a hierarchical blockchain framework with lightweight consensus and optimized storage for resource-constrained scenarios. The main contributions are summarized as follows:(1)We design a novel hierarchical system architecture, in which all the nodes are divided into three levels, i.e., high, mid, and low, according to their capability. With the support of lightweight consensus protocol and data storage optimization, our HLOChain enables mid-level nodes with limited resources to maintain the blockchain such as full nodes.(2)In order to reduce the resource consumption of the consensus mechanism, we propose a lightweight consensus mechanism, Proof of Random. The miner node is selected in a random way rather than relying on computing power or stake. The consensus process only consumes a few resources and is friendly to resource-constrained devices.(3)Facing the problem of ever-increasing ledger data, this study designs an account model-based storage optimization strategy combined with the hierarchical node architecture. The blockchain ledger is divided into a full ledger and a state ledger. In the case of ensuring data integrity and normal operation of the system, resource-constrained nodes can participate in the consensus by only storing the state ledger. It is needed noting that the size of the state ledger is much smaller than the full ledger.(4)The security analysis shows that our HLOChain could resist some common blockchain attacks well (such as double-spend attack, Sybil attack, and so on.). The experimental results show that our HLOChain can achieve better performance in ledger storage cost, consensus computing cost, throughput, and transaction confirmation latency.
1.3. Organization
The rest of this paper is organized as follows: Section 2 reviews the related work. Our system architecture is introduced in Section 3. Sections 4 and 5 present our HLOChain design in detail. Section 6 analyzes the security, and Section 7 experimentally evaluates the performance. Finally, Section 8 concludes this paper.
2. Related Works
2.1. Consensus Mechanism Optimization
The computing resource consumption of the blockchain is caused mainly by the consensus mechanism. Resource-constrained devices cannot afford computing-intensive consensus mechanisms. Therefore, optimizing the consensus mechanism is an important way to achieve lightweight computing. Some scholars have improved the consensus mechanism. Li et al. [18] proposed an improved PBFT blockchain consensus mechanism for federated blockchain. In this work, the strategy of reward and punishment is utilized, and the primary node is selected by voting. It reduces the communication complexity of PBFT. Puthal et al. [19] designed a consensus protocol, proof-of-authentication, to replace the PoW consensus. It can greatly reduce computing consumption in the consensus process. However, its application scope is limited to the permissioned blockchain.
In PoEWAL [20] (Proof of Elapsed Work and Luck) consensus protocol, each miner has a fixed period to solve a cryptographic puzzle similar to PoW. This mechanism relies on the amount of work carried out by nodes within a preset period. It can reduce the computational consumption in each block iteration by adjusting the period to calculate the cryptographic puzzle. Huang et al. [21] proposed a trust-based PoW mechanism to reduce the computing power consumption of honest nodes. This mechanism introduced the node credit value which is related to the behavior of the node. The credit value of nodes will be reduced if they perform malicious behavior. The higher the credit value of a node, the lower its mining difficulty. Saad et al. [22] introduced an extended PoS protocol e-PoS, where the nodes compete to propose a new block through auction. This process does not need to run complex cryptographic algorithms. In addition, each node has the same initial auction funds to ensure a fairer competition.
Khan et al. [23] proposed a lightweight authenticated encryption-based proof-of-authentication consensus mechanism. It utilizes a lightweight hash function and a hardware sharing architecture to reduce the overhead of computing resources. Microchain [24] randomly selected some nodes to form a committee according to the stake of the node. The committee members compute the cryptographic puzzles related to their credit value to compete to propose a new block. Dorri et al. [25] exploited the overlay network to organize nodes in the form of clusters. The nodes with rich resources are selected as cluster heads. The cluster heads reach a consensus through a lightweight time-based distributed algorithm. Kara et al. [26] proposed a Proof of Chance (PoCh) consensus mechanism. Nodes become candidates by chance and randomly select a miner from the candidates. Consensus relies on the chance value of nodes rather than computing power. However, there are only a small number of candidates in each block iteration. It is vulnerable to malicious attacks and reduces the security of the blockchain.
The previous work can reduce the resource consumption of the consensus process to a certain extent, but there are still several problems as follows: (1) The application scenarios are limited. Moreover, some are more suitable for federated blockchain [18, 19]. (2) PoW problem needs to be solved. Consensus relies on computing power and is not applicable to resource-constrained devices [20, 21]. (3) The proposed optimization measures in turn bring additional resource overhead, which will increase the burden on nodes [21, 22]. (4) Resource-constrained devices do not directly participate in consensus, but instead elect resource-rich cluster heads as representatives, which may go against the wishes of some users [20, 25]. (5) There are security loopholes, and the blockchain is vulnerable to security attacks [24, 26]. The PoR consensus proposed in this study reaches consensus in a random form that does not depend on computing power. The whole process consumes very few resources. The resource-constrained devices can also participate directly. Thus, it is suitable for resource-constrained IoT scenarios.
2.2. Blockchain Storage Optimization
Reducing the blockchain data storage to alleviate the storage burden of resource-constrained devices is the key to obtaining lightweight storage. Currently, a number of solutions have been put forth by some scholars. Zhao et al. [27] developed a lightweight enhanced SPV (simplified payment verification) node named ESPV. ESPV nodes store all new blocks and reserve some old blocks according to their storage capability. Furthermore, some projects [28–30] proposed various lightweight clients. These lightweight clients only store a subset of the most recently generated blocks rather than the entire blockchain ledger.
Li et al. [18] proposed an RS erasure code-based storage optimization strategy. Based on the RS erasure code, a new block is encoded into several segments. These code segments are distributed and stored in different nodes. To recover blocks, the nodes request the missing encoded segments from other nodes. However, this method increases the computing and communication overhead of the nodes. Liu et al. [31] proposed a lightweight blockchain system for the industrial IoT. Blocks that do not contain unspent transaction output (UTXO) sets are defined as unrelated blocks. To reduce the consumption of node storage resources, an unrelated block offloading filter is utilized to unload unrelated blocks. Wang et al. [32] proposed an UTXO model-based efficient storage scheme (ESS). To reduce blockchain storage consumption, ESS divides the blocks into three types according to UTXO weight. Then, it utilizes pruning strategies to reduce the size of the blockchain ledger. Ehmke et al. [33] introduced a Proof of Property (PoP) protocol based on the account model. Each transaction includes a proof of property, which proves that the input account of a transaction has enough coins to pay for this transaction. Therefore, the nodes only need the latest block header to verify the transaction. Kim et al. [34] proposed a ledger data compression scheme. By organically combining with the consensus mechanism, the historical block data are compressed to fully improve the utilization of node storage space. Biswas et al. [35] designed a novel type of local transaction to decrease the growth rate of the blockchain ledger. However, this approach is only applicable to a specific framework. In addition, Bitcoin-NG [36] and the works in [37–39] divide the entire blockchain network into smaller committees based on the sharding protocol. Each committee runs the consensus protocol independently and in parallel. Nodes store less ledger data.
To some extent, the previous work can relieve the storage pressure of nodes, but the following issues still exist: (1) lightweight clients allow nodes to store only a small amount of data, but these lightweight clients cannot participate in the consensus process [27–30], (2) unloading and compressing historical blocks lacks protection for the integrity of ledger data [31–35], and (3) the sharding technology is used to deal with the storage problem, but the problem of cross-sharding transaction is generated [36–39]. Under the premise of preserving data integrity, our storage optimization strategy enables those resource-constrained nodes to participate in the consensus by storing only a small amount of data.
3. System Architecture
Our system architecture is shown in Figure 1. Considering the diversity of IoT devices and the different levels of resources they have, we provide three different levels of clients. The high-level client includes the blockchain full ledger. The mid-level client includes the state ledger and a historical block unloading module. The low-level client only includes block header data. When joining the blockchain network, users select appropriate clients according to their own computing and storage resources. Different clients correspond to different node levels. High-level nodes and mid-level nodes participate in consensus, similar to full nodes. Low-level nodes are similar to light nodes, submitting transactions by connecting to high-level nodes or mid-level nodes. The detailed description of each level of node is as follows:(i)High-level nodes (): This layer consists of nodes with rich computational and storage resources, such as servers, high-performance computers, and so on. In our HLOChain, edge nodes are deployed on the high-level nodes layer. They are responsible for block proposal and full ledger storage. It is also our motivation of introducing edge computing into deploying the blockchain system, i.e., utilizing the rich resources provided by edge computing to maintain the operation of a blockchain system.(ii)Mid-level nodes (): This layer consists of some nodes with limited computational and storage resources, such as personal notebooks, smartphones, and tablets. These nodes are unable to run computation-intensive tasks for a long time and store hundreds of gigabytes of data. Our HLOChain optimizes the working mechanism of the consensus and the storage, so that mid-level nodes can participate in the consensus process even if their resources are limited.(iii)Low-level nodes (): This layer consists of nodes that are severely resource-constrained, such as sensors, webcams, and smart home devices. These nodes cannot afford tasks other than normal operations. They propose transactions by connecting to high-level or mid-level nodes, which only need to store the block headers.
In the consensus module, inspired by [20, 26], we design a green and low-energy consumed consensus protocol, Proof of Random (PoR). The node decides whether it can become a candidate node according to the random value. According to a special comparison process, the only miner in consensus iteration is determined from the candidate nodes. The whole process consumes very little resources and is suitable for resource-constrained devices. The protocol is a strongly consistent consensus protocol, and there is no fork problem.
In terms of data storage, we learned from Ethereum’s account model and optimized the block structure. The blockchain ledger is divided into a full ledger and a state ledger. The full ledger stores all data from the genesis block to the current latest block, including all transactions and all account states. The state ledger stores only the blocks containing the latest state tree. Note that the state ledger contains no any transaction data. As we all know, of all data storage, transaction data storage cost accounts for the highest proportion. Therefore, compared with the full ledger, the size of the state ledger is much smaller. The mid-level nodes only need to store the state ledger to participate in the consensus. In addition, the mid-level client also provides historical block unloading service, which is called when the storage space of the mid-level node is insufficient. The high-level nodes are encouraged to store the full ledger by increasing the block reward. They need to provide the proof of storing the full ledger to obtain the corresponding block reward.
Some major notations used in this paper are shown in Table 1. The following will introduce our lightweight consensus protocol PoR and account model-based storage optimization strategy.
4. Proof of Random
Deploying blockchains in resource-constrained IoT scenarios requires avoiding computationally intensive consensus. PBFT consensus will increase the communication burden of IoT devices. PoR is based on the concept of “Random,” meaning that the node must have double luck to get block rewards. Nodes reach consensus through a two-stage random process. The first stage is the candidate test. The node calculates a hash value with the random value and ID, in which . If the hash value meets the given conditions (i.e., ), it becomes a candidate node. The candidate node generates a associated with its ID and broadcasts it to the blockchain. and will be modified at each consensus iteration according to equations (2) and (3), respectively. Proof generation refers to part (1) in Section 4.1. The second stage is to compare the in the of all candidate nodes, and the candidate node with the smallest becomes the miner of the current consensus iteration.
In order to facilitate the verification of candidate nodes, each candidate node includes its public key in the broadcast proof and signs it with its private key. It takes a certain time interval ( in Algorithm 1) before the candidate nodes get s from other candidate nodes. The is based on the present state of the network. The nodes that do not follow the rules will be prevented from taking part in consensus. After , if the number of candidate nodes () is in the range , candidate nodes normally execute the second stage consensus to determine the final miner. Otherwise, the message of consensus failure is broadcast. If the miner has been elected (), all candidate nodes will get a new block generated by the miner after a time interval ( in Algorithm 1).
|
Once receiving a new block, the candidate node updates and and broadcasts the triplet (, , and ). If the block verification fails, the miner node will be reselected. Similarly, the candidate node broadcasts “consensus failure, new Target” if . If a node is not a candidate, it must wait for a new (, , and ) or the message of consensus failure. In order to reduce the probability of consensus failure, only candidate nodes have the right to determine the state of the current consensus. A decision is considered valid only when it is from at least half of the candidate nodes. Algorithm 1 depicts the suggested consensus process.
According to the synchronous consensuses, such as PoW, the system state is updated upon the completion of every consensus round. Nevertheless, there is no clear upper restriction for message delivery in asynchronous consensuses, such as DPoS. To address deadlocks, partially synchronous consensuses, such as PBFT, can use timeouts, preset hierarchies, and additional rules [40]. In our PoR, the nodes cannot forward to the next consensus round until a new block or consensus failure message is broadcast.
4.1. PoR Main Operation Principles
The main steps defined in our PoR are explained as follows:
4.1.1. Generating
The node calculates the hash value by equation (1). If , the node becomes a candidate node and generates a . The generation of is very important here, which needs to ensure uniqueness, unpredictability, and verifiability. The uniqueness guarantees the uniqueness of and ensures that only one miner is generated in the second stage of the consensus. Thus, the fork problem can be avoided. Unpredictability is the guarantee of system security. Verifiability is to ensure the legitimacy of generation and prevent nodes from maliciously forging to skip candidate tests. We give the calculation principle of , which is . is the signature of to the random value , which is unique, unforgeable, and verifiable. In each consensus interation, the values of and will be updated according to equations (2) and (3). Therefore, in each consensus iteration, the is changing and unpredictable. In addition, in order to prevent malicious nodes from forging multiple through multiple public and private keys to increase their probability of passing the candidate test, nodes need to pledge a certain number of tokens when generating .
4.1.2. Update
In equation (2), , , and are the block height, the hash of the previous block, and the number of candidate nodes, respectively. Therefore, the random value is computed by the concatenation of these three parameters. The block height can ensure that each update process is uniquely identified when the other two parameters stay unchanged. The is used because it cannot be manipulated by the miner of the current consensus. The is used in the update procedure to prevent malicious nodes from manipulating their blocks to pass the next candidate test.
4.1.3. Update
After each round of consensus, we use equation (3) to update . If , the value will be reduced after the update. The difficulty of the next round of the consensus candidate test will increase. As a consequence, fewer nodes can pass the candidate test. If , the value will be increased after the update. The difficulty of the next round of the consensus candidate test will decrease. More nodes can pass the candidate test. Thus, remains near , i.e., in the range . If is equal to 0 or 1, then . Here, is dependent on the size and the network throughput, i.e., the propagation of in the P2P network will not cause network congestion.
4.1.4. Miner Select
After , nodes will receive the of all candidate nodes that pass the candidate test. These form a candidate proof list. After that, one of these candidate nodes needs to be selected as a miner node. The specific measure is that the candidate node sorts the hash value in the proof list and selects the with the smallest . If the passes the verification, it is considered that the node that generated the becomes the miner of the current consensus iteration. Because the generated by equation (1) is unique, a unique miner will be determined in this process. The miner will construct a new block and broadcast it to other candidate nodes for verification.
4.1.5. Verification
This process includes verification, block verification, and transaction verification. The verification work is the responsibility of the candidate node. Because our HLOChain is based on the account model, transaction verification mainly depends on the account state of the node. For verification, first verify the legitimacy of the signature according to the node public key, then verify whether the generation is legal according to the signature, and finally verify the legitimacy of the hash value according to the and . The verification of the block includes the following point:(1)To verify the of the miner node, the candidate node is compared with the selected in the second stage of consensus with the contained in the block. The signature is verified with the public key in the .(2)If the miner is a high-level node, it needs to include a digest of the full ledger in the block to prove that it has stored the full ledger. The verification of the digest depends on the high-level nodes. Therefore, the mid-level nodes among the candidate nodes need to randomly send requests for verification digest to 10 high-level nodes. When more than half of the verification success messages are received, the digest is considered to be legal.(3)All transactions are verified and executed according to the account state. If any transaction is illegal, the block will not pass the verification.
After the candidate node is successfully verified, the ledger is updated and the new block is broadcast to the noncandidate nodes. If the verification fails, a consensus failure message will be broadcast.
4.2. PoR Additional Rules
A fork means that there are multiple different versions of the blockchain simultaneously. It seriously affects the scalability of the blockchain. To reduce the probability of forks, we make the following additional rules:(1)The candidate node is required to wait before selecting the miner. The depends on the network conditions. It is guaranteed that the of all candidate nodes can be spread throughout the network during this period.(2)The noncandidate node of each consensus iteration must wait until a new block or a consensus failure message is received(3)Each candidate node is required to forward the received data to all candidate nodes(4)Each noncandidate node is required to forward the received data to 10 randomly nodes(5)If a new candidate node for the previous block consensus iteration (i.e., block ) appears in the block consensus iteration, and the block ’s mining work must be aborted. Nodes must reselect the miner based on the proof list of this candidate node.(6)If a new candidate node for the block consensus iteration appears in the block consensus iteration, this new candidate node should be disregarded(7)If there are two candidate proof lists and , where , only the is taken into consideration by the network. Otherwise, if and , both and are disregarded. Simultaneously, consensus failure message is broadcasted.
5. Storage Optimization Strategy
We optimize data storage based on the Ethereum account model. Each node has a unique account, and the verification of its transactions mainly depends on the account state of the node. The structure of the state tree is a Merkle Patricia Tree (MPT). The leaf nodes store the account states. Once a new block is generated, the states of the accounts involved will change. The corresponding nodes in the state tree will change as well. Note that the change is not made directly in the original nodes. Instead, some new branches are created to store the changed accounts. As shown in Figure 2, we will take the genesis block and block 1 as an example to show the state tree update process. Assume that the block 1 only changes the account 7. Thus, a new branch marked by the blue boxes is created to store the new state of the account 7. Other unchanged nodes directly point to the counterparts in the previous block. In this way, the state tree is updated, and a new MPT is created. So, there is only one latest state tree in the blockchain. To participate in mining and verify transactions, nodes need to keep a full ledger.
In order to solve the storage pressure of resource-constrained devices, so that they can participate in the consensus by only storing a small amount of data, we have optimized the data layer. First, we optimize the block structure, as shown in Figure 3. A complete block includes block header , state body , and transaction body , i.e., . The block header contains some common parameters such as block height , timestamp , hash of the previous block , hash of the root of the state tree , hash of the root of the transaction tree , of miner, role level identifier , and full ledger digest , i.e., . The state body contains a list of accounts whose current state has changed, i.e., . The transaction body is the list of transactions in the current block, i.e., . We separate the account state from the block, and nodes only need to store the block header and state body to participate in the consensus. Therefore, the transaction body can be offloaded when the storage space is insufficient without affecting the normal operation of the blockchain.
In addition, we found that the state of accounts in the blockchain is constantly changing, and the historical state of those accounts has no effect on subsequent transaction verification. Therefore, they can be deleted without affecting the normal operation of the blockchain to save space. Those blocks that do not contain the latest account state are defined as useless blocks. Add a version number flag to the account, which corresponds to the block height of the block storing the current account, i.e., . Therefore, we only need to find the smallest version number of all accounts from the latest state tree, and the historical blocks before the block height corresponding to this version number are all “useless blocks.” So, they can be deleted. Here, we consider all accounts to be active because IoT devices are collecting, processing, and exchanging data all the time. These actions will be recorded in the blockchain in the form of transactions.
Finally, we designed a historical block offloading algorithm for mid-level nodes. As shown in Algorithm 2, our purpose is to delete those useless blocks and transaction bodies. First, obtain the latest account list from the state tree of the latest block and find the minimum version number of the account from the account list. Then, delete those historical blocks whose block height is less than the minimum version number. Finally, delete the transaction body of the remaining blocks. The rest is the state body that only contains the block header and the latest account. We call this part of the data the state ledger.
|
In this study, edge nodes with strong computational power and large storage space are deployed at the high-level nodes layer, which need to store the full ledger to maintain the integrity of blockchain ledger. The mid-level nodes whose storage space is limited just need to store the state ledger to participate in consensus. The state ledger only occupies a small amount of storage space, and it does not strictly increase with the increase of the block height. The new block contains the new state of the account. The historical blocks that store the expired account state will eventually be unloaded. Therefore, as time goes by, the size of the state ledger tends to a stable range, which depends on the total number of accounts in the current blockchain and the average number of accounts stored in each block.
6. Security Analysis
Unpredictability and unmanipulability are significant properties required for a secure consensus protocol. Unpredictability assures that malicious nodes cannot predict the consensus result until it is generated. Unmanipulability ensures that nodes cannot maliciously manipulate and tamper with the consensus result. In our PoR, malicious nodes can neither forecast the outcome of the miner’s selection nor tamper with the outcome by manipulating the consensus process. This is because we use two unpredictable parameters and to calculate . cannot be manipulated because its calculation parameters are public to all nodes. Also, our ID generation is an unpredictable process. The and used by all nodes in the candidate test are the same, and the node that passes the candidate test must generate a to prove its candidate identity. Therefore, a malicious node cannot forge its because each is broadcast in the blockchain network. The malicious nodes cannot tamper with the proof list to fool other candidate nodes when honest nodes are in the majority.
Furthermore, the malicious nodes cannot manipulate the outcomes of miner selection because our selection methods are reasonable and verifiable. If a malicious node violates Rule 1 in Section 4.2, i.e., it does not wait for , but uses a smaller proof list () to recommend itself or its collaborators to become miners, this decision is disregarded because the blockchain network contains a larger proof list (Rule 6 of Section 4.2). Similarly, if a candidate node does not follow the consensus rules to wait for and maliciously broadcasts its new block or the consensus failure message, this decision is also disregarded because the decision must come from half of the candidate nodes to be valid.
6.1. Fault Tolerance
For a blockchain network with n consensus nodes (a collection of high-level nodes and mid-level nodes), our HLOChain can tolerate Byzantine nodes, where .
Since all nodes use the same and , they have the same probability of passing the candidate test. Assuming that Byzantine nodes account for 50% of the current system, in the worst case, there are nodes that pass the candidate test, among which there are Byzantine candidate nodes. These Byzantine candidate nodes will form a candidate list with the lowest number of candidate nodes to successfully launch an attack. As a result, if Byzantine nodes do not surpass 50%, i.e., , then all nodes can ensure fault tolerance.
6.2. Attack Resistance
In this section, we evaluate PoR’s resistance against some common attacks, including double-spending attack, 51% computing power attack, and Sybil attack.(1)Double-spending attacks: In this attack, the attacker attempts to spend the same coin in different transactions. The attack relies on the fork of the blockchain and the transaction delay confirmation mechanism. The collusion of more than 50% of nodes can cause forks. However, the fork is prevented through the additional rules in which we restrict this phenomenon of forks through additional rules in Section 4.2. Therefore, within our fault tolerance range, malicious nodes cannot launch double-spending attacks through forks.(2)51% computing power attacks: In a 51% computing power attack, the attacker who owns more than 51% computing power of the entire blockchain network is able to become a miner at a high advantage. Then, he can generate a longer blockchain to roll back historical transactions. Nevertheless, in our proposed PoR, the miners are generated randomly, instead of depending on the computing power of nodes. Thus, even if malicious nodes occupy 51% of the computing power, they cannot launch attacks through forks.(3)Sybil attacks: In the Sybil attack, the attacker forges a large number of false identities to participate in the blockchain to interfere with the normal operation of the blockchain system. Assume an attacker generates a large number of , which exceed 50% of the total number of nodes in the blockchain. The probability that the attacker becomes a miner is greatly increased. It will seriously affect the fairness of miner selection. Therefore, we increase the cost of becoming a candidate node by pledging tokens in the process of generating , so as to resist Sybil attacks.
7. Performance Evaluation
To evaluate the performance of the proposed solution, a concept-proof prototype of HLOChain is implemented in Java. The performance metrics include consensus time, transaction throughput, transaction confirmation latency, and ledger storage. Consensus time refers to the time that it takes to reach consensus on a given number of transactions. Transaction throughput refers to the number of transactions per second which are packed into the blockchain. Transaction confirmation latency refers to the time from when a transaction is proposed to when it is deposited on the ledger. The ledger storage indicates the size of the ledger data required to be stored by different type nodes at a given number of blocks.
We developed a private blockchain environment based on a virtual machine cluster built over several laptops and local servers. 4 laptops and 2 servers make up the hardware environment. We simulate different types of nodes by assigning different CPU cores and hard disk space to virtual machines. Among them, the configuration of the server is Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20 GHz, and the configuration of the laptop is Intel(R) Core (TM) CPU i5-12500H @ 2.50 GHz.
7.1. Consensus Time
In the experiment, we deployed 50 nodes. The block size is 1 MB, and each block contains 3000 transactions on average. The changes in the consensus time of PoW, PoS, PoEWAL, PoCh, and our PoR under different number of transactions are simulated, and Figure 4 shows the data results. It is clear that the consensus time of PoW is much higher than that of other algorithms because nodes need to continuously solve a cryptographic problem to mine new blocks in PoW. As the computing power of nodes increases, the difficulty is also increasing. For example, Bitcoin generates a new block in about 10 minutes on average. PoS uses stake to reduce the difficulty of mining. PoEWAL expects nodes to reach a consensus by partially solving the cryptographic puzzle within a fixed mining time. Their consensus time is much shorter than Pow, but they still need to continuously calculate the cryptographic puzzle. In the consensus process of PoCh and our PoR, there is no need to continuously calculate the cryptographic puzzle. A more energy-saving random method is used to select miner nodes. However, PoCh consumes a lot of time in the process of node interaction. Figure 4 clearly shows that when the number of transactions mined increases, PoR requires minimal consensus time compared to other lightweight algorithms.
7.2. Transaction Throughput
The transaction throughput is affected by two factors: the consensus time and the block size. Different block sizes are used to test the throughput of PoW, PoS, PoEWAL, PoCh, and our PoR. Figure 5 shows the experimental results. We found that with the increase of block size, the throughput increased significantly. This is due to the block size affecting the number of transactions contained in each block. The larger the block size, the higher the number of transactions per block. In addition, different consensus algorithms have different consensus time. It leads to different throughputs. The lower the consensus time, the higher the throughput. Compared to PoW, PoS, PoEWAL, and PoCh, our PoR has the lowest consensus time. As a consequence, the throughput of PoR is the highest. This shows that our HLOChain is more applicable to the IoT scenarios with large-scale transactions.
7.3. Transaction Confirmation Latency
We adjust the number of nodes to test the change of transaction confirmation latency. Figure 6 shows the experimental results. It can be found that with the increase of the number of nodes, the transaction confirmation latency of PoW changes significantly. It is mainly affected by the consensus time and the fork problem. The latency of PoS, PoEWAL, and PoCh is much lower than PoW and slightly higher than our PoR. However, they are still affected by the forking problem. In the case of 50 nodes, PoR only needs an average of 1.06 s for transactions to be confirmed. This is mainly due to the fact that we use additional rules to effectively alleviate the fork problem, and transaction confirmation does not need to wait for 6 blocks.
7.4. Ledger Storage
In the blockchain system, the full nodes need to store full ledger data to participate in the consensus process, while light nodes only need to store block headers and do not participate in consensus. We divide blockchain ledgers into a full ledger and a state ledger. High-level nodes need to store full ledgers, mid-level nodes only need to store state ledgers to participate in consensus, and low-level nodes only need to store block headers.
We compare the size of the full ledger and state ledger under different block heights, different block sizes (that is, the number of transactions contained in each block), and different numbers of accounts. Figure 7 shows the storage difference between the full ledger and the state ledger under different block heights. It is clear that the full ledger increases significantly with the increase of the number of blocks, while the state ledger is less affected by the number of blocks. Moreover, the state ledger is significantly smaller than the full ledger. Figure 8 shows the storage difference between the full ledger and the state ledger under different block sizes. It is clear that the impact of the block size is basically the same as that of the number of blocks. Figure 9 shows the storage difference between the full ledger and the state ledger under different account numbers. In this respect, the growth rate of the full ledger decreases, while the growth rate of the state ledger increases. Therefore, it can be concluded that the state ledger is greatly affected by the number of accounts because the state ledger mainly stores the latest state of all accounts. It can be observed from the previous three figures that the size of the state ledger is significantly smaller than the full ledger, which is friendly for resource-constrained devices.
8. Conclusion
In this study, we proposed a hierarchical blockchain framework with lightweight consensus and optimized storage for IoT scenarios, which aims to solve the problems of high resource consumption and low efficiency of traditional blockchain. We fully considered the resource configuration of various types of devices in the IoT and combined edge computing to build a hierarchical system model. To enable mid-level nodes with limited resources to participate in the consensus, we designed a lightweight consensus protocol which provides lightweight and efficient mining operations and alleviates the computational power consumption of nodes. In addition, in order to reduce the storage pressure of nodes, we designed a storage optimization strategy, so that resource-constrained nodes just store a small amount of data to work like the full node. Finally, security analysis and experiments showed that our HLOChain is safe and feasible.
In the future, we will further study the data sharing problems under the proposed HLOChain for the IoT. Considering most IoT clients are resource-constrained and may not be trusted, realizing secure data sharing in IoT scenarios is facing the challenges of light weight, efficiency, and privacy preservation. To this end, we will try to utilize the smart contracts in implementing access control, to achieve lightweight, efficient, and secure data sharing for IoT.
Data Availability
All the experimental data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by the National Natural Science Foundation of China (grant nos. 62002139 and 62272203), Natural Science Foundation of Jiangsu Province (grant no. BK20200886), and Project funded by China Postdoctoral Science Foundation (grant no. 2019M651738).