Abstract

High frequency (HF) is an important method for long-range communications and even the only mean when satellites are destroyed or interfered, which play an essential role in defense and economic construction. However, noncooperative frequency competition accompanied with power competition results in the continuously deterioration of HF electromagnetic environment. This article endeavors to resolve this issue through proposing blockchain-empowered HF spectrum management. Specifically, massive personal HF devices are organized around the preselected nodes to construct HF spectrum management IoT, further monitor, and share HF data through PBFT (Practical Byzantine Fault Tolerance) protocol. To address the scalability problem during the consensus, a multilayer PBFT consensus protocol is employed. Scalability evaluations show that increasing consensus layers of PBFT greatly reduces the communication complexity. Security assessments illustrate that the security performance will decline with the increase of layers. Tradeoff has been made between the communication complexity and security performance, indicating 2-4 layers PBFT is sufficient, which bring down the communication complexity and also achieve acceptable security performance.

1. Introduction

1.1. Background and Motivation

High frequency is an important method for long-range communication and even the only mean when the satellites are destroyed or interfered. Currently, wireless communication technologies, such as the 5th Generation Mobile Communication (5G) [1] and Internet of Things (IoTs) [2], are still in their booming era. Simultaneously, electromagnetic environment of high frequency (HF) band is persistently deteriorating, and HF background noise is increasing year by year, causing HF transmitters with hundreds or even thousands Watts hard to communicate well, which seriously threaten the survival and development of HF service.

So as to investigate the deteriorated degree of HF electromagnetic environment, we have monitored the evolution of HF electromagnetic environment for 5 years. The results are shown in Figures 1 and 2. From Figure 1, we can see that both the power and the number of HF signals are continuously increasing in the last 5 years. From Figure 2, we can see that in the past 5 years, the background noise of HF electromagnetic environment is increasing at a rate of 1 dB per year, which indicates that deteriorating trend of HF electromagnetic environment. How to reverse the deteriorating trend of HF electromagnetic environment? Our previous works indicate that noncooperative frequency competition accompanied with power competition is the key manual factor in the deterioration of HF electromagnetic environment [3]: The quality of HF communication largely depends on timely and accurately detecting of ionosphere evolution, which is hard to obtain, although hundreds of HF monitoring stations and ionosonde stations have been built. The reason is that HF transmitters neither know the ionosphere information in time nor guarantee the ionosphere of reflection point has HF monitoring stations or ionosonde stations. Then, people either blindly increase the transmission power to improve communication quality or arbitrarily switch to idle (local) HF, i.e., the noncooperative frequency competition accompanied with power competition. It can be asserted that if we still insist utilizing HF resources in a noncooperative way, the earliest invented long-range communication method, HF will be probably destroyed by ourselves.

Firstly, how to change the noncooperative utilization mode of HF band? HF amateur service provides a solution. Amateur is a radiocommunication service used for self-training, intercommunication, and technical investigation [4]. HF amateurs are also called HAM and are distributed all over the world. If HF amateurs connect to each other and construct the HF spectrum management IoT, further monitor, and share the data of HF electromagnetic environment; HF transmitters no longer need to blindly increase the transmission power or arbitrarily switch to idle (local) HF; i.e. HF transmitters no longer need to adopt the noncooperative frequency utilization mode, finally promote the reduction of HF background noise, and improve the HF electromagnetic environment.

Secondly, how to motivate HF amateurs to construct the HF spectrum management IoT and monitor/share the data of HF electromagnetic environment? Emerging blockchain technology provides solution. Blockchain is a completely new distributed infrastructure and computing paradigm [57]. It applies a block-chain structure to store and authenticate data and distributed consensus algorithm to generate and update data, and asymmetric encryption to guarantee the security during data transmission, and smart contracts to operate and edit data. In a word, blockchain provides a safe and efficient solution for data transmission in distributed systems, which can be transplanted to HF band and construct the new framework of HF spectrum management IoT.

1.2. Related Works

Spectrum management was organized all along in a centralized manner, which was criticized for its inflexibility. The emergence of blockchain technology enables people to notice the natural connection between blockchain and spectrum management. In 2018 Mobile World Congress, Rosenworcel, the speaker of FCC (Federal Communications Commission), said that blockchain can be recognized as lower-cost alternative of a centralized database to support shared access in specific spectrum bands [8]. Kotobi and Bilen in [9] attempted to apply blockchain to moving cognitive radio networks and proposed an Aloha medium-access protocol for dynamic spectrum access. Pei et al. in [10] combined cooperative spectrum sensing with mining in Bitcoin; each secondary user acts both a sensing node for cooperative sensing and a miner in blockchain network. After that, the applications of blockchain to spectrum management were investigated in [11, 12], including four typical scenarios, i.e., primary cooperative sharing, secondary cooperative sharing, primary noncooperative sharing, and secondary noncooperative sharing. The applications of blockchain in spectrum management are successively proceeded, some focus on UAV spectrum management [13, 14], some focus on the spectrum management in 5G/6G [1517], and some focus on the spectrum management in Internet of Vehicles [18, 19].

In the rough, most blockchain can be divided into three categories, i.e., public blockchain, private blockchain, and consortium blockchain. Majority of early studies adopt public blockchain in the distributed spectrum management and apply proof-of-work (PoW) or proof-of-stake (PoS) as consensus protocol [9, 20, 21]. With the deepening of research, challenges gradually surfaced. Devices should be authenticated in spectrum management, no matter under a distributed or centralized manner. However, permissionless blockchain, i.e., public blockchain, is contrary to this requirement. Secondly, as time elapse, there will be increasing devices participating in the blockchain network, while private blockchain has fixed amount of nodes and cannot scale up later. A consortium blockchain is a special blockchain with multiple preselected nodes to establish the distributed shared database with moderate cost [14, 22]. For consortium blockchain, devices are allowed to join the blockchain only after authentication, which is in accordance with the concept of spectrum management IoT [23, 24].

Consensus protocol has always been seen as the core of the blockchain, which can be divided into two categories. One is represented by PoW or PoS; the other is represented by Practical Byzantine Fault Tolerance (PBFT) [20]. The following advantages indicate PBFT is more appropriate than PoW or PoS for spectrum management IoT. Firstly, compared with the throughput of PoW (7 Transactions Per Second (TPS)), the throughput of PBFT can achieve thousands of TPS [25, 26], which is essential for processing massive spectrum data. Secondly, the energy efficiency of PBFT is far superior to PoW. Considering that a large number of personal HF devices, i.e. HAMs, participate in the consensus, the simple consensus process of PBFT (consensus only performed among preselected nodes) represents higher energy efficiency compared with PoW or PoS (consensus is performed by all nodes). Thirdly, the confirmation delay of PoW sometimes can be up to hours, while that of PBFT is only milliseconds [27]. Last but not the least, the poor scalability of PBFT has always been criticized. In this article, multilayer PBFT is proposed to achieve a tradeoff between scalability and security for HF spectrum management IoT.

1.3. Contributions

Motivated by the aforementioned observations, in this article, we exploit the consortium blockchain to develop a HF spectrum management IoT and apply PBFT protocol to achieve consensus among edge computing nodes. A multilayer PBFT is proposed to solve the problem of scalability [28]. A tradeoff has been made between communication complexity and security, so as to derive the optimal structure of the blockchain-empowered HF spectrum management IoT. Specifically, the contributions of this article are summarized as follows: (1)A blockchain-empowered HF spectrum management IoT is presented to motivate the personal HF devices to monitor and share the HF data for the first time. Massive personal HF devices are organized around the preselected nodes, i.e., 4G/5G base stations, to monitor and share the HF data, which bridges the gap between the collection of HF data and the inference of spectrum strategy(2)A multilayer PBFT consensus protocol is employed to achieve the tradeoff between the scalability and security. The detailed operations of consensus process are illustrated to show how spectrum management agencies, 4G/5G base stations, and personal HF devices overcome the disadvantages of scalability while preserving the advantages of its throughput and energy efficiency(3)Under the multilayer PBFT consensus, a tradeoff is formulated to obtain the optimal structure of HF spectrum management IoT, which jointly minimize the communication complexity and maintain an acceptable security performance

The rest of this article is organized as follows. Blockchain-empowered HF spectrum management framework and detailed operations are introduced in Section 2. In Section 3, a multilayer PBFT consensus is presented and the scalability of which is analyzed. In Section 4, the security of multilayer PBFT consensus is assessed to show the tradeoff between scalability and security. Scalability evaluation and security assessment are performed in Section 5, and conclusion has been made in Section 6.

2. Blockchain-Empowered Hf Spectrum Management

Blockchain is a decentralized database, a distributed infrastructure and computing paradigm, that uses block-chain structures to verify and store data and distributed consensus algorithms to generate and update data, asymmetric cryptography to ensure the security during the transmission and access, and smart contracts composed of automated script codes to program and manipulate data. In this section, a blockchain-empowered HF spectrum management IoT is proposed to timely and accurately obtain the changes of HF electromagnetic environment.

2.1. Overview of the Blockchain-Empowered HF Spectrum Management

Consensus in blockchain can be divided into two categories. The first category is represented by PoW, which is a computational processing called “mining”; i.e., a set of participants called miners need to solve a complex computation problem, i.e., proof-of-work puzzle, to confirm and secure the integrity and validity of transactions before adding the records into the blockchain. The security and privacy of the blockchain depend on the distributed consensus mechanism managed by these miners. However, in traditional public/permissionless blockchain (such as Bitcoin or Ethereum), the consensus is performed by all nodes (miners), which results in high cost and low throughput. To relieve the computation-intensive challenge of constructing HF blockchain, unlike existing works, in this article, a consortium blockchain is explored to empower the operation of HF spectrum management. Consortium blockchain is permissioned blockchain in which the consensus process is executed by preselected nodes. The consensus process of consortium blockchain is Practical Byzantine Fault Tolerance (PBFT), i.e., the second consensus protocol, with the throughput up to thousands TPS, which is essential to the blockchain empowered HF spectrum management, considering the HF spectrum data can be seen as a kind of big data [29]. Furthermore, the framework of private blockchain is also inappropriate for HF spectrum management, as the user of HF spectrum management is still increasing, while the number of user in private blockchain is fixed. Consequently, consortium blockchain is more suitable for HF spectrum management IoT.

In the proposed HF spectrum management IoT, the limited computing resource and energy supply become one of major problems, especially for the communication and computing load in the consensus-reaching process. Instead, edge computing provides necessary computing and communication resources for the blockchain-empowered IoT [30]. For example, base stations equipped with small data center can accept offloaded computation-intensive jobs from adjacent IoT devices [31]. Then, we leverage edge computing as an enabler to offload the computation-intensive puzzles to proximate edge computing nodes. Compared with traditional cloud computing [32, 33], edge computing brings network resources (e.g., computation power and storage space) closer to the users, which can effectively shorten the transmission delay and reduce the energy consumption [34]. The consortium blockchain-empowered HF spectrum management IoT is illustrated in Figure 3, which consists of the following major entities. (i)ITU HF Agency: ITU HF agency is a trusted authority and operated by International Telecommunication Union (ITU). In this framework, ITU HF agency is responsible for initializing the entire HF spectrum management IoT, including the preselected edge computing nodes. ITU HF agency authenticate personal HF devices, and generates the public/private keys for them. Note that the ITU HF agency is offline for most of the time. It does not serve as a central controller and is not conflict with the distributed characteristics.(ii)Computing nodes: computing nodes include an ITU HF server (cloud computing node) and edge computing nodes. The ITU HF server is operated by ITU and deployed at the same location of ITU HF agency. ITU HF server provides huge storage space and powerful computing power for inferring HF spectrum strategy in a centralized manner. Unlike ITU HF agency, the ITU HF server is online most of the time. 4G/5G base stations serve as edge computing nodes and provide relatively high computing power and large storage space for inferring HF spectrum strategy in a distributed manner. The storage space of edge computing nodes is mainly used to store HF spectrum data.(iii)Personal HF devices: personal HF devices, i.e., HF amateurs, also called HAM, are distrusted widely over the world. Generally, personal HF devices are responsible for monitoring HF electromagnetic environment and uploading HF data to the proximate edge computing nodes. In addition, HF spectrum data and transaction data are asymmetric encrypted before uploading or transmission.

Additionally, in the proposed framework, the HF blockchain composes of HF blocks, including HF spectrum data and transaction data. For each edge computing node, it packs the HF spectrum data and transaction data every period of time to generate a preadded HF block and broadcasts this preadded HF block to the surrounding edge computing nodes. The object is to reach consensus on the preadded HF block through PBFT protocol.

In the proposed framework, ITU HF agency is designed for authenticating personal HF devices and allocating public/private keys. The ITU HF server is deployed at the same place of ITU HF agency and provides large space and powerful computing power for storing HF spectrum data and inferring HF spectrum strategies. 4G/5G base stations are deployed in the edge, with the aim of providing relative large space and powerful computing power. Personal HF devices are located at the end of the network. Then, ITU HF agency, base stations, and personal HF equipment constitute an end-edge-cloud structure and apply edge computing to operate the blockchain-empowered HF spectrum management IoT.

2.2. Detailed Operations of the Blockchain-Empowered HF Spectrum Management IoT

In the operation of HF spectrum management IoT, the process can be divided into 3 steps, i.e., the collection of HF spectrum data, the generation of HF blocks, and the trading of HF spectrum data. We elaborate the details as follows. (1)Collection of HF spectrum data: in the 5G era, base stations can be regarded as the nodes with powerful computing power and massive storage space, which are deployed in a distributed manner. Here, each base station is assumed to manage surrounding HF electromagnetic environment. In ITU Spectrum Monitoring Handbook [35], -hour continuous spectrum monitoring is recognized sufficient to characterize the electromagnetic environment of a region. An HF electromagnetic environment is generally stable and partially dynamic. HF spectrum strategies of a certain region can be further inferred based on the collected HF spectrum data [36].

Personal HF devices can run an App that can be seen as smart contract, to automatically collect HF spectrum data. Personal HF devices upload the collected HF spectrum data to the proximate edge computing node for a period of time.

In the proposed framework, the automatically collected HF spectrum data has identical data structure that can be directly used by most personal HF devices. Intuitively, HF spectrum data is a kind of big data. If we use 1 byte to represent the HF spectrum data in a geospatial grid of , and the frequency and time resolutions are assumed to 1 kHz and 100 ms, respectively. After one month, the total HF spectrum data size in the frequency band ranging from 2 to 30 MHz and a geospatial region of can be as large as

By comparison, Facebook, one of well-known big data examples, generates approximately  TB per month. The size of HF spectrum data described above is approximately half of Facebook in the same duration. Moreover, the size of HF spectrum data will grow with the time duration and spatial scale, as well as the corresponding resolution in each dimension. It will cause heavy pressure to the ITU HF Server, needless to say under a centralized network framework.

Edge computing could efficiently processing HF spectrum data. Once the base station receives the HF spectrum data and transaction data that uploaded by personal HF devices, it extracts the key information from the HF spectrum data and generates a digest. The main body of HF spectrum data is locally stored in edge computing nodes. (2)Trading of HF spectrum data: the uploaded HF spectrum data is divided into the digest and main body of HF spectrum data. Edge computing nodes cooperate through PBFT protocol to reach consensus on uploaded HF spectrum data to form the preadded HF blockchain. HF blockchain is stored online and saved as a copy in each edge computing node. It should not take a large space to store the HF blockchain and not take long to download the HF blockchain, since the HF blockchain only saves the digest of HF spectrum data, which indicates the main body of HF spectrum data is stored in which edge computing node. When personal HF devices need to download the main body of HF spectrum data for inferring HF spectrum strategy, it locates the exactly base station, i.e., the edge computing node, that the main body of HF spectrum data is stored and connects the base station to download through high speed 4G/5G channels.

If massive personal HF devices, i.e., HF amateurs, share HF spectrum data, HF strategy is expected to change from noncooperative frequency competition accompanied with power competition to cooperative competition and sharing. It will gradually reduce the HF background noise and improves HF electromagnetic environment. Consequently, personal HF devices need to make use of HF spectrum data to infer HF spectrum strategy. The above process can be concluded into four steps, as shown in Figure 4. (i)Personal HF device searches HF blockchain and locates corresponding edge computing node through the digest that stored in HF block(ii)Personal HF device pays some HF coins(iii)Personal HF device downloads corresponding HF spectrum data(iv)Personal HF device infers HF spectrum strategy according to the downloaded HF spectrum data

In the third step, when personal HF device needs to download corresponding HF spectrum data, there are two options: (1)Option 1: the main body of HF spectrum data is stored in local edge computing node. Personal HF device pays some HF coins to local edge computing node and downloads corresponding HF spectrum data. Edge computing node receives minority HF coin and transfers majority HF coin to personal HF devices that provide HF spectrum data.(2)Option 2: the main body of HF spectrum data is stored in foreign edge computing node. Personal HF device sends request to foreign edge computing node through local edge computing node and pay some HF coins beforehand. Foreign edge computing node transmits corresponding HF spectrum data through high-speed network, e.g., 4G/5G network, to the local edge computing node. Then, HF coins are transferred to personal HF devices that provide HF spectrum data.

In the fourth step, when personal HF device infers HF spectrum strategy according to the downloaded HF spectrum data, there are also two options. (1)Option 1: personal HF device infers HF spectrum strategy locally. If personal HF device has enough computing power and storage space, it could infer HF spectrum strategy locally.(2)Option 2: local edge computing node assist personal HF device inferring HF spectrum strategy. If personal HF devices do not have enough computing power, it could send the requirements to local edge computing node and pay some HF coins. With relative sufficient computing power and large storage space, local edge computing node could quickly infer the HF spectrum strategy and then transmit the results back to personal HF device.

Moreover, the security during the transmission is guaranteed by asymmetric encryption [37]. For instance, when personal HF device transmits HF spectrum data to edge computing node , device downloads the public key of node and encrypts :

is the encrypted HF spectrum data, RSA is the asymmetric encryption algorithm [38], and is the public key of edge computing node . When edge computing node receives , it decrypts with his private key and obtains the HF spectrum data:

Secondly, personal HF devices can check whether HF spectrum data has been tampered. When personal HF device uploads HF spectrum data to edge computing node, device first generates the digest of through Hash algorithm [39]:

Device encrypts the digest and generates digital signature:

Device appends to the end of and uploads to edge computing node. Then, other personal HF devices can decrypt with the public key of device and obtain : Other personal HF devices apply Hash Algorithm to and obtain the digest . Then, other personal HF devices compare with ; if , it indicates that the HF spectrum data has not been tampered. (3)Generation of HF Block: when the accumulated HF spectrum data of a certain region exceeds hours, the base station iteratively discards redundant HF spectrum data to make it light-weighting. Once the accumulated HF spectrum data reach a certain amount, e.g., 24 hours, the edge computing node extracts the key information and generates a digest and packs with the transaction data to form the preadded HF block; then, broadcasts it to surrounding edge computing nodes and seeks for consensus. The preadded HF block contains a unique serial number, duration/spectrum range/monitoring location, time/frequency/spatial resolution, data size, and storage location (i.e., the location in the base station). The size of the preadded HF block is relatively small. Note that the preadded HF blocks are asymmetric encrypted (e.g., SHA-256 algorithm) by the private key of the edge computing node. When these edge computing nodes reach consensus about the preadded HF block, it will be appended at the end of the HF blockchain and becomes an official block. Note that other personal HF devices could decrypt HF block with the public key of edge computing node that uploaded online and easily obtain the location of demanding HF spectrum data through the digest of HF spectrum data. When the preadded HF block becomes an official one, the personal HF devices that provide the HF spectrum data will get some HF coins automatically as rewards. As stated above, the strategy that the HF spectrum data been divided into digest and main body and been stored in HF blockchain and edge computing node, respectively, not only greatly reduces the traffic load but also saves the computing power and energy consumed in the consensus process.

The structure of HF block is illustrated in Figure 5, including the digest of HF spectrum data, transaction data, timestamp, and the hash value of the previous block. HF blocks are linked end by end according to the timestamp, which record the time of consensus-reached. The subblocks are organized in the structure of Merkel Tree. Note that HF blocks only contain the digest of HF spectrum data, and the main body is stored at corresponding edge computing node. Similar to Bitcoin, the ITU HF server regularly releases HF coins for their contributions of collecting HF spectrum data. When surrounding edge computing nodes reach consensus on the preadded HF block, the HF block will be appended to the end of HF blockchain, personal HF devices that provide HF spectrum data and edge computing nodes participating in consensus both will be rewarded some HF coins. HF coins can be used to purchase additional HF bandwidth and additional HF spectrum usage rights.

3. Scalability of Multilayer PBFT Consensus

3.1. Multilayer PBFT Consensus

Before introducing the multilayer PBFT, we first review the single-layer PBFT protocol. Practical Byzantine Fault Tolerance was first presented to solve the malicious attacks in Byzantine General Problem [25, 26]. Figure 6 shows the flow chart of the single-layer PBFT; one primary node (replica 0) and three replicas work together to carry consensus process forward. The whole consensus process generally includes 5 steps, i.e., request, preprepare, prepare, commit, and reply. PBFT consensus is triggered by a client sending a request message to the primary node. Then, primary node broadcasts a preprepare message to other replicas. All replicas, including primary node, send messages to each other for checking the validity of the received messages in prepare and commit steps. Finally, if an agreement is achieved in reply step, the preadded HF block will be added to end of HF blockchain.

PBFT consensus is designed to tolerate f faulty nodes with a total number of replicas [25, 26]. Therefore, the security threshold of the single-layer PBFT can be seen as , given a total number of replicas participating the consensus process. From Figure 6, we can see that PBFT is a communication-intensive consensus process. Given the total number , the single-layer PBFT requires times internode communications to reach consensus. Obviously, the communication complexity will become increasingly unaffordable with the increasing of nodes. It is also the reason for the poor scalability of the PBFT consensus.

Next, a multilayer PFBT is applied to bring down the communication complexity to an acceptable level when the number of nodes sharply increases. Generally speaking, the core idea of the multilayer PBFT consensus is successively inserting a PBFT consensus between commit and reply steps to reduce the whole communication complexity [28]. The consensus process of the second layer is inserted after the commit step; after that, each node has generated his own judgment about whether the preadded HF block is valid. At this time, whether the PBFT consensus of the second layer is reached only affects the reply message of one replica in the first layer and will not affect the reply message of other replicas. As an example, Figure 7 illustrates the process of two-layer PBFT, Replica 3 is assumed to be a malicious node, which is down during the whole consensus process, where the first layer contains replicas, and each serves as a primary node () with sublayer replicas in the second layer. Then, the total number of nodes in the double-layer PBFT consensus is . The pseudocodes of Primary, , and for two-layer PBFT consensus are described in Algorithms 1, 2, and 3, respectively. Note that we assume each group in the second layer contain the same number of nodes. A previous study has derived the communication complexity of a double-layer PBFT system [27].

while valid request1 received=True do
  if client identity authenticated=True then
   mn
   multicasts pre−prepare1 to Primary
  end if
end while
while valid prepare1 received=True do
  if number of valid prepare1≥ 2fthen
   prepare1=valid
   multicast commit1 to
  end if
end while
while valid commit1 received=True do
  if number of valid commit1≥2fthen
   commit1=valid
  end if
end while
while valid reply1 received=True do
  if number of valid reply1≥2fthen
   reply client with reply1
  end if
end while
while valid pre-prepare1 received=True do
  multicasts prepare1 to
end while
while valid prepare1 received=True do
  if number of valid prepare1≥2fthen
   prepare1=valid
   multicasts commit1 to
  end if
end while
while valid commit1 received=True do
  if number of valid commit1≥2fthen
   commit1=valid
   multicasts sub-pre-prepare2 to
  end if
end while
while valid sub-prepare2 received=True do
  if number of valid sub-prepare2≥2fthen
   sub-prepare2=valid
   reply primary with reply1
  end if
end while
while valid sub-commit2 received=True do
  if number of valid sub-commit2≥ 2f then
   reply client with reply1
  end if
end while
while valid sub-pre-prepare2 received=True do
  multicasts sub-prepare2 to in the same
  consensus group
end while
while valid sub-prepare2 received=True do
  if number of valid sub-prepare2≥2fthen
   sub-prepare2=valid
   multicasts sub-commit2 to in the same
   consensus group
  end if
end while
while valid sub-commit2 received=True do
  if number of valid sub-commit2≥2fthen
   sub-commit2=valid
   send sub-reply2 to group leader
  end if
end while
3.2. Scalability of Multilayer PBFT Consensus

Therem 1. For a double-layer PBFT consensus process with replicas in the first layer and sublayer replicas in

Then, what is the optimal network structure that achieve the lowest communication complexity for the double-layer PBFT? The optimization problem can be formulated as

As is total number of nodes and the constrains are , Problem 1 is a quadratic integer programming problem and is nonconvex. Substituting into Equation (8), we have

It is an integer programming problem and NP-hard problem. Considering that the feasible solution domain is not very large under the constraint , the optimal network structure can be solved by exhaustive searching.

Consider the case of multilayer PBFT, the communication complexity can be derived accordingly.

Therem 2. For a double-layer PBFT consensus process with replicas in the first layer and sublayer replicas in each subgroup, the communication complexity C2 to reach consensus is

Based on the above analysis, we infer that, given the total number of edge computing nodes , the minimum communication complexity can be achieved when PBFT consensus has the most layers. The PBFT consensus contains the most layers, meaning that each group only contains the least nodes, i.e., 3 nodes. At this time, PBFT consensus has the most layers :

Then, the total number of nodes in PBFT system can be written as

Thus, the lowest communication complexity can be expressed as

It can be seen that the communication complexity has a linear relationship with the number of edge computing nodes . Intuitively, it is impossible to reduce the communication complexity without any cost. We can see in the following that the cost is the system security. Consequently, when we increase the layers of PBFT consensus to reduce the communication complexity, the security of PBFT consensus will be degraded at the same time. In order to maintain a basic security performance when we reduce the communication complexity, it is necessary to make a tradeoff between communication complexity and system security. We discuss it in the following subsection.

4. Security Analysis of Multilayer PBFT Consensus

4.1. Security of Double-Layer PBFT Consensus

Security of double-layer PBFT is discussed firstly. Assume that the 1st layer contain edge computing nodes, and each group in the 2nd layer contains nodes. The double-layer PBFT can reach consensus under following conditions: the summation of the number of malicious edge computing node (name as malicious nodes hereinafter) in the 1st layer and the number of groups of the 2nd layer that does not reach consensus (the head node is normal) should be less than or equal to , i.e., . The 1st layer contains malicious nodes indicating that there are groups that cannot reach consensus and there are groups failing to reach consensus in the 2nd layer meaning the head nodes of these groups are treated as malicious nodes.

If there are malicious nodes in the 1st layer, it means the number of groups that fails to reach consensus is no more than bm1 , i.e., . That is to say, two necessary conditions constitute the sufficient condition of consensus-reached. In the premise of the 1st layer contains no more of malicious nodes, the 2nd layer contains no more than groups that fail to reach consensus; then the system can reach consensus. We have the following definitions. (i)Event A1: the 1st layer contains no more than malicious nodes.(ii)Event B2: the 2nd layer contains no more than group that fails to reach consensus.

, is the probability of consensus-reached for the double-layer PBFT. We have where is the probability that the nodes of the 1st layer are malicious and is the probability that the group of the 2nd layer fails to reach consensus, which is derived as follows.

If (the head node of the group in the 2nd layer is normal), the group fails to reach consensus. can be written as

The probability of consensus-reached for the double-layer PBFT is derived as

4.2. Security of Multilayer PBFT Consensus

Next, we analyze the security performance of the three-layer PBFT and further derive the security performance of -layer PBFT. Please note that the derivation of security performance of the three-layer PBFT has some differences with that of the double-layer PBFT. The number of nodes in the 1st layer is assumed to be , and the numbers of nodes in the group of 2nd and 3rd layer are denoted as , respectively. The number of malicious nodes in the 1st layer is assumed to be , and the numbers of malicious nodes in the group of 2nd and 3rd layer are denoted as , respectively.

The numbers of groups that do not reach consensus in the 2nd/3rd layer are assumed to be (the head node is normal). We can infer that the consensus is reached or not is determined by the number of malicious node in the 1st layer and the number of groups that does not reach consensus in the 2nd layer , i.e., . Let denote the probability that the number of malicious nodes in the 1st layer less than and represent the probability that the number of groups have not reached consensus in the 2nd layer less than . Then, we have , where is the probability of three-layer PBFT reaching consensus. We can derive where is the probability that the group in the 2nd layer fails to reach consensus. Given the head node is normal, how does the group fail to reach consensus? Considering that there are nodes and malicious nodes in the 2nd layer and there are groups in the 3rd layer failing to reach consensus, when , the 2nd layer cannot reach consensus. We have

Let denote the probability that and denote the probability that . Equation (18) indicates that, except for and , the groups in the 2nd layer always cannot reach consensus. We have where is the probability that the group in the 3rd layer fails to reach consensus. Similarly, we have indicating that the group in the 3rd layer cannot reach consensus when .

Substituting (17)–(20) into , we can derive the probability of consensus-reached of three-layer PBFT. Then, the probability of consensus-reached of the -layer PBFT can be derived as follows.

The numbers of nodes in the 1∼-th layer are assumed to be . The numbers of malicious nodes in the 1∼-th layer are assumed to be . The numbers of groups that do not reach consensus in the 2∼ layer are denoted as (the head node is normal). The security of -layer PBFT is where is given by

5. Scalability Evaluations and Security Assessments

In this section, a scalability evaluation of the proposed multilayer PBFT consensus is firstly given. After that, some security assessments are provided to show that we should reasonably design the structure of multilayer PBFT consensus for the blockchain-empowered HF spectrum management, in order to tradeoff between scalability and security.

5.1. Scalability Evaluations of Multilayer PBFT Consensus

In this subsection, the scalability performance of multilayer PBFT consensus is demonstrated. Intuitively, the poor scalability of the PBFT consensus mainly comes from the sharply increasing of communication complexity as the number of nodes increases. Consequently, the scalability of the PBFT consensus will be greatly improved with the reduction of communication complexity.

In Evaluation 1, four schemes are demonstrated in Figure 8 to show the improvement in communication complexity of double-layer PBFT. In Scheme 1, double-layer PBFT, keeps the minimum (, include one head node) and increases linearly. In Scheme 2, double-layer PBFT, increases linearly and keeps the minimum (). In Scheme 3, double-layer PBFT with . In Scheme 4, double-layer PBFT with an optimal network structure achieves the lowest communication complexity. Evaluations are performed under the constraint of . Obviously, the communication complexity of double-layer PBFT is significantly reduced compared with that of single-layer PBFT. Secondly, the communication complexity of Scheme 2 further reduced compared with that of Scheme 1, indicating that we should first increase the nodes in the 1st layer, i.e., , rather than the nodes in each group of the 2nd layer, i.e., . Thirdly, compared with the communication complexity of single-layer PBFT, the communication complexities of Scheme 3 and Scheme 4 reduce by at least 1 order of magnitude. Fourthly, the communication complexity of Scheme 3 is relatively close to that of Scheme 4, indicating that is a suboptimal solution when the optimal network structure cannot be obtained.

The optimal network structure of double-layer PBFT when the lowest communication complexity achieved is shown in Figure 9. It can be seen that as the total number of nodes increases, the number of nodes in the 1st layer, i.e., , increases almost linearly, while the number of nodes in each group of the 2nd layer, i.e., , hardly increases. From (6), we can see that the communication complexity of double-layer PBFT, i.e., , has a linear relationship with and . Therefore, for the double-layer PBFT, when the total number of nodes increases, we should firstly increase the nodes in the 1st layer, i.e., , rather than increase the nodes in the 2nd layer, i.e., .

Figure 10 shows the lowest communication complexity under different layers PBFT with the variation of the number of nodes, which further confirms the conclusion that the more layers in PBFT are, the lower of communication complexity is.

5.2. Security Assessment of Multilayer PBFT Consensus

Given the total number of nodes , the security performance of -layer PBFT (, , and ) is illustrated in Figure 11. It can be seen that when is relatively low, the probabilities of consensus-reached decrease with . When is relatively high, the probabilities of consensus-reached increase with instead, which indicates that increasing PBFT layers does not always bring down the security performance. When is relatively high, we have . However, the security performance decreases sharply and becomes very poor at that time, and it is almost impossible to reach consensus for the multilayer PBFT. Secondly, with the increasing of , the critical point, i.e., the intersection point of , , and , gradually moves forward and indicates that the increasing of will reduce the security performance.

The security performances of the double-layer PBFT under different number of nodes are illustrated in Figure 12, given . It can be seen that when , increasing the number of nodes will improve the security performance (probability of consensus-reached). On the contrary, when , increasing the number of nodes will reduce the security performance (probability of consensus-reached).

Consequently, in order to greatly reduce the communication complexity and obtain an acceptable security performance, too many layers are unpractical. A 2- to 4-layer PBFT is sufficient to bring communication complexity down and also achieve an acceptable security performance.

6. Conclusion

In this article, a consortium blockchain-empowered HF spectrum management is exploited to improve the deteriorating HF electromagnetic environment; massive personal HF devices are organized around the preselected nodes to monitor and share HF data through PBFT protocol. To address the scalability problem, a multilayer PBFT consensus protocol is presented. Scalability evaluations shows that increasing the layers of PBFT greatly reduce the communication complexity. Security assessments illustrate that the security performance does not always decrease with the increasing of the layers of PBFT, but fewer layers indeed guarantee a better security performance. Tradeoff has been made between the communication complexity and security performance, a 2- to 4-layer PBFT is considered sufficient to bring the communication complexity down and also achieve an acceptable security performance. In a future work, it is interesting to extend the utilization of blockchain-empowered HF spectrum management for better improving HF electromagnetic environment, such as deployment optimization of edge computing nodes and spectrum strategy inference under energy constraint.

Data Availability

The supporting data are not yet open to public access.

Conflicts of Interest

The authors declare that they have no conflicts of interest.