1 Introduction

With the rapid advancement of digital electronics, sensors, and communication technologies, the Internet of Things (IoT) is experiencing rapid growth and has been widely applied in various fields such as commerce, healthcare, and home environments [1,2,3,4,5]. However, as IoT devices become more functional and integrated, they increasingly rely on large distributed systems for information transmission and storage. These systems collect vast amounts of data from various decentralized sources and transmit it to data centers for processing. Although this interconnection of numerous heterogeneous devices and frequent data exchanges brings convenience to IoT applications, it also introduces new security challenges [6, 7]. For example, IoT devices can utilize the peer-to-peer nature of blockchain to ensure the privacy, reliability, and fault tolerance of data exchanges. Every operation involving the creation, modification, or deletion of network data can be registered and verified on the blockchain, enabling detection of tampering and misuse of IoT data. Additionally, blockchain can be used to customize and enforce access policies, achieving control over data access. Moreover, due to the decentralized nature of blockchain, IoT devices can securely store data across different nodes without human intervention.

Blockchain technology, leveraging its decentralized, auditable, and tamper-resistant characteristics, has the potential to bring efficiency, scalability, and security to IoT-based applications [7, 8]. However, introducing blockchain technology into IoT environments is not without challenges, particularly regarding the significant computational and communication overhead involved in consensus protocols, which makes achieving fair consensus in heterogeneous networks a considerable challenge. In practical blockchain networks, nodes running consensus protocols must undertake multiple tasks such as transaction verification, cryptographic computations, and hashing operations, which place demands on the performance of the nodes. In IoT environments with numerous devices, there is often a disparity in device performance, and not all nodes have sufficient capabilities to run consensus protocols. This performance imbalance often leads to network delays, forks, and even more severe security issues. Additionally, in IoT networks with high responsiveness requirements, frequent information exchanges are essential, which further imposes performance demands on the throughput of consensus protocols.

For instance, in smart homes, real-time communication between devices is crucial for responding to emergencies, but the insufficient performance of existing consensus protocols may cause delays and security issues, affecting user safety and comfort. In industrial IoT, real-time monitoring and control of production lines require a high-responsiveness consensus mechanism to ensure the accuracy and timeliness of data. In medical IoT, the real-time synchronization of patient data is critical for quick responses and treatment decisions in emergencies [9,10,11].

In most permissionless environments, the Proof-of-Work (PoW) consensus protocol is widely used. Its advantage is that it provides good security and scalability. PoW typically limits the rate of block creation to give miners enough time to receive and process the previous block. This ensures that most miners build on the same previous block, preventing blockchain forks [12, 13]. However, this also results in the low throughput of PoW in actual deployments, such as in classic Ethereum and Bitcoin, making it unsuitable for IoT environments where device performance is limited and real-time data is highly required. Additionally, existing Proof-of-Stake (PoS) consensus eliminates the process of computing hashes and selects nodes for block production based on asset holdings, but it is susceptible to manipulation by malicious nodes holding the majority of assets, compromising security [14]. Byzantine Fault Tolerance (BFT) consensus allows up to one-third of the nodes in the network to be malicious while still maintaining secure communication. However, the drawback of BFT consensus is that it is only efficient in small node clusters; in networks with many nodes, communication overhead increases sharply, prolonging the consensus process and making normal network communication difficult [15]. Existing consensus protocols have significant limitations in IoT environments, leading to performance bottlenecks and security risks in practical applications. Therefore, it is crucial to research a high-responsiveness consensus protocol suitable for performance-heterogeneous IoT environments, which can enhance system performance and security, thereby promoting the widespread application of IoT technology in various scenarios.

The goal of this paper is to design and implement a new consensus protocol that effectively addresses the limitations of existing consensus protocols in IoT environments, providing high responsiveness and security. The main contributions are as follows:

  • A node partition strategy that comprehensively considers multiple parameters, categorizing nodes into different working nodes, enabling devices with varying performance to participate in network consensus, thereby optimizing the network structure.

  • An improved Ghost-Weight fork block adaptation mechanism based on the Ghost protocol, which can accommodate forked blocks generated in the network, effectively addressing the issues of forks, resource waste, and security problems in IoT blockchain environments.

  • Experimental evaluation of the scheme’s performance, showing that the proposed solution achieves better efficiency and security in heterogeneous IoT environments.

The remainder of this paper is organized as follows: Section 2 reviews related research in the field. Section 3 introduces the system model and detailed information about the consensus protocol. Section 3.2 provides formal proofs of consistency and security of the protocol. Section 4 evaluates the performance of the proposed solution through experiments, and finally, Section 6 summarizes the entire work.

Fig. 1
figure 1

System architecture model diagram. After joining the network, IoT devices are partitioned into different types of nodes through node partitioning. These nodes will then join the consensus process via the Ghost-Weight protocol, where these blocks will be processed

Full size image

2 Related work

In blockchain technology, consensus protocols are considered the core component and key mechanism ensuring the smooth operation of the entire network. Current consensus protocols are mainly divided into two categories: permissioned and permissionless.

Examples of permissionless consensus protocols include the Proof of Work (PoW) used by Bitcoin. PoW consensus protocols are widely used in blockchain environments for mining processes due to their simplicity and security. Rainblock [16] adopted a novel DSM-Tree, which eliminated the I/O bottleneck in transaction processing, thereby improving PoW throughput from the transaction processing layer. However, its changes to the underlying storage structure significantly increase the difficulty of final protocol deployment. OHIE [17] introduced the concept of parallel chains, where one chain is split into multiple chains, running concurrently, greatly enhancing blockchain network performance. However, this also requires nodes to coordinate parallel chains, posing deployment and application challenges. Conflux [18] and Prism [19] optimized the process of blocks being included in the chain by using a graph structure, leading to performance improvements. However, these schemes do not offer compatibility for environments with heterogeneous performance in the Internet of Things (IoT).

These improvements aim to make PoW more competitive and better suited to the needs of blockchain networks. Similar to PoW, the Delegated Proof of Stake (DPOS) process, as used by Ethereum [20], replaces the need for energy-intensive hash computations with staking tokens. However, DPOS may lead to stake concentration issues, making it less suitable for IoT systems as a service (BaaS). On the other hand, Practical Byzantine Fault Tolerance (PBFT) is a protocol deployed in permissioned environments. Although PBFT has achieved significant success in consistency and fault tolerance in asynchronous distributed systems, its complexity and the number of communication messages limit its application in resource-constrained environments like IoT [21].

This paper focuses on efficient consensus protocols deployed in IoT networks with heterogeneous performance. Kariyappa Janani et al. proposed a lightweight consensus protocol: Proof of IoT (PIoT), designed to overcome attacks encountered during data communication. The proposed blockchain system excels in effectively identifying IoT devices, verifying their legitimacy, and dynamically allocating addresses based on demand [22]. Fateme Fathi et al. introduced IBFT, a sharded BFT consensus protocol suitable for IoT environments. It is based on replicas rather than fault tolerance. Initially, nodes are divided into different shards through VRF, and a high-performance team leader shard is considered. Finally, cross-shard transactions are resolved through an improved two-phase commit scheme [23]. E.K. Wang et al. proposed a reputation consensus protocol for IoT systems. The protocol designed two methods to enable the blockchain system to reach consensus quickly and securely. The reputation reward and punishment method settles the reputation value of nodes; nodes with satisfactory behavior will receive reputation rewards. The reputation mining method proposes reputation requirements for consensus nodes; nodes with high reputation values are more likely to produce blocks [24]. For reputation-based consensus protocols, Wu et al. proposed a dynamic incentive reputation consensus mechanism based on a sigmoid function to address scalability challenges in IoT blockchains, prevent node monopolies, promote the integration of new nodes, and enhance fault tolerance [25]. Additionally, researchers have proposed a protocol called Practical Proof of Work (PoUW), which attempts to replace the SHA256 hash calculation in PoW with solving practical problems such as orthogonal vector problems, shortest path problems, etc. [26]. G. Ateniese et al. proposed Proof of Space (PoSp) based on proof of storage space. This scheme is not interested in the number of accesses to the main memory (such as memory-bound proof of work); instead, the prover must use a specified amount of space to calculate the proof. This method has achieved significant results in reducing energy consumption [27]. Othmen introduced a new lightweight IoT blockchain fast consensus algorithm, which improved PBFT and was applied in random clusters with a small number of miners. This will allow multiple consensuses on different clusters to be executed in parallel, reducing the complexity of PBFT [28]. Zhao et al. proposed an Evolutionary Model Proof (PoEM), which iteratively trains machine learning models to reach consensus. In this way, PoEM improves consensus efficiency and allows low-performance IoT devices to participate [29]. Dai et al.’s research introduced the GH-PBFT consensus algorithm, proposing a three-layer system design and achieving consensus through a simplified identity verification and management process, enabling resource-constrained IoT devices to operate as lightweight nodes [30]. Chacko et al. modified the Proof-of-Authority (PoA) consensus mechanism, introducing decentralized PoVA, an improvement to the traditional Proof-of-Authority (PoA) mechanism, making the selection of authoritative nodes dynamic rather than static, adapting to the issue of low-performance IoT devices [31]. Wan et al. proposed a deep reinforcement learning (DRL)-based blockchain IoT resource orchestration scheme, reaching consensus on the allocation of network resources between servers and clients. However, IoT generally lacks AI decision support, and how to effectively use AI to identify important data remains a challenge [32, 33]. Moreover, the implementation of these schemes may lead to IoT data privacy not being guaranteed, posing risks to data security [34, 35]. Table 1 provides a summary and comparison of the consensus algorithm characteristics of the above schemes, highlighting research gaps.

Table 1 Summary and comparison of consensus algorithms
Full size table

The aforementioned work optimizes consensus schemes, but deploying a high-performance consensus protocol under the conditions of numerous and heterogeneous IoT devices remains challenging. Additionally, as network performance improves and IoT device data continue to incrementally submit to the blockchain, avoiding waste of network resources is also an important issue. This proposal addresses these issues with Ghost-Weight, an efficient consensus protocol suitable for heterogeneous performance IoT environments.

3 System model

The system model of our scheme consists of two parts: the Node Partition strategy and the Ghost-Weight forked block processing protocol.

Figure 1 shows the system model of our scheme. IoT devices are partitioned into different nodes and join the blockchain network through the Node Partition strategy. The nodes participate in consensus, generate transactions, and package blocks. Transaction blocks are processed by the Ghost-Weight protocol to complete transactions. The design objectives of our scheme are as follows:

  • Achieving fair consensus in heterogeneous networks. The devices in the network have varying performance capabilities and a wide range of quantities. All devices within this range should be able to join the blockchain network and actively participate in its consensus activities. This not only prevents the domination of high-performance devices but also protects the rights of lower-capacity devices. By enabling all devices, regardless of their performance configurations, to meaningfully participate in the consensus process, the network promotes an inclusive and equitable environment.

  • Scalability and performance optimization. As the network data continuously increase, the demands for scalability and performance optimization vary. This scheme aims to seamlessly adapt to network growth, regardless of its scale. It ensures that the network remains robust and efficient when facing the expansion of new devices and applications.

  • Optimizing node resource utilization. In traditional consensus processes, forked blocks generated during consensus are typically discarded, leading to significant waste of computational power and network resources. Our protocol aims to minimize this inefficiency by incorporating forked blocks into the network whenever possible.

3.1 Node partition

Fig. 2
figure 2

Devices undergo node partitioning

Full size image

At the beginning of the network, IoT devices join the network through Node Partition, as shown in Fig. 2. These devices are classified into two types of nodes within the blockchain network: LPNode (Low-Performance Node) and PNode (Proof-of-Work Node), enabling them to perform different network activities. Pnodes, labeled as PNodes, are at the forefront of the network’s computational power and actively participate in the mining process, earning the majority of the rewards. These nodes have excellent computational capabilities and highly reliable network connections, making them the most competitive participants in the network. They solve mathematical problems in the blockchain by computing complex hash functions, thereby validating and adding new transaction records to the blockchain. In contrast, LPnodes do not participate in the mining process of solving hash functions but can still earn a portion of the rewards through other means. These nodes have relatively weaker computational and read/write capabilities, making it difficult for them to compete with PoW nodes. However, they play a crucial role in the blockchain network by performing tasks such as verifying Merkle trees, maintaining the network ledger structure, and validating transactions. Despite their lower performance evaluations, LP nodes are essential in ensuring the security and stability of the blockchain network. Node Partition is divided into two steps: the Pre-Mining Process and Comparison. The Pre-Mining Process is an initial evaluation process. During this process, nodes must find shares within a specified time, and the final number of shares found serves as an indicator of their computational ability. It is important to note that, unlike the formal mining process, the goal of the Pre-Mining Process is to assess the performance levels of different devices. The difficulty and duration of this process depend on the overall state of the network, ensuring that all nodes can participate in Pre-Mining. The algorithm for the Pre-Mining Process is outlined in Algorithm 1. The shares generated by nodes during the Pre-Mining Process will be used as parameters for the Sigmoid function, ultimately producing the Node Performance metric, which represents the performance of the node.

Algorithm 1
figure a

Pre-Mining Process

Full size image

Nodes that have completed the Pre-Mining Process move on to the Compare phase. During the Compare phase, the Node Performance is compared with the Network Performance. If the Node Performance is lower than the Network Performance, the node is more likely to become an LP (Low-Performance) node; otherwise, it will become a P (Workload) node. Network Performance represents the average performance of the network and measures the average performance of all nodes in the blockchain network. It is determined by assessing the bandwidth, read/write performance, and the total number of shares generated by all nodes during each Epoch.

To understand how Node Partition works within the network, consider the following example: In a given Epoch, an IoT device joins the network and enters the Pre-Mining Process. The node’s performance is calculated using the following formula, as shown in Formula:

Let \(h_n\) denote the number of shares generated by the Pre-Mining process. The Pre-Mining process is defined as:

$$\begin{aligned} h_n = \text {Pre-Mining}(N, T, D) \end{aligned}$$
(1)

where \(T\) represents the execution time, and \(D\) represents the share difficulty. Both \(T\) and \(D\) are network parameters that change in each Epoch.

The network parameter \(T\) represents the duration of the Pre-Mining execution and can be calculated using:

$$\begin{aligned} T = \frac{\sum _{i=1}^{B_{\text {Epoch}}} (\text {blocktimestamp}_i - \text {blocktimestamp}_{i-1})}{B_{\text {Epoch}}} \end{aligned}$$
(2)

where \(\text {blocktimestamp}_i\) is the timestamp of the \(i\)-th block, \(\text {blocktimestamp}_{i-1}\) is the timestamp of the \((i-1)\)-th block, and \(B_{\text {Epoch}}\) is the number of blocks produced in the Epoch.

The network parameter \(D\) represents the difficulty of the Pre-Mining process, specifically the difficulty of obtaining a valid share. It can be calculated using:

$$\begin{aligned} D = \left( \frac{\sum _{i=1}^{B_{\text {Epoch}}} \text {Block difficulty}(i) \times \text {Block nonce}(i)}{B_{\text {Epoch}}} \right) \times F_{\text {factor}} \end{aligned}$$
(3)

where \(\text {Block difficulty}(i)\) is the difficulty of the \(i\)-th block, \(B_{\text {Epoch}}\) is the number of blocks produced in the Epoch, and \(F_{\text {factor}}\) is an adjustment factor that maps the average difficulty in this Epoch to a lower difficulty, determined by the ratio of LP nodes to P nodes.

Node performance can be normalized using the sigmoid function to produce a value in the (0,1) range, calculated as follows:

$$\begin{aligned} P_{\text {node}} = \frac{b_n}{1 + e^{-\frac{b_t}{m}(h_n - h_{\text {network}})}} \end{aligned}$$
(4)

where \(b_n\) and \(b_t\) represent the node’s bandwidth and the average bandwidth of the network, respectively, \(m\) is the total number of network nodes, and \(h_{\text {network}}\) is the average share production of the current network.

After the Pre-Mining Process, the node moves to the Compare phase. Node Performance is compared with Network Performance. If the node’s performance is higher than the network’s average performance, it is more likely to be selected as a PNode; otherwise, it will become an LPNode. This is represented as:

$$\begin{aligned} {\left\{ \begin{array}{ll} P_{\text {node}} \ge P_{\text {network}} & \text {if } \text {node} = \text {LPNode} \\ P_{\text {node}} < P_{\text {network}} & \text {if } \text {node} = \text {PNode} \end{array}\right. } \end{aligned}$$
(5)

3.2 Ghost-Weight protocol

As the amount of device data continuously increases on the blockchain, forks in the network are likely to occur. Due to competition between different branches, network resources may be wasted, leading to network congestion and reduced efficiency. To address this issue, Ethereum has introduced a set of selection rules based on the GHOST (Greedy Heaviest Observed Subtree) protocol. According to these rules, if there are multiple branches, the longest branch is considered the valid blockchain. However, when multiple branches have equal lengths, weight becomes the determining factor. The GHOST protocol allows miners to include uncle blocks in new blocks to improve the network’s processing power and security. Despite its attractiveness in maximizing resource utilization, the GHOST protocol’s fork accommodation mechanism also introduces potential threats and security risks. One threat occurs when the block generation rate significantly exceeds network latency. Malicious nodes might control the weights of two subtrees to maintain balance, leading the network to be unable to determine which chain is more critical, thereby slowing down network transaction speeds and causing damage. Another situation is when a malicious miner discovers a block but keeps it secret and does not immediately reveal it. If an honest miner finds a block on the public branch, the selfish miner pool will publish its private branch, causing competition. In this competition, if the selfish miner pool gains an advantage, it will continue to maintain the private branch and eventually reveal it at an appropriate time to maximize its revenue. Importantly, this behavior typically does not require more than 50% of the computational power. This attack is known as "selfish mining" or "balance attack," and it aims to disrupt the network’s consensus mechanism, causing the network to falter. By appropriately adjusting the weights of subtrees, malicious nodes can maintain multiple balanced chains, obstructing the consistency confirmation process of other honest nodes. This results in increased transaction delays, reduced throughput, and overall decreased system performance.

This proposal introduces a fork accommodation mechanism based on the GHOST protocol. This mechanism aims to maximize resource utilization by allowing the consideration of certain or all blocks on forked chains when confirming blocks on the main chain, ensuring their successful integration into the network ledger.

3.2.1 Dominant block

In this proposal, we first define a special type of block: the Dominant Block. When a Dominant Block is successfully mined, it can organize and publish forked blocks (blocks that do not belong to the heaviest chain) to the entire blockchain network. In other words, the Dominant Block determines which forked blocks are included in the main chain of the blockchain.

At any height in the blockchain network, if a mined block’s block header hash meets the condition specified by the Epoch, that block is considered a Dominant Block. Within an Epoch, only the first block to meet this condition will be selected as the Dominant Block, and there can be at most one Dominant Block per Epoch.

The selection of Dominant Blocks is essentially a competitive process. During each Epoch in the blockchain network, as long as no Dominant Block has yet appeared, any mined block may potentially satisfy the conditions and become the Dominant Block.

This proposal uses a mechanism that selects the branch with the maximum weight as the main chain of the blockchain network. This means that the chain with higher weight will be considered the consensus version on the network. The weight primarily considers the transaction fees included in the blocks; a block that contains more or higher-value transactions will have a higher weight. The release of a Dominant Block involves synchronously publishing several forked blocks to the entire blockchain network. Therefore, it usually contains more transactions and has a higher weight, meaning that the branch containing the Dominant Block is more likely to become the main chain.

Next, we will provide an example of the Dominant Block selection process to better understand how it works.

At the beginning of a new Epoch, whenever a miner successfully mines a block, the hash of the block header will be compared with the identification sequence Seq in the Epoch field to check if its hash contains the sequence specified for that Epoch. If it does, then the block will become a Dominant Block.

As shown in Fig. 3, no Dominant Blocks were generated in Epochs 1 and 2. However, in Epoch 3, Block G satisfies the identification sequence Seq condition for that Epoch, thus becoming the Dominant Block of Epoch 3.

Fig. 3
figure 3

As illustrated in the diagram, no Dominant Block is generated during Epoch 1 and Epoch 2. However, in Epoch 3, Block G meets the Seq condition for that Epoch, thereby becoming the Dominant Block for Epoch 3

Full size image

3.2.2 Fork block accommodation

Once a Dominant Block is successfully mined, it triggers the fork block accommodation mechanism to ensure that forked blocks are processed and included in the network ledger in an orderly manner. Fork block accommodation mainly consists of two parts: initializing the Confinement Edge and the ForkBlock Process.

During the initialization of the Confinement Edge phase, the Dominant Block searches its locally maintained set of forked blocks for blocks that can be connected. If there are blocks in the set, the Dominant Block will establish a CF (Confinement) edge connection with these blocks, indicating that the Dominant Block has accommodated the corresponding forked blocks.

Each forked block can only be connected by a unique CF edge, indicating that it is accommodated by the Dominant Block. Typically, the Dominant Block will prioritize blocks with earlier timestamps or higher transaction fees. To control network performance and resource utilization, we have set a maximum limit on the number of forked blocks a Dominant Block can accommodate, with an upper limit of 7. This means each Dominant Block can accommodate up to 7 forked blocks. Once the Dominant Block reaches this limit, any additional forked blocks will not be accepted. The initialization phase of the Confinement Edge ends when the set of forked blocks is exhausted or when the Dominant Block has no more available slots.

In the ForkBlock Process phase, the Dominant Block organizes the accommodated forked blocks into a sequence of blocks. In this sequence, the blocks are ordered by hash header size. Based on this order, the blocks are chained together to form an ordered linked list. We initially assume that there are no transaction conflicts between these blocks. The Dominant Block and all forked blocks it has accommodated represent a total set of transactions, which are verified locally and conflicting transactions are removed. Finally, the Dominant Block, along with all transactions contained in the forked blocks, will be packaged into a new block and published to the blockchain network as part of the network consensus. If there are no competing Dominant Blocks, this new block will likely become part of the main chain, and the network consensus will continue to extend under this main chain. Figure 4 illustrates the process of fork block accommodation. The Ghost-Weight algorithm is described in Algorithm 2.

Algorithm 2
figure b

Ghost-Weight protocol

Full size image

Under a PoW consensus network environment, we assume that the proportion of honest nodes in the network is greater than 50%. Additionally, network propagation delays are limited, meaning that blocks can be disseminated to most nodes in the network within a finite time. In each Epoch, there is exactly one Dominant Block successfully selected.

Fig. 4
figure 4

Fork block A, B, C, D, E contained by Dominant block E, and F, G contained by Dominant block F

Full size image

4 Security analysis

In this paper, we introduce the Ghost-Weight protocol, which builds upon the Nakamoto and GHOST protocols by incorporating concepts like Node Partition and the Dominant Block, responsible for containing forked blocks. This enhancement aims to better utilize network resources and improve performance in IoT networks with heterogeneous performance and high responsiveness demands. The protocol allows for dynamic adjustment of system throughput based on actual demand during operation, rather than setting a fixed throughput target in advance. This design enables the protocol to flexibly handle the growth and fluctuations in transaction volume within the network, thereby avoiding the scalability–security trade-offs encountered in the Nakamoto consensus. In the following sections, we will detail the formal security proof of the Ghost-Weight protocol, based on our previous descriptions and analyses, providing theoretical support for the protocol’s security.

4.1 Model definition

We first introduce the formal expression of blockchain abstraction [36]. A blockchain is understood as a set of algorithms: \((\Pi , \text {ext})\). Here, \(\Pi\) maintains a local variable called the chain C. C contains blocks consisting of several messages m, which together form the chain itself. The algorithm \(\text {ext}\) is responsible for forming a sequence of messages from blocks. Participants receive these messages as input and attempt to include their own messages in both their own chain and the chains of others.

The formal definition of the blockchain protocol can be abstracted into the following components:

  • Environment: Represented by \(Z(1^k)\), where k represents the security parameter of the network, and Z simulates all external factors during the protocol’s execution. For example, Z activates all participants at the start of the protocol and provides input to the protocol.

  • Honest Participants: Honest players follow the protocol rules set by \((\Pi , C)\). As honest participants, they select the blockchain replica they believe to be correct and attempt to extend this replica to maintain network stability.

  • Adversary: Represented by A, a proportion \(\rho\) of the total participants n are corrupted, and these participants are controlled by the adversary A. Generally, besides not exceeding the protocol’s prescribed behavior, the adversary has the following powers:

    1. 1.

      The adversary can delay and reorder all messages received by players, with a maximum delay of \(\Delta\) rounds.

    2. 2.

      The adversary can control the behavior of each corrupted node. For instance, all corrupted nodes may work on the same block or different blocks.

  • Random Oracle: All participants can access a random function \(H: \{0, 1\}^* \rightarrow \{0, 1\}^\kappa\). H(x) simply outputs H(x), and \(H.\text {ver}(x, y)\) outputs 1 if and only if \(H(x) = y\); otherwise, it outputs 0. In any round r, participants can make an arbitrary number of \(H.\text {ver}\) queries. On the other hand, in each round r, honest players can only query H once, while the adversary A, controlling q participants, can sequentially query H q times. The H function is parameterized by p (the mining difficulty parameter) based on a Proof-of-Work protocol. Simply put, for a block \(h-1\) and message m, the Proof of Work is a string \(\eta\) such that \(H(h-1, \eta , m) < D_p\), where \(D_p\) is set so that the probability of satisfying this relation is less than p.

The protocol execution begins with Z creating n participants, all possessing equal computational power. After starting, the protocol proceeds in rounds. In each round, participants receive messages from Z, which may be transactions to be packaged or blocks. Through the environment Z, participants can communicate with the adversary at any time or access the local state variable C (state\(_i\)) of player i (i.e., the chain of player i). At any given time, Z can corrupt an honest party j, meaning the adversary can control j’s local state and messages, or revoke the corruption of party j, meaning A no longer controls j, and player j executes the protocol \(\Pi (1^\kappa )\) from an empty state.

We simulate the protocol’s execution using the random variable \(\text {EXEC}(\Pi , C)(A, Z, \kappa )\). Let \(\text {view}_r\) denote the execution of \(\text {EXEC}(\Pi , C)(A, Z, \kappa )\) at round r. Let \(C^r_i(\text {view})\) denote the record chain in the local state of player i up to round r in the prefix of \(\text {view}\).

4.2 Security definitions

This protocol does not confirm the main chain based on the longest chain, so it requires a different security definition from that of PoW.

First, we assume that chain growth in this protocol depends on the weight of the chain, i.e., the increase in the weight of blocks on the paths of honest participants is equivalent to the growth in the longest chain model.

Lemma 1

For any \(\delta > 0\), in any chain of an honest participant at time round r, there exists a block b of length l and weight w. At time \(r + T\) (for some T), the expected weight increase of blocks of length l and all blocks it points to is at least \(T (1 - \delta ) / \mu \Delta (c+\mu )\).

Proof

Honest participants will seek the heaviest path P in the chain. Whenever Z announces a new block b, two scenarios occur in the network:

  1. 1.

    b becomes part of the main chain, increasing the weight of path P.

  2. 2.

    A fork occurs at the height of b, and all subtrees of blocks at the current height have the same weight.

  3. 3.

    b is selected as the Dominant Block, gaining more weight to become the main chain, thus increasing the weight of path P.

Within a \(\Delta\) period, at least one honest path’s weight will increase. Using the Markov model and the standard Chernoff–Hoeffding bound, the number of rounds required to increase one weight is at most \(c\Delta /\mu + \Delta\), and the number of rounds to increase the weight by \(\delta\) is at most \((1 + \delta )(c\Delta /\mu + \Delta )\delta\), with a probability of \(1 - e^{-\Omega (\delta )}\). That is, within T rounds, the weight of the main chain increases by at least \((1 - \delta )T/\mu \Delta (c+\mu )\) with a probability of \(1 - e^{\Omega (T)}\). Therefore, the lemma is proven. \(\square\)

Similarly, under the weight-chain model, we define that if an adversary withholds blocks and attempts to launch an attack, the branch recognized by the adversary will not become part of the main chain except with negligible probability.

Lemma 2

There exists a branch C that an adversary is preparing to mine (no honest participants are mining on this branch), but honest participants may not be working on the same block at the same height. Let r be the point where only the adversary is mining on C, and \(r + t\) be the point where an honest player first hears of any block in C after r. Considering a negligible function \(\epsilon (.)\) and a parameter \(\delta \in (0, 1)\), and given \(\mu \ge \delta \rho\), the probability that the adversary’s mined branch becomes the main chain is \(\le \epsilon (t)\).

Proof

At some time \(T \ge r+t\), an honest participant becomes aware that an adversary is mining on a historical position C. If the honest participant is mining on the main chain at position b, by Lemma 1, we know that at the current time T, the weight growth of the main chain is at least \(T/\mu \Delta (c+\mu )\). Moreover, the adversary is mining at a historical state relative to the current chain state. Even if they mine a Dominant Block, it will not be recognized by Z. Thus, if there exists \(\mu /(c + \mu ) > \rho /c\) in Z, then except for a negligible probability, the adversary will never catch up with the progress of honest participants, and C will never become the main chain.

Due to the setting of the heaviest main chain and the fact that blocks in the chain are connected based on weight, the probability of this branch becoming the main chain is negligible. Additionally, even if an adversary adds a new block after \(\Delta\) rounds, they will not gain an advantage in weight, which proves the lemma. \(\square\)


Common Prefix: The common prefix property is used to ensure that when there is no malicious adversary, all participants agree on a common prefix, with only a negligible number of blocks being different.

Lemma 3

When there is no adversary, honest participants in any two positions will have a common prefix of length l, and for the remaining \(T = c \cdot \text {poly}(k)\), the number of differences is negligible.

Proof

We consider an honest participant A with a chain of length \(l_1\) and an honest participant B with a chain of length \(l_2\). The first scenario is that \(l_1 = l_2\), where the chains of A and B have a common prefix of length l, i.e., \(l_1 = l_2 = l\). In the second scenario, the chain lengths differ, \(l_1 > l_2\), or \(l_1 < l_2\). Without loss of generality, consider the case where \(l_1 > l_2\). Due to the execution of \(\Pi (1^k)\), for any two adjacent honest participants, they will not differ by more than one block. Therefore, their chains \(C_1\) and \(C_2\) must have a common prefix \(C^*\) that is only negligibly different. Additionally, within the finite round delay \(\Delta\), participant B will add the new block to \(C_2\) to form a new common prefix \(C'\). Thus, even with high traffic, honest participants will converge toward the same chain within \(\Delta\) time. Consequently, the lemma is proven. \(\square\)


Chain Quality: The chain quality property ensures that the honest nodes control a significant fraction of the blocks in the blockchain. The number of blocks controlled by honest nodes in a sufficiently long portion of the chain is at least a certain fraction.

Lemma 4

Consider an execution \(\text {EXEC}(\Pi , C)(A, Z, \kappa )\). For any sufficiently long chain C and any position i, within any consecutive portion of the chain with length m, the fraction of blocks controlled by honest nodes is at least \(\alpha\).

Proof

This proof follows the analysis in [32]. Assume that the fraction of blocks controlled by honest nodes is less than \(\alpha\). Given the mining advantage of honest participants and the weight model, honest nodes will eventually surpass the adversary, contradicting the assumption. Therefore, the fraction of blocks controlled by honest nodes must be at least \(\alpha\), as stated.

In summary, the above lemmas demonstrate that the Ghost-Weight protocol satisfies the core security properties required for a blockchain protocol: chain growth, chain quality, and common prefix. These properties ensure that the protocol can withstand adversarial attacks and maintain consistency and integrity across the network. \(\square\)

5 Performance evaluation

In this section, we will delve into the details of our experimental setup, the performance evaluation metrics employed, and the analysis of the experimental results. For our experiments, we established a blockchain environment within the Ethereum network. Simulated IoT devices served as blockchain nodes, with their parameters outlined in Table 2. The performance characteristics of each blockchain node were derived from dataset [33], which follows a normal distribution. The network nodes’ workload was based on representative mining tasks. We implemented the Node Partition and Ghost-Weight Protocol, configuring a network cycle duration of 1 h and repeating the process 50 times.

At the outset of the experiment, we observed the operation of the Ethereum network under default conditions. Subsequently, we simulated a selfish mining attack to observe the variations in network performance and security. We documented the mining behavior of each participant, network performance metrics, and security indicators. The data analysis involved comparing the data before and after each experimental phase to evaluate the protocol’s impact on enhancing network performance and security.

This experimental approach in a simulated Ethereum environment, utilizing IoT devices as blockchain nodes, allows us to systematically assess the proposed Node Partition and Ghost-Weight Protocol under various conditions, providing valuable insights into their effectiveness and resilience in practical blockchain scenarios.

Table 2 Experiment setup
Full size table

5.1 Network performance

We deployed the Node Partition and Ghost-Weight protocols in the network and conducted one-hour-long network consensus under various network bandwidth configurations, repeating the process 50 times. The experimental results are depicted in Figs. 5 and 6.

Fig. 5
figure 5

Comparison of transaction throughput

Full size image
Fig. 6
figure 6

Transaction throughput in Mbps

Full size image

Figure 5 illustrates the achievements of our proposed scheme in improving network throughput. We selected several prominent IoT blockchain projects for comparison, with Ethereum serving as the baseline. The x-axis represents different IoT blockchain platforms, with Ethereum as the biberence. The y-axis indicates the throughput achieved by each project, representing the number of transactions generated per second in the blockchain network. Under our proposed scheme, the blockchain network achieves a throughput of 2500 transactions per second.

Fig 6 illustrates the impact of block propagation delay on network throughput. The x-axis represents different network bandwidth limitations (in Mbps), and the y-axis represents the achieved throughput of the network. The PropagationDelay represents the preset block propagation delay, indicating the proportion of newly generated blocks propagated from one node to other nodes in the network. The experimental results indicate that, under varying network block propagation delays, network throughput is only slightly affected at lower bandwidth limitations. As bandwidth limitations increase, block propagation delay ceases to be a limiting factor for network throughput. Moreover, with a bandwidth limitation exceeding 2 Mbps, network throughput experiences a significant increase. Under a 4 Mbps bandwidth limitation, the network achieves a throughput of 4000 transactions per second.

The above experimental results indicate that network throughput is predominantly constrained by the bandwidth limitations of nodes. Under a 4 Mbps bandwidth limitation, this protocol achieves relatively high throughput. This is attributed to the increased performance of nodes, leading to higher block generation speeds and larger average block sizes in the network. Consequently, the blockchain network experiences a higher incidence of forks. In the Nakamoto consensus protocol, blocks not on the longest chain are considered invalid and discarded. In the Ghost protocol, uncle blocks are not truly incorporated into the total order of the blockchain, resulting in significant wastage of forked block resources. In this protocol, such blocks are processed and added to the chain. Additionally, this protocol adheres to the principle of the heaviest chain, and the block confirmation process aligns with traditional consensus protocols.

At the same time, we recorded the handling of fork blocks in the network and compared the results with different consensus protocols. The results are shown in Figs. 7 and 8.

Figure 7 illustrates the number of fork blocks processed by the blockchain network using the Ghost protocol and our proposed solution under different network bandwidth constraints over a ten-minute period, as well as the total percentage of fork blocks processed. The x-axis represents the network bandwidth limit, and the y-axis represents the number of fork blocks processed by the network. The experimental results show that when the bandwidth limit is set to 1 Mbps, the network processed 1,067 fork blocks, with fork blocks accounting for 43% of the total. When the bandwidth limit is set to 4 Mbps, the proportion of processed fork blocks increased to 72

Figure 8 displays the throughput achieved by the network using different consensus protocols and varying numbers of nodes under the same protocol settings. The x-axis corresponds to the number of network nodes, and the y-axis corresponds to the number of blocks in the network. The experimental results indicate that, under the same network configuration, our solution achieves a higher block generation rate compared to traditional consensus protocols. According to these results, the increase in block generation rate caused by this solution leads to a faster blockchain growth rate. Furthermore, this growth rate is linearly related to the performance of the nodes.

Finally, we compared the efficiency of Ghost_Weight with other consensus protocols by measuring the time from block production to final transaction confirmation in the network. To make the comparison more intuitive, we used a fixed hash difficulty. We compared POW, Ghost, PBFT, PosP, and DPOS, and the results are shown in Fig. 9. It can be observed that, except for DPOS and PosP, which maintain relatively constant confirmation times due to their specific mining characteristics, our solution achieves shorter confirmation times compared to other node-mining protocols. Additionally, the confirmation time does not significantly increase as the network scale expands.

Fig. 7
figure 7

Processed fork blocks in Mbps

Full size image
Fig. 8
figure 8

Comparison of block generation rate

Full size image
Fig. 9
figure 9

Comparison of efficiency

Full size image

5.2 Network security

We conducted simulations of selfish mining attacks in both a default blockchain network and a blockchain network deployed with our protocol. We assumed that a malicious miner continuously performed selfish mining attacks, while other miners in the network participated normally in consensus activities. We monitored the behavior of each miner, recorded relevant mining activities, and assessed their impact on network performance and security metrics.

The simulation of selfish mining attacks aims to verify the robustness of our solution in adversarial environments. By comparing the simulation results of the default blockchain network with those of the enhanced network we proposed, we can gain a comprehensive understanding of the effectiveness of the Node Partition and Ghost-Weight protocols in preventing selfish mining attacks. Additionally, we evaluated their impact on overall network performance and security. Figures 10 and 11 provide detailed insights into the impact of selfish mining attacks on the default blockchain network settings, while Figs. 11 and 12 demonstrate the performance of our proposed solution in mitigating selfish attacks.

Fig. 10
figure 10

Revenue and orphan block ratio in a default blockchain network

Full size image
Fig. 11
figure 11

Revenue and profit threshold in a default blockchain network

Full size image

In the default blockchain network scenario, we gradually increased the hash rate of the malicious nodes. It was observed that as the hash rate increased, the profitability of the malicious nodes rose, and the system security decreased. When the hash rate of the malicious nodes increased from 0 to nearly 1, we recorded the expected profitability of the malicious nodes through selfish mining and the network’s orphan block rate. At hash rates of 0.15, 0.3, and 0.4, the profitability probabilities were 21.57%, 24.64%, and 32.48%, respectively, while the orphan block rates were 26.1%, 30%, and 32.3%. A clear conclusion is that an increase in the malicious nodes’ computational power makes selfish mining more profitable. At the same time, the orphan block rate rises rapidly with the increase in hash rate. Although a high orphan block rate may expose the attacker’s identity, it still poses significant risks to the system.

Subsequently, when we increased the number of selfish mining blocks from 0 to 5, the profitability threshold for the malicious nodes decreased significantly. By increasing the number of selfish mining blocks, malicious nodes could achieve a lower profitability threshold. After reaching 5 blocks, the threshold stabilized. Additionally, as the number of selfish mining blocks increased, the profit of the malicious nodes significantly increased. This positive correlation indicates that as malicious nodes retain more blocks, their overall profit in the network increases significantly. This phenomenon highlights the potential gains that malicious actors could obtain through selfish mining and underscores its potential impact on blockchain network security. The decrease in profitability threshold and the increase in profit indicate an increased network risk, especially for malicious nodes with higher hash rates.

Fig. 12
figure 12

Revenue and orphan block ratio in our protocol blockchain network in different hashrate

Full size image

To evaluate the impact of node partitioning on network inclusivity and decentralization, we designed a series of experiments. We selected nodes with varying numbers and performance characteristics from a node dataset to join the network. These nodes were integrated into the blockchain network after undergoing node partitioning, implementing the Node Partition and Ghost-Weight protocols. We set a network cycle of 1 h and repeated the experiments 50 times.

In Fig. 13, we track the number of transactions verified by a set of performance-diverse nodes (mainly characterized by differences in CPU computing power, while bandwidth remained constant) in the network. Specifically, nodes 1, 2, and 3 have lower computing power compared to nodes 4, 5, and 6. Figure 13 shows the experimental results, where the x-axis represents the number of network nodes and the y-axis represents the number of transactions verified by the respective nodes. The observations indicate that, although nodes 1, 2, and 3 have lower performance compared to nodes 4, 5, and 6, the number of transactions they verify is generally higher than that of the latter. This suggests that even without participating in mining, nodes remain actively engaged in the consensus process.

In Fig. 14, we report the number of addresses involved in the coinbase transactions, i.e., the reward distribution among nodes for mining a block. The data in the figure indicate that, in addition to the miner who discovered the block, other nodes also have the opportunity to receive coinbase rewards. Although these nodes do not directly participate in mining, they still receive a portion of the rewards from coinbase transactions through their participation in the consensus process.

Fig. 13
figure 13

Node participation in consensus activities

Full size image
Fig. 14
figure 14

Number of node receive coinbase rewards

Full size image

5.3 Network scalability

To investigate the scalability of our approach, we simulated an expansion of network nodes to 10,000, including 500 workload nodes, with a block generation interval of 1 s and a bandwidth limit of 1Mbps. The experimental results indicate that, under the given network settings, network throughput is significantly constrained by the bandwidth limitation of network nodes, leading to a sharp increase in block confirmation time and severe limitations on throughput. This is because our approach requires fetching new blocks from the network to handle forked blocks, and the number of nodes in the network necessitates a substantial block transmission rate.

Subsequently, we adjusted the network bandwidth limits to 10Mbps and 20Mbps, keeping other network configurations unchanged. The experimental results demonstrate that under a 10Mbps network constraint, the throughput reached 3,850 transactions per second, and under a 20Mbps network constraint, it achieved nearly 6,000 transactions per second. This highlights the ability of our approach to effectively scale the network nodes while achieving superior performance in blockchain network functionality.

6 Conclusion

In this paper, we have proposed a consensus mechanism aimed at enhancing the efficiency, fairness, and security of blockchain networks in the Internet of Things (IoT) environment. Our proposed mechanism comprises two crucial components: Node Partition and the Ghost-Weight Protocol. The Node Partition scheme ensures that any node can participate in consensus activities based on its computational power and bandwidth, fostering inclusiveness and fairness in the network. The Ghost-Weight Protocol accommodates forked blocks in the network, thereby improving network resource utilization and transaction throughput. To validate our proposed protocol, practical experiments were conducted, and the results demonstrate that our approach achieves efficient, secure, and fair transaction verification and network consensus in IoT environments characterized by heterogeneous resource capabilities.