# A Trust-Centric Privacy-Preserving Blockchain for Dynamic Spectrum
Management in IoT Networks

Jingwei Ye, Xin Kang, , Ying-Chang Liang, , and Sumei Sun J. Ye, X. Kang and
Y.-C. Liang are with the Center for Intelligent Networking and Communications
(CINC), University of Electronic Science and Technology of China (UESTC),
Chengdu 611731, China (e-mail<EMAIL_ADDRESS><EMAIL_ADDRESS>liangyc@ieee.org).S. Sun is with the Institute for Infocomm Research, Agency
for Science, Technology and Research, Singapore (e-mail:
sunsm@i2r.a-star.edu.sg).

###### Abstract

In this paper, we propose a trust-centric privacy-preserving blockchain for
dynamic spectrum access in IoT networks. To be specific, we propose a trust
evaluation mechanism to evaluate the trustworthiness of sensing nodes and
design a Proof-of-Trust (PoT) consensus mechanism to build a scalable
blockchain with high transaction-per-second (TPS). Moreover, a privacy
protection scheme is proposed to protect sensors’ real-time geolocatioin
information when they upload sensing data to the blockchain. Two smart
contracts are designed to make the whole procedure (spectrum sensing, spectrum
auction, and spectrum allocation) run automatically. Simulation results
demonstrate the expected computation cost of the PoT consensus algorithm for
reliable sensing nodes is low, and the cooperative sensing performance is
improved with the help of trust value evaluation mechanism. In addition,
incentivization and security are also analyzed, which show that our design not
only can encourage nodes’ participation, but also resist to many kinds of
attacks which are frequently encountered in trust-based blockchain systems.

###### Index Terms:

Dynamic spectrum access, blockchain, trust model, consensus algorithm,
cooperative spectrum sensing.

##  I Introduction

Recent years have witnessed the exponential growth of mobile data traffic. The
rapid development of new wireless applications such as autonomous vehicles,
remote healthcare, augmented and virtual reality will continue driving the
demand for radio spectrum[1]. However, the current static spectrum management
method has resulted in under-utilization of spectrum resources[2]. To this
end, dynamic spectrum access (DSA) has been proposed to allow secondary users
(SUs) sense and then use the idle spectrum bands. Since single SU’s sensing
capability is usually limited, cooperative sensing[3] is proposed to fuse the
sensing results of multiple SUs to improve the sensing accuracy. However, the
traditional usage of a centre to collect and fuse sensing results faces the
risk of single point of failure and the increasing management and regulatory
costs. Moreover, SUs usually need to upload their sensing data to the fusion
center at the risk of leakage of their privacy, such as identity and location.

As an emerging technology, blockchain has attracted attention from both
academia and industry. By using blockchain, a decentralized resource
management system can be established without the requirement of trustworthy
central management agencies[4, 5, 6, 7, 8]. Moreover, smart contracts which
are implemented on a blockchain can be used to replace traditional central
management agencies and facilitate the cooperation of users [9]. Recently,
researchers have investigated how to apply the blockchain technology to DSA.
[10] summarizes the types of blockchains applicable in different spectrum
sharing scenarios, and the possible advantages and disadvantages of applying
blockchain technology to DSA. With the help of cryptocurrency issued by the
blockchain and smart contracts, flexible and automatic spectrum trading
markets are made possible for spectrum sellers and buyers. [11, 12, 13, 14,
15].

However, the integration of blockchain and DSA still faces many challenges.
Firstly, although the data recorded on a blockchain is prevented from being
tampered, the quality or value of it cannot be guaranteed. Especially, in a
public blockchain, a malicious user can easily join the blockchain and record
their data in the blockchain. The data from such a malicious user or an
unreliable user is valueless or even harmful to cooperation tasks based on the
data, e.g., cooperative sensing. Therefore, there is compelling need to
evaluate the quality of the data from each user. Secondly, though the
communication among Ethereum external accounts can be protected by encryption
and decryption with their public and private key pairs, a contract account is
not equipped with a key pair hence such protection method is not applicable to
smart contracts. As a result, sensing results uploaded to the smart contract
cannot be encrypted, and the sensitive information in the sensing results
(such as real-time geolocatioin), can thus be accessed by malicious users.
Thirdly, traditional consensus algorithms like Proof of Work (PoW) used in
public blockchain introduce much computation overhead and thus make the
transaction processing speed very low. As a result, it is inefficient to
directly use existing consensus algorithms (such as PoW) for spectrum
management, especially considering the limited computation capabilities of IoT
devices.

In this paper, we consider the DSA for an IoT network where IoT devices
opportunistically access the licensed spectrum bands through cooperative
sensing. Blockchain is used as a platform for dynamic spectrum management.
Specifically, key component designs for such a blockchain-enabled DSA system,
including the trust evaluation mechanism, privacy protection, consensus
algorithm and smart contracts, are studied. The main contributions of this
paper are summarized as follows.

  * •

We propose a trust evaluation mechanism to evaluate the trustworthiness of
sensing nodes which participate in the collaborative sensing. We show that the
proposed trust evaluation mechanism is effective in incentivizing sensing
nodes to be honest, and thus improving the spectrum sensing result.

  * •

We propose a strong privacy protection mechanism by combining ring signature
with the commit-and-reveal scheme for providing sensing nodes’ privacy such as
their real-time location. The ring signature is used to protect sensing nodes’
identities when they upload sensing data. The commit-and-reveal scheme is
proposed to figure out the connection between sensing data packets and its
originated sensing node after the fusion of sensing results, so that the trust
value of each sensing node is updated and the incentive tokens are
distributed.

  * •

We propose a new consensus algorithm named as Proof-of-Trust (PoT) by
connecting the mining difficulty with a miner’s trust value. We show that the
proposed PoT can greatly reduce the computation cost of honest nodes and
enhance the scalability of current blockchian-based DSA system.

  * •

We design the system protocol and two smart contracts to make the whole DSA
procedure, including spectrum sensing, spectrum auction, and spectrum
allocation, run automatically. In addition, we implement and verify a
prototype of our proposed protocol and smart contracts using Solidity[16] on
the Ethereum test net.

The rest of the paper is organized as follows. In Section II, we introduce the
basic concept of blockchain and smart contract. In Section III, we describe
the works related to the application of blockchain to DSA. In Section IV, we
introduce our system model. In Section V, we describe the design of our
proposed protocol including the block structure, the trust evaluation
mechanism, the consensus algorithm and the privacy protection scheme. In
section VI, the design of smart contract and workflow are introduced. In
Section VII, we discuss the performance of the trust evaluation mechanism, and
analyze the security of the system. Finally, Section VIII concludes this
paper.

##  II Preliminaries

###  II-A Blockchain

Blockchain is a growing chain of data blocks with a specific data structure
constructed using cryptographic algorithms. It uses hash pointers to connect
the data blocks to form an entangled chain. In this way, the integrity of the
data can be protected. Blockchain uses a measurable and verifiable mechanism
to reach a consensus among nodes in the network on the generation of new
blocks. Such a mechanism is usually referred to as the consensus algorithm. On
the premise that the data block entanglement is guaranteed, the structure and
the consensus algorithm of the blockchain can be flexibly designed based on
the demand of application scenarios.

Blockchain can be roughly classified into three types, depending on degree of
openness, which are public blockchain, private blockchain, and consortium
blockchain. Public blockchain is designed to enable and to record the
transactions in a public network, which means that any node can freely join or
leave the blockchain network without authorization. Bitcoin, the most famous
digital cryptocurrency, is generated and managed by a public blockchain.
Consortium blockchain is a permissioned blockchain, which is open to
authorized members of external institutions in limited roles and functions.
The authorization of the node to join are all determined by an authorized
organization. The nodes in a private blockchain network trust each other.
Thus, private chains can simplify operations in data authentication and the
consensus algorithm to improve the efficiency.

###  II-B Smart Contract

In the 1990s, Nick Szabo first proposed the concept of smart contracts[17]. It
was defined as computerized transaction protocols that execute terms of a
contract. In the field of cryptocurrency, a smart contract is defined as an
application or a program that runs on a blockchain. Normally, it contains a
set of digital agreements with specific rules. These rules are predefined in
the form of computer source codes, and all network nodes will copy and execute
these computer source codes independently. Smart contracts are highly
customizable and can be flexibly designed to provide different services and
solutions.

###  II-C Ring Signature

Ring signatures were first introduced in 2001[18] which follow a ring-like
structure of the signature algorithm. It is a type of digital signature that
can be performed by any member of a group of users without the agreement of
others. Therefore, the only “open” information is that a message signed with a
ring signature is endorsed by someone in a particular group of people. Ring
signatures are deliberately designed so that it is computationally infeasible
to determine which of the group members’ keys was used to produce the
signature. Ring signatures are similar to group signatures but differ in two
key ways: firstly, there is no group administrator to revoke the anonymity of
an individual signature; secondly, any set of users can be used as a group by
the signer without additional setup.

##  III Related work

Blockchain was first proposed as a secure decentralized ledger for recording
spectrum transaction data and analyzing overall spectrum usage in dynamic
spectrum management. In [19], the authors proposed to use the blockchain as a
distributed database to securely store the transactions in dynamic spectrum
sharing, and to use the digital currency issued by the blockchain as the
currency for spectrum auctions. In [15], a smart contract running on Ethereum
was proposed as a platform to provide spectrum sensing services.

In [13], a blockchain-based spectrum trading and sharing scheme was proposed
for Mobile Network Operators (MNOs) to lease their spectrum to secondary
Unmanned Aerial Vehicle (UAV). In [20], spectrum sharing contracts deployed on
a permissioned blockchain platform are constructed for multi-operators
spectrum trading. In [14], the authors proposeds to use the smart contract to
securely store and then autonomously implement the spectrum leasing
agreements, thus to avoid the interference from the disordered spectrum
access.

However, these works did not make any improvement to the existing blockchain.
Thus, the TPS of the blockchain is low, limiting the performance of the
blockchain-based DSA platform. Thus,

in [21], the authors proposed a consensus algorithm named as "blockchain-KM
protocol" by modifying the PoW, to speed up the transaction processing for the
license-free spectrum sharing. In [22], a novel consensus algorithm named as
proof-of-strategy was proposed, where the best strategy to allocate the
spectrum bands in the whole network is the proof of authority to publish a new
block. Such a consensus algorithm can not only regulate the transaction
generation, but also optimize the spectrum allocation.

In [23], by modifying the PoW, the authors proposed a consensus algorithm
named as Proof-of-Device, which selects a device, represented by its unique
identifier, to publish a new block in a way like lottery. It thus eliminates
the heavy computation cost in PoW.

On the other hand, blockchain system is an open system, hence the reliability
of data source needs to be guaranteed. In [24], the data uploaded by the
sensors are compared with the data collected by the trustworthy validator to
determine the credibility degree of the sensor, in this way, the system can
evaluate the credibility of nodes for better performance. However, this method
is a semi-centralized method which needs to deploy trustworthy validators.

Different from the above works, we not only delve into the design of block
structure and consensus algorithm, intending to overcome the scalability
problem of the blockchain technology, but also design a decentralized trust
evaluation mechanism and a privacy protection mechanism for the openness and
transparency of blockchain system while protecting the data’s confidentiality
and the sensors’ privacy. To the best of our knowledge, this is the first work
of joint trust evaluation and privacy protection mechanism in cooperative
sensing in a blockchain-enabled DSA system.

##  IV System Model, challenges and design guidelines

In this section, we introduce the dynamic spectrum sharing scenario in the
future IoT network, and list the difficulties and challenges in applying the
blockchain to this scenario. Finally, we give the guidelines on how to design
a blockchain-based DSA system.

###  IV-A Blockchain-enabled DSA System Model

In this paper, we consider the DSA in a two-tier cognitive radio network
consisting of licensed/primary users (PUs) and unlicensed/secondary users
(SUs). In this network, PUs are inactive users who may not use their spectrum
all the time so SUs can detect these spectrum holes and use them. As
illustrated in Fig.2, SUs can be a variety of heterogeneous IoT devices, which
form a mesh network. SUs access the spectrum bands of a PU in an opportunistic
manner based on cooperative sensing, and a blockchain is used as the platform
of the cooperative spectrum sensing decision and the spectrum allocation.

Figure 1: System model

Basically, as shown in Fig. 3, there are four phases in our blockchain-enabled
DSA system.

  1. 1.

Individual Sensing: The sensors perform spectrum sensing to detect the state
of the PU’s spectrum band.

  2. 2.

Sensing Fusion: Each of the sensor broadcasts its sensing data which mainly
consists of the sensing result and the geolocation where the sensing is
performed. These data can be raw data or quantized bits, which will be fed to
a smart contract implemented upon a blockchain. Then, the smart contract
provides the final sensing result according to predefined fusion rules.

  3. 3.

Spectrum Allocation: When the final sensing result indicates that PU is
inactive, it should be decided which spectrum requester can access the
spectrum. Spectrum auction, as a common and fair way for spectrum allocation,
is chosen to achieve that. In the spectrum auction, the digital
cryptocurrency, which is issued by the blockchain through incentive mechanisms
for spectrum sensing and mining, is commonly considered.

  4. 4.

Spectrum Access: The SU who obtains the access right through spectrum auction
accesses the idle spectrum for data transmission.

Compared with traditional cooperative spectrum sensing and spectrum allocation
methods, blockchain-enabled DSA has the following benefits:

  * •

Decentralized: Blockchain-based dynamic spectrum access does not require the
deployment of trusted central nodes which avoids the single point of failure.

  * •

Transparency: The blockchain ledger can record the whole process of DSA.

  * •

Automatic: Using smart contract instead of traditional contracts, we can
achieve automatic spectrum management and on-chain payment settlement.

  * •

Flexibility: For spectrum trading on the blockchain platform, diversified
spectrum trading rules can be dynamically enforced by adjusting parameters of
smart contracts. Compared with the current fixed paper-based contracts signed
between mobile users and operators, this method has higher flexibility.

Figure 2: Blockchain based DSA

###  IV-B Difficulties and Challenges

Traditional cooperative spectrum sensing is divided into two modes:
centralized mode and distributed mode. Centralized collaborative spectrum
sensing requires the deployment of a central fusion node to process the data
collected from sensors which usually contain sensors’ geolocation information.
Therefore, this mode not only requires redundant regulation fees (usually
charged to maintain the operation of the central node), but also faces the
risk of data leakage when the central node is attacked. While the distributed
mode often suffers from the fake reporting issue caused by malicious nodes and
the iterative-based malicious node detection algorithms [25] introduce extra
computation cost.

Therefore, how to implement the cooperative sensing in a secure and effective
way is a challenge. The decentralized nature of the blockchain system is
promising to realize distributed cooperative sensing and encourage all sensors
to share spectrum sensing results. However, there are still some challenges
when applying blockchain into spectrum management. Firstly, IoT devices
usually lack sufficient computing and storage resources to maintain and store
the whole blockchain ledger. Secondly, a malicious node can easily join a
public blockchain network and threaten the reliability of the cooperative
spectrum sensing. Moreover, the sensing-related data recorded on blockchain or
collected by smart contracts is usually in an unencrypted format which may
leak the private information of IoT devices contained in their sensing data
packets.

###  IV-C Design Guidelines

Considering above challenges, our discussion on system design mainly includes
the following four parts.

  * •

_Trust Evaluation_ : Specially, in a public blockchain network, anyone can
join or exit the system at will, and one user can create multiple accounts in
the system. Therefore, if there is no suitable node evaluation mechanism,
malicious users can launch sybil attacks easily. This is because, malicious
nodes can keep on applying for accounts and continue launching attacks.
Therefore, the system should be able to evaluate the trust values for nodes,
and identity the malicious nodes based on the their trust values.

  * •

_Lightweight Consensus Algorithm_ : Due to the limitation of the computing
power and storage resources of IoT devices, maintaining a normal public
blockchain system is a heavy burden. To reduce the computing cost, it is
necessary to invent a new consensus algorithm with low computational and
storage complexity.

On the other hand, as time goes by, the length of the ledger keeps on
increasing, resulting in increased node storage. To reduce the storage cost,
methods such as edge storage can alleviate storage pressure on the blockchain
nodes but may introduce additional budget. Thus, a method that can directly
reduce the storage cost of the blockchain is preferred.

  * •

_Privacy Protection Mechanism_ : Smart contracts does not have public-and-
private key pair and thus can not communicate with external accounts in an
encrypted manner. Therefore, when a smart contract is used as the data fusion
center of cooperative spectrum sensing, a privacy protection mechanism is
needed to ensure that the private information of the sensors will not be
leaked during the interaction between sensors and the smart contract.

##  V Blockchain Design, Trust Evaluation and Privacy Protection

In this section, to improve the accuracy of cooperative sensing, we first
introduce the block structure of our blockchain. We then propose the trust
evaluation mechanism to evaluate the trustworthiness of each SU on spectrum
sensing. After that, a high-efficiency consensus algorithm is proposed for our
blockchain. Finally, a privacy protection mechanism is proposed for protecting
participants’ privacy.

TABLE I: List of notations  Notations | Descriptions
---|---
$N_{i,w}(n)$ |  Accumulated number of wrong sensing results of $sensor_{i}$ at round $n$
$N_{i,r}(n)$ |  Accumulated number of right sensing results of $sensor_{i}$ at round $n$
$P$ |  Length of window for calculating $N_{i,w}(n)$
$\mathcal{D}^{i}_{n}$ |  Mining difficulty of node $i$ at block $n$
$\mathcal{H(\cdot)}$ | Hash operation
$R_{sleep}$ | Number of inactive rounds since last active round
$RND_{i}$ |  Random number picked by $sensor_{i}$
$SR$ | Sensing result of unknown but legal sensors
$SR_{i}$ |  Sensing result of $sensor_{i}$
$N_{1}$ |  Number of required sensors in Cooperative Sensing Contract ($CSC$)
$N_{2}$ |  Number of required bidders in Spectrum Auction Contract ($SAC$)
$TV_{thr}$ |  Trust value threshold set in $CSC$
$T_{ddl}$ |  Sensing deadline in $SAC$
$d_{s}$ | Deposit for sensing
$d_{a}$ | Deposit for auction
$T_{self-d}$ |  Time for $SAC$ to self-destruct
$TS$ | Timestamp
$loc$ | Location of unknown but legal sensors

###  V-A Block Structure

The block structure should be tailor-designed for the blockchain-based DSA
system. Some of the unnecessary components in the block header can be removed
to reduce the overheads on the block transmission and storage and other
necessary information, such as the trust value of the block generator, needs
to be recorded in the block header to prevent possible attacks in the DSA
system.

  * •

Block header: As shown in Fig. 3, The block header mainly contains (i) the
merkle root of transactions; (ii) the merkle root of account states; (iii) the
hash value of the header of the previous block, as the hash pointer of the
chain structure; (iv) the trust value of the miner who mines this block; (v)
the signature of the miner who mines this block; (vi) a Nonce, which is the
solution of Hash puzzle of the consensus algorithm; (vii) the timestamp when
the block is mined.

  * •

Block body: The block body mainly stores transaction generated during spectrum
allocation using merkle tree. Unlike the unspent transaction output (UTXO)
[26] model used in Bitcoin, the system based on the account model usually
contains an account tree to record the account states such as the balance and
the trust value of each account. Merkle Patricia Trie (MPT) [27] which is a
commonly adopted data structure, is used here to store the account states.

Figure 3: Block structure

###  V-B Trust Evaluation Mechanism

Although the blockchain can guarantee that the data recorded in a block will
not be tampered, it cannot guarantee that the data source is trustworthy.
Especially, in a public blockchain, a malicious node can upload misleading
data which may interfere the cooperation sensing based on such data. In such
cases, the performance of the cooperative sensing will be degraded, and the
honest and reliable sensors will be discouraged from participating in
cooperative sensing. To this end, we design a trust evaluation mechanism to
evaluate the credibility of every sensing node in the blockchain. Instead of
using a central authority to record and maintain every account’s trust value,
we propose to include the trust value as an attribute of the blockchain
account, which is recorded in the block and maintained by all the miners. In
the following, we will discuss the design of trust value updating method.

Intuitively, the trust value of a sensing node should be adjusted based on its
performance on the current and historical cooperative sensing. In detail, if
it plays a positive role in the cooperative sensing, its trust value should be
increased, and vice versa. Here, we define that the effect of a sensor is
positive when its sensing result is consistent with the cooperative sensing
result, and is negative when its sensing result is inconsistent with the
cooperative sensing result, or when the sensing node does not participate in
the cooperative sensing. Denote the number of times when the sensing result of
the i-th node is consistent with the cooperative sensing result as $N_{i,r}$;
the number of times when the sensing result of a node is inconsistent with the
cooperative sensing result as $N_{i,w}$. Inspired by [28], we propose a new
model to calculate trust value of $sensor_{i}$ denoted by $TV_{i}^{(1)}(n)$ in
sensing round $n$, where $n$ is also the number of sensing tasks published
since this system was created.

$\displaystyle TV_{i}^{(1)}(n)=e^{-\rho N_{i,w}(n)}\left(1-e^{-\eta
N_{i,r}(n)}\right),$ (1)

where $\rho>0$ and $\eta>0$ are coefficient that determine how fast the trust
value changes with respect to $N_{i,w}$ and $N_{i,r}$ , respectively.

Moreover, we let $N_{i,w}(n)$ decay by $\frac{1}{P}$ every time when the node
participates in sensing, and we only consider the latest $P$ sensing rounds of
each node. In this way, the effect of a wrong sensing result on the trust
value will gradually be degraded over time. As a result, a node that
unintentionally submitting an inconsistent result will be gradually forgotten.
Mathematically, $N_{i,w}(n)$ can be defined as

$N_{i,w}(n)=\sum\limits_{m=n-P}^{n}r_{i}(m)\left(1-\frac{n-m}{P}\right),$ (2)

where $r_{i}(m)=1$ if $sensor_{i}$ broadcasts the wrong sensing result in
round $m$, and $r_{i}(m)=0$ otherwise.

Besides, we denote the number of rounds when a sensing node is inactive as
$R_{sleep}$, and we add a function $f(R_{sleep})$ which models the negative
impact of being inactive on the trust value. It is designed to satisfy the
following criteria.

  * •

${\forall}R_{sleep}\in[1,+\infty)$, $f(R_{sleep})\in(0,1]$,

  * •

$\frac{\partial f_{dcv}}{\partial R_{sleep}}<0$,

The first criterion is for normalization; the second criterion is to ensure
that the negative effect increases as $R_{sleep}$ increases. Moreover, as
$R_{sleep}$ increases, the downward trend of the function is first gentle, and
then becomes severe. This is designed to punish the peers that does not
participate in the sensing process. The punishment is light when the peer does
not participate only a few times, but becomes severe when the node always does
not participate in the sensing. $f(R_{sleep})$ will reach a certain low value
when $R_{sleep}$ is big enough. For example, the trust value of a node will
reduce to $r_{1}$ ($r_{1}<1$) of its original value for $k_{1}$ consecutive
non-participation, and to $r_{2}$ ($r_{2}<r_{1}<1$) for $k_{2}$ consecutive
non-participation. Here, a piecewise function consisting of multiple linear
functions is utilized as our $f(R_{sleep})$.

$f(R_{sleep})=\left\\{\begin{array}[]{lcl}\frac{k_{1}-R_{sleep}}{k_{1}}\cdot(1-r_{1})+r_{1}&&{0\leq
R_{sleep}\leq k_{1}}\\\ \\\
\frac{R_{sleep}-k_{2}}{k_{1}-k_{2}}\cdot(r_{1}-r_{2})+r_{2}&&{k_{1}\leq
R_{sleep}\leq k_{2}}\\\ \\\ r_{2}&&{k_{2}<R_{sleep}}\\\ \end{array}\right.$
(3)

These parameters can be set flexibly. If the actual deployment requires
stricter penalties, then all these parameters should be set smaller.

By adding the attenuation function, the model in (1) can be modified as:

$TV^{(2)}_{i}(n)=\begin{cases}TV_{i}^{(2)}(n-1)+\Delta TV_{i}\cdot
f(R_{sleep}),&\mbox{if $\Delta TV_{i}>0$}\\\ \\\ TV_{i}^{(1)}(n),&\mbox{if
$\Delta TV_{i}<0$}\\\ \\\ TV_{i}^{(2)}(n-1)\cdot f(R_{sleep}),&\mbox{if
inactive}\end{cases}$ (4)

where $\Delta TV_{i}$ = $TV_{i}^{(1)}(n)-TV_{i}^{(2)}(n-1)$ is defined as the
original increment of trust value, which can be either positive or negative.
The design criterion of (4) is explained as follows. We consider three cases.
First of all, when the sensor senses correctly, the original increment of
trust value is positive, i.e., $\Delta TV_{i}>0$. Such increment is first
degraded by the negative effect of sleeps in the previous sensing activities,
i.e., $f(R_{sleep})$, and then added to the trust value. Secondly, when the
sensor gives the wrong sensing result, the original increment of trust value
is negative, i.e., $\Delta TV_{i}<0$. In this case, we choose not to consider
the negative effect of the sleep in previous sensing rounds, in order to
encourage the sensors which unintentionally derive the wrong sensing result in
this time. Finally, for sensors who do not participate in sensing, their trust
value will not remain unchanged but gradually decrease as their sleep time
increases. This design is to ensure that sensors can only maintain its high
trust value by actively participating in spectrum sensing.

###  V-C Consensus Algorithm, Forking and Block Compression

Based on the last block of the block chain, nodes in the blockchain network
will compete for publishing the next block, and only one block will be
accepted as the next valid block.

The traditional consensus algorithm for public blockchain like PoW is
computation-intensive, which may be inapplicable in IoT networks, where IoT
nodes are usually with limited computational capabilities. One reason why the
PoW is designed to be computation-insensitive is that it assumes there is
nearly no trust among nodes in a blockchain network. Nevertheless, with the
trust value mechanism proposed in this paper, we can evaluate the credibility
of a node on spectrum sensing in the blockchain network. Therefore, based on
the trust value, we can optimize our design of the blockchain consensus
algorithm, forking solution and blockchain compression.

Consensus Algorithm: Intuitively, the nodes with higher trust value on sensing
are more likely to be honest in publishing a new block. Therefore, we can
reduce the difficulty of such nodes to mine a new block. In this way, the
computation consumption for reliable nodes will be decreased, and a block will
thus be more quickly mined and published.

Based on PoW and trust value, we propose a Proof of Trust (PoT) consensus
algorithm. Similar to the Proof-of-Stake (PoS), PoT assigns different nodes
different mining difficulties. To be specific, for successful mining, the
miner with the higher trust value is required to find a hash value with fewer
leading zeros and vice versa.

Mathematically, assuming that the difficulty of node $i$ at block $n$ is
denoted as $\mathcal{D}^{i}_{n}$, which can be denoted as

$\mathcal{D}^{i}_{n}=\beta_{n}\cdot\left(1-sin\left(\frac{\pi}{2}\cdot
TV_{i}\right)\right),$ (5)

where $\beta_{n}$ denotes the base difficulty of block $n$. $TV_{i}$ is the
trust value of node $i$. The initial difficulty is denoted as $\beta_{0}$.
$\beta_{0}$ can be determined by evaluating the computing power of actual IoT
devices. We will discuss this problem in the simulation section. A node with
$TV_{i}=0.8$ has about $0.049\cdot\beta_{n}$ difficulty, which is 17 times
less than a node with $TV_{i}=0.1$ whose difficulty is about
$0.844\cdot\beta_{n}$.

We denote the timestamp of block $n$ as $T_{n}$, the ideal time interval of
two consecutive blocks is $T_{0}$. Then,we have

$q=\left\lfloor\frac{T_{n-1}-T_{n-2}}{T_{0}}\right\rfloor,$ (6)

where $q$ is defined as adaptive adjustment factor of base difficulty, and $g$
is defined as the difficulty adjustment granularity, which can be written as

$g=\left\lfloor\frac{\beta_{n-1}}{128}\right\rfloor,$ (7)

The updating of $\beta_{n}$ can be denoted as

$\beta_{n}=\beta_{n-1}-q\cdot g,$ (8)

Forking Solution: As the mining speed increases, there may be multiple blocks
mined at nearly the same time. Because of the communication latency, the block
that is first mined might not be the first to be received by all the nodes in
the blockchain network. Instead, the block that is first received and
recognized by different nodes might be different. In this case, the blockchain
forking occurs. It is harmful and thus needs to be solved. In Algorithm 1, we
propose a trust value based forking solution. It first compares the trust
values in the head of blocks, and it then validates the block with the highest
trust value. If the trust values of multiple blocks are the same, the block
whose timestamp is earlier is selected as the valid block. If the timestamp is
the same, it compares the hash value of the blocks, and then selects the block
with the smallest hash value as the valid block. Since the probability of hash
collision is negligible, Algorithm 1 can select one valid block eventually.

Blockchain Compression: Since IoT devices are usually with limited storage
space, each time when the blockchain grows by $L$ blocks, compression will be
performed. For the compression of blockchain, in the existing literature, the
RSA accumulator as a data structure, which functions similarly to that of a
Merkle tree, can be used to compress the blockchain [29]. Another approach to
compress blockchain is to use the chameleon hash function to replace the
traditional hash function of the blockchain [30]. Here, using the trust value,
we propose a compression method called as Trust-based Compression (TBC). The
node with the highest current trust value will be authorized to compress the
blockchain. To be specific, such a node will first extract the account tree in
the last block as the body of the new block, calculate a hash value for the
body, and finally combine the obtained nonce, miner’s signature, and timestamp
to form the block header. The obtained block is the new genesis block. Since
each node stores the original blockchain, it is easy to check whether the
account status has been tampered by the selected node during the compression
process. After a node verifies the new genius block, it will clear the
original blockchain.

Algorithm 1 Block Selection

Input: the block to be compared: $Block_{i}$, $Block_{j}$;
Output: The winner block;

if $TV_{i}<TV_{j}$ then

$Block_{i}$ wins.

else if $TV_{i}>TV_{j}$ then

$Block_{j}$ wins.

else

if $Timestamp_{i}<Timestamp_{j}$ then

$Block_{i}$ wins.

else if $Timestamp_{i}>Timestamp_{j}$ then

$Block_{j}$ wins.

else

if $\mathcal{H}(Block_{i})<\mathcal{H}(Block_{j})$ then

$Block_{i}$ wins.

else

$Block_{j}$ wins.

end if

end if

end if

###  V-D Privacy Protection Mechanism

The location where a sensing node senses the spectrum bands of interest is
useful for the fusion centre to cluster the sensing nodes and to improve the
cooperative sensing accuracy [31]. Therefore, alongside the sensing result,
the location is needed to be uploaded by a sensing node. However, it is
difficult to protect the location information of a sensing node from being
leaked when a smart contract is used as the fusion centre. This is because a
smart contract account is not equipped with a key pair which can be used by
sensors to encrypt their upload data packet.

The privacy protection issue in this case is to hide the source of a sensing
packet, i.e., from which sensing node the sensing packet comes. However, the
sensing node cannot be allowed to be totally anonymous when submitting the
sensing packet because this will make the cooperative sensing system
vulnerable to malicious attacks. To this end, we propose the use of the ring
signature [18] by each sensing node to hide the source of a sensing packet in
a group of valid sensing nodes. Also, the smart contract as the fusion centre
can identify the validity of each received sensing packet. Moreover, since
sensing packets are unencrypted, fusing these sensing results can be carried
out directly and automatically in the smart contract.

In the following, we illustrate the procedures of one sensor, denoted by
$Sensor_{s}$, in generating the ring signature.

  * 1.

$Sensor_{s}$ selects $n-1$ legal sensors to form a group and collect their
public keys. The format of a sensing data packet, denoted as msg, is given as
follows

$msg=\\{\mathcal{H}(msgID),SR,time,location\\},$ (9)

where $\mathcal{H}(msgID)$ is used in the update of the trust value and $SR$
is the sensing result denoted by one bit.

  * 2.

$Sensor_{s}$ uses one-way hash function to compute $k=\mathcal{H}(msg)$, which
is a symmetric key of the symmetric encryption function $E_{k}$.

  * 3.

$Sensor_{s}$ generates a random value for each of other members in the group
where it belongs to. Specifically, the random number $x_{i}$ is first
generated for the $i$-th node in the group. It then calculates corresponding
$y_{i}$=$g_{i}(x_{i})$ using corresponding public key, where the function
$g_{i}(\cdot)$ is the encryption function encrypted with the public key
$pk_{i}$.

  * 4.

$Sensor_{s}$ finds the solution to the ring equation (10) and gets the
undetermined parameter $y_{s}$, where $v$ is a random value chosen by
$Sensor_{s}$. Then, $Sensor_{s}$ calculates $x_{s}$ using its own privacy key:
$x_{s}$=$g_{s}^{-1}(y_{s})$. To find solution, a private key of a sensor in
this group is needed , anyone who is not in the group cannot generate a legal
ring signature.

$\begin{split}C_{k,v}(y_{1},y_{2},...,y_{n})&=E_{k}(y_{n}\oplus
E_{k}(y_{n-1}\oplus E_{k}(...\\\ &\oplus E_{k}(y_{1}\oplus
v)...)))=v,\end{split}$ (10)

Finally, a valid ring signature, denoted as $Ring_{sig}$, can be generated by
$Sensor_{s}$.

$Ring_{sig}=(pk_{1},pk_{2},...,pk_{n},v,x_{1},x_{2},...,x_{n}),$ (11)

The signature verification by the smart contract as the fusion centre involves
the following three steps.

  * 1.

Calculate all $y_{i}$ using corresponding public key $pk_{i}$ and $x_{i}$;

  * 2.

Calculate the symmetric key $k=\mathcal{H}(msg)$;

  * 3.

Verify that if $C_{k,v}(y_{1},y_{2},...,y_{n})=v$ holds.

If the verification succeeds, the smart contract recognizes that $msg$ is sent
by a valid sensing node from the group
$\\{Sensor_{1},Sensor_{2},...,Sensor_{n}\\}$. In this way, we can cut the
connection between the data packet and its corresponding owner.

However, for the trust value update and payments assignment process, it is
necessary to know the mapping of the sensing result and its corresponding
sensor. To this end, we propose a two stage commitment scheme as follows.

This scheme consists of two stages including Commit Stage and Reveal Stage. As
shown in Fig. 4, at the commit stage, each sensor participating in the
cooperative sensing needs to submit the $msg$ whose privacy is protected by
the ring signature, and the field “hash of $msgID$”, i.e.
$\mathcal{H}(msgID)$, is used as a commitment. $msgID$ is an identifier which
is the input of hash function, and can be any message such as "I am User 3" or
"I like apples". At the reveal stage, each sensor directly uploads the
unhashed $msgID$ for miners to verify the consistency. This checking mechanism
is effective since hash function is preimage resistance and second-preimage
resistance [32], i.e., given a hash output $\mathcal{R}$=$\mathcal{H}(msgID)$,
it is difficulty to find the input $msgID$ or another input $msgID^{\prime}$
such that $\mathcal{H}(msgID)$ = $\mathcal{R}$ or
$\mathcal{H}(msgID^{\prime})=\mathcal{R}$.

Figure 4: Two-Stage commitment scheme.

##  VI Smart Contracts and DSA Protocol Design

Smart contracts are computer codes that run on the blockchain platform, which
are automatically executed when the predefined conditions are satisfied.
Moreover, smart contracts are not controlled by any third party. Therefore, we
propose to use smart contracts to realize the automated operation of
cooperative spectrum sensing and spectrum auction on blockchain. In this
section, we will give the designs of the corresponding smart contracts, and
then propose the DSA protocol based on these smart contracts.

###  VI-A Smart Contract Design

We first discuss the design of our smart contracts for cooperative sensing and
spectrum auction. In the following, we describe the parameters and functions
in the two smart contracts, respectively.

_Cooperative Sensing Contract (CSC)_ : The parameters in CSC that need to be
predefined are $T_{ddl}$, $d_{s}$, $N_{1}$ and $TV_{thr}$, which are
introduced as follows.

  * •

$T_{ddl}$: The deadline for a sensor to send its sensing packet to CSC;

  * •

$d_{s}$: The deposit that a sensor needs to pay before participating in
sensing, which is used to be a guarantee for acting honestly. The deposit can
be withdrawn only if the sensor uploads the sensing result which is consistent
to the cooperative sensing result..

  * •

$N_{1}$: The maximum number of sensors needed in cooperative sensing. If there
are more than $N_{1}$ sensors who apply to participate in cooperative sensing,
those with $N_{1}$ highest trust value will be selected.

  * •

$TV_{thr}$: the minimum trust value of a sensor is needed to participate in
cooperative sensing.

The functions in CSC are introduced as follows.

  * •

$SensorRegister(\cdot)$: The inputs to this function are address $Addr$,
deposit $dpt$ and trust value $TV$ of the node who invokes this function. This
function will decide whether this node can register successfully by checking
its trust value.

  * •

$CheckRegisterQuality(\cdot)$: This function is used to check node’s quality
of participating in sensing by checking the parameters passed into it, i.e.,
node’s trust value $TV_{i}$ and deposit $deposit_{i}$. For new users,
participating in sensing is the only way to improve their trust value. This
function offers users a way to convert their tokens to additional trust value,
which enables the users whose trust value is below threshold to participate in
sensing by paying more deposit.

  * •

$Fusion(\cdot)$: The input to this function is $msgList$, which is a list
consisting of all the sensing results from the registered sensors. This
function outputs the final sensing result according to the pre-defined fusion
rule.

  * •

$UploadSensingData(\cdot)$: The inputs to this function are $msg$ and $RSIG$ ,
which are the sensing packets in (9) and the ring signature of the node,
respectively. This function is invoked by legal sensors to upload their
sensing result.

The pseudocode of the CSC is summarized in Algorithm 2.

_Spectrum Auction Contract (SAC)_ : The parameters in SAC are as follows.

  * •

$CSC_{id}$: The identity of corresponding CSC, which is used to identify the
connection between SAC and CSC since every SAC is associated with a particular
CSC.

  * •

$N_{2}$: The maximum number of the bidders, which is used to prevent too many
nodes from sending bidding message.

  * •

$T_{self-d}$: The time when this SAC will conduct the self-destruct operation
to release memory.

  * •

$d_{a}$: The amount of tokens that the bidders need to deposit before the
final sensing result is released.

The functions in SAC are introduced as follows.

  * •

$BidderRegister(\cdot)$: Bidders invoke this function to register in SAC.

  * •

$Commit(\cdot)$: The input to this function is $bldBid$ which denotes the
commitment of $bidder_{i}$. Note that since the account balance is
transparent, nodes can identify others’ bid by checking their balance[33].
Therefore, everyone makes several commits in order to prevent others from
inferring your bid based on changes of their account balance.

  * •

$Reveal(\cdot)$: The inputs to this function include $Dps$, $Bools$ and
$RNDs$. $Dps$ is the list of deposit ($Dp$) the bidders make; $Bools$ is the
list of boolean values which indicate whether these bids are valid or not;
$RNDs$ are random values to make the hash of $\\{Dp$, $Bool$, $RND\\}$ hard to
guess. A $Commit$ is the hash of these three parameters, i.e., $Commit$=
$\mathcal{H}$$\\{$$Dp$, $Bool$, $RND\\}$. $bidsList[msg.sender]$ is the list
of the invoker’s commits. By comparing the reveal messages and the commits,
this function can identify which bids are revealed correctly. Valid bids are
added together as the bidder’s total bid, invalid but correctly revealed bids
are allowed to be withdrawn, bids that are not correctly revealed will not be
returned.

  * •

$Win(\cdot)$: The input to this function is $bidderList$, which is the list of
all valid bids. Here we adopt the second-price sealed-bid auction for better
economic profit [34]. Accordingly, this function selects the bidder with the
highest bid as the winner, who only needs to pay the second highest bid.

  * •

$EndOfAuction(\cdot)$: SAC will execute self-destruct operation at the preset
time $T_{self-d}$.

The pseudocode of SAC is shown in Algorithm 3.

Algorithm 2 Cooperative Sensing Contract

1:function init($TV_{thr}$, $d_{s}$, $N_{1}$)

2: require(msg.sender==ContractOwner);

3: initialize $TV_{thr}$, $d_{s}$, $N_{1}$;

4:end function

5:

6:function SensorRegister($Addr,dpt,TV$)

7: $sensor_{num}\leftarrow 0$;

8: if checkRegisterQuality($TV_{i}$, $addr_{i}$) then

9: $sensorMap\leftarrow sensor_{i}$;

10: $sensor_{num}\leftarrow sensor_{num}+1$;

11: EMIT event("Registration success!");

12: else

13: EMIT event("Registration failed, please checkout the trust value and
deposit.");

14: end if

15: if $sensor_{num}>N_{1}$ then

16: Select top $N_{1}$ sensors according to trust value;

17: end if

18:end function

19:

20:function Fusion($msgList$)

21: Decision fusion in majority rule;

22: return Cooperative sensing result;

23:end function

24:

25:function checkRegisterQuality($TV_{i}$,$deposit_{i}$)

26: if $deposit_{i}>d_{s}$ then

27: $TV^{{}^{\prime}}_{i}$ $\leftarrow$ $convert(deposit_{i}-d_{s})$

28: if ($TV_{i}+TV^{{}^{\prime}}_{i})>TV_{thr}$ then

29: if $totalNum<N_{1}$ or $TV_{i}>lowestTV$ then

30: Register Successful;

31: end if

32: else

33: Register Failed;

34: end if

35: end if

36:end function

37:

38:function UploadSensingData($msg$, $RSIG$)

39: if $RSIG$ is legal then

40: $msgList\leftarrow msg$;

41: EMIT event("Upload successfully!");

42: else

43: EMIT event("Upload failed, illegal sensor!");

44: end if

45:end function

Algorithm 3 Sealed Spectrum Auction Contract

1:$Bid\leftarrow{bldBid_{i},msg.value}$;

2:$bidsList\leftarrow mapping(address=>Bid[])$;

3:$refund\leftarrow 0$

4:

5:function Commit($bldBid$)

6: $bidsList[msg.sender].push(bldBid);$

7:end function

8:

9:function Reveal($Dps,Bools,RNDs$)

10: $len\leftarrow bidsList[msg.sender].length$;

11: while $len>0$ do

12: $Commit\leftarrow\mathcal{H}\\{Dps[len],Bools[len],RNDs[len]\\}$;

13: if $Commit!=bidsList[msg.sender][len]$ then

14: EMIT event("Illegal Reveal!");

15: Continue;

16: else if $Commit==bidsList[msg.sender][len]$ and $Bools[len]==true$ then

17: $refund\leftarrow refund+Dps[len]$;

18: else if $Commit==bidsList[msg.sender][len]$ and $Bools[len]==false$ then

19: withdraw invalid but reveal correctly bid;

20: end if

21: $len\leftarrow len-1$;

22: end while

23:end function

24:

25:function Win($bidderList$)

26: return Bidder with the highest bid;

27:end function

28:

29:function EndofAuction($T_{self-d}$)

30: Execute self-destruct operation;

31:end function

###  VI-B The DSA Protocol

In this part, we illustrate our proposed blockchain-based DSA protocol. To
make it clearer, we elaborate this protocol in Fig. 5.

  * •

Phase 1 (_Spectrum Sensing Request_): To ask for the channel state, SUs need
to send a request message to Task Issuer (TI) through the control channel. TI
is played by the node whose trust value is currently the highest. The role of
TI is set to prevent multiple contracts from appearing in the network, which
results in users participate in different contracts. TI will then creates and
deploys the CSC and the corresponding SAC in the blockchain.

  * •

Phase 2 (_Smart Contracts and Nodes Register_): The CSC and SAC are
instantiated when TI issues the transaction

$CSC=\\{CSC_{id}\mid T_{ddl}\mid N_{1}\mid TV_{thr}\mid Fusion(\cdot)\mid
d_{s}\\}$ (12)

with the signature $Sig_{TI}(STC)$, and the transaction

$SAC=\\{CSC_{id}\mid SAC_{id}\mid N_{2}\mid T_{self-d}\mid Win(\cdot)\mid
d_{a}\\}$ (13)

with the signature $Sig_{TI}$=$(AC)$. To register to CSC, a sensor issues the
transaction

$Deposit_{CSC_{id}}=\\{pk_{i}\mid TV_{i}\mid CSC_{id}\mid d_{s}\\}$ (14)

with the signature $Sig_{sk_{i}}(Deposit_{CSC_{id}})$ to make deposits.
Similarly, a SU who intends to participate in SAC makes its deposit by issuing

$Bty_{SAC_{id}}=\\{pk_{i}\mid TV_{i}\mid SAC_{id}\mid
d_{a}\mid\mathcal{H}(bid_{i},RND_{i})\\}$ (15)

with the signature $Sig_{sk_{i}}(Bty_{SAC_{id}})$. The
$\mathcal{H}(bid_{i},RND_{i})$ denotes the bidding commitment this SU makes
for the sealed auction.

  * •

Phase 3 (_Players selection_): Players (including sensors and bidder) are
selected based on $SensorRegister(\cdot)$ and $BidderRegister(\cdot)$,
respectively. Finally, an event will be triggered to provide an appropriate
notification to every eventually selected nodes.

  * •

Phase 4 (_Sensing phase_): Sensors upload the sensing data by issuing the
transaction

$msg_{tx}=\\{CSC_{id}\mid\mathcal{H}(msgID)\mid TS\mid SR\mid loc\\}$ (16)

with the ring signature generated by (11) before $T_{ddl}$, and $TS$ denotes
timestamp, $SR$ denotes the sensing result. In this process, we use the ring
signature to protect the SU’s identity. Meanwhile, these sensors need to make
commitments mentioned in Section V-D by sending the transaction

$Commit_{i}=\\{CSC_{id}\mid\mathcal{H}(SR,RND_{i},msgID)\mid pk_{i})\ $ (17)

with $Sig_{sk_{i}}(Commit_{i})$. After the sensing deadline, data fusion is
done, and the final sensing result will be published in the blockchain
network.

  * •

Phase 5 (_Auction if necessary_): If the cooperative sensing result indicates
that the corresponding spectrum bands are idle, the SAC will be invoked. Users
who have been selected will reveal their bids for the spectrum by sending bids
and random numbers. Then the winner will be published on the blockchain.

  * •

Phase 6 (_Trust value updating_): In this phase, the trust value of each node
is updated using equation (4) by miners in the network.

Figure 5: The workflow of our proposed blockchain-based DSA.

##  VII Implementation and Performance Analysis

###  VII-A Implementation of Smart Contract

We implement the proposed smart contracts using Solidity[16] in the Ethereum
Virtual Machine (EVM). The smart contracts are compiled and deployed in the
Remix IDE[35] which is used for testing. After that, the nodes in the
blockchain network can send transactions to deploy the smart contracts and
invoke functions in these contracts. In the cooperative sensing phase, five
sensors are considered and the information of their accounts in the blockchain
network are listed in table II. In the following, we describe the
implementation procedures in detail.

  1. 1.

_Smart Contract Preparation_ : The smart contract is created and deployed by
the node with the highest trust value, i.e., the fifth account in table II.
The relevant parameters and functions which need to be predefined are set as
follows: $N_{1}$ is set as 3, the trust value threshold $TV_{thr}$ is set as
900 where we magnify the trust values by 100 times and make they as integers,
since fixed point numbers are not fully supported by Solidity yet. $d_{s}$ is
set as 100 wei,

  2. 2.

_Smart Contract Deployment_ : Fig.6 shows the details about the deployed smart
contract. The field “from" is the account address of TI. The field “decoded
input" shows all of our preset parameters.

  3. 3.

_Sensor Registration_ : All the five sensors send their registration request
to the smart contract. Then, three sensors are selected by the function
$SensorRegister(\cdot)$.

  4. 4.

_Sensing Results Fusion_ : The function $Fusion(\cdot)$, where the majority
rule is selected, is used to fuse the sensing results from three legal
sensors.

If the spectrum is detected as idle, the auction phase initiates. In this
phase, we consider two bidders: each bidder has one true bid and one false
bid. The related information is listed in Table III. The first bidder has two
bids: one is a true bid with 100 wei, the other one is a false bid with 200
wei. The second bidder also has two bids: one is true with 150 wei, the other
is false with 300 wei.

TABLE II: Related information of sensor accounts

Account addresses | Trust value | Sensing Result
---|---|---
0x5B38Da6a701c568545dCfcB03FcB875f56beddC4 | 0.91 | 0
0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2 | 0.92 | 1
0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db | 0.87 | 1
0x78731D3Ca6b7E34aC0F824c42a7cC18A495cabaB | 0.93 | 0
0x5B38Da6a701c568545dCfcB03FcB875f56beddC4 | 0.94 | 1

Figure 6: Initialization of Smart Contract

  1. 1.

_Commit_ : Bidders invoke $Commit(\cdot)$ function to make commits. Fig. 7
shows the log of commit made by bidder 2. There are address information and
bid information about this commit, thus others can know that bidder 2 make a
bid with 150 wei, but they can not identify whether this is a real commit or
not.

  2. 2.

_Reveal_ : After the commit phase, bidders invoke the function $Reveal(\cdot)$
to reveal its commits. The field “decoded input” in Fig. 8 shows the whole
information about this commit. The smart contract will automatically verify
the information uploaded in the two phase and the final bidding result can be
accessed by all nodes in the system.

TABLE III: Related Information of Bidders

Bidder address | Bid | isReal | Commit
---|---|---|---
0xAb84…5835cb2 | 100wei | yes | 0x591a291ad67…1b62c96a2092
200wei | no | 0x4871a30b671…4d08cfaa8bc1
0x4B20…2C02db | 150wei | yes | 0x4e6a24e35c7be…23643d68efa
300wei | no | 0x0c98edecac…74d24d971ec88

Figure 7: The commit made by bidder 2

Figure 8: The reveal made by bidder 2.

###  VII-B Performance Analysis of The Proposed PoT Consensus Algorithm

In this part, we evaluate the performance of the proposed PoT consensus
algorithm. We first discuss how to set the initial mining difficulty at the
beginning when every node’s trust value is 0. We simulate the mining process
in our personal computer as a reference to explain how to select a suitable
mining difficulty. We use a given string to represent the transactions in a
block in the blockchain network. The result is shown in Fig. 9. The running
time increases exponentially when the number of leading zeros is larger than
20. Supposing that the hash rate of the IoT devices is similar to that of our
personal computer, the interval between two blocks $T_{0}$ is about 1 second,
then the mining difficulty should be less than 18 leading zeros, the
$\beta_{0}$ is about $2^{18}=262144$.

It’s worth mentioning that even under the same mining difficulty and
experimental environment, the mining time may be different. For example, given
the mining difficulty where 32 leading zeros are needed in the target hash, it
sometimes take tens of seconds, and sometimes can take more than an hour. In
order to eliminate the impact of luck, we convert the mining difficulty into
the expected mining cost and evaluate the expected mining cost instead of
running time. Theoretically, assuming that the output of each hash calculation
is unpredictable, each time when we increase the leading zero by one, the
success probability of each hash trial will be halved. The trust value is
associated with the mining difficulty. Therefore, we first convert the trust
value into the number of leading zeros, and then the number of leading zeros
is converted into the expected mining cost proportionally. Simulation is
conducted for 1000 time slots, and the average expected mining cost of every
type of nodes is calculated in Fig.11. To be specific, we simulate a network
with 20 nodes and 4 types of nodes are considered. Rnode means a node with
high performance and always act honestly; UAnode means a node with high
performance and act honestly, however it participates in sensing infrequently.
OOnode is a node who conducts malicious behavior periodically. We assume that
OOnode will act maliciously after every two normal sensing rounds. The Lnode
is a node who randomly provides binary sensing result without sensing. There
are 12 Rnode with probability of detection $p_{d}$ = 0.90 and probability of
false alarm $p_{f}$ = 0.15 [36]; 3 OOnode whose $p_{d}$ = 0.90 and $p_{f}$ =
0.15; 3 Lnode with $p_{d}$ = 0.5 and $p_{f}$ = 0.5; and 2 UAnode with $p_{d}$
= 0.90 and $p_{f}$ = 0.15. Besides, it is assumed that they only have a 50%
chance to sign up in CSS each sensing round.

In Fig.11, it can be observed that the reliable node performs best with
respect to the average expected mining cost per timeslot, which is about one
third of the other three types of nodes. The expected mining cost of a on-off
node is a little smaller than Lnode and UAnode but still cost three times than
Rnode. This proves the effectiveness of our proposed consensus algorithm.

Figure 9: Running time (second) with increasing number of leading zeros Figure
10: Curve of trust value Figure 11: Expected mining consumption of different
nodes

###  VII-C Performance of Cooperative Sensing

In this part, we evaluate the performance of cooperative spectrum sensing with
the help of our proposed trust evaluation mechanism. In traditional blockchain
network, there is no trust among nodes hence anyone can record the sensing
information into blockchain, including nodes with poor performance or
malicious behavior. However, due to the introduction of the trust value
mechanism, the cooperative sensing contract can exclude bad nodes according to
nodes’ trust value, thus the system’s sensing performance can be improved. For
comparison, we consider 3 kinds of selection schemes to select the candidate
nodes for the cooperative sensing. (i) random selection scheme; (ii) select
according to register time; (iii) select according to sensor’s trust value. We
simulate a 20 nodes network with the same setup in VII-B.

It can be seen from Fig.12 that when the number of needed sensors $N_{1}$ is
small, $p_{d}$ and $p_{f}$ of cooperative sensing in the first two schemes
which do not take advantage of trust value perform worse than that of the last
selection scheme. This indicates that our proposed trust value mechanism can
effectively improve the cooperative sensing performance of the system.
Moreover, in the last selection scheme, $p_{d}$ is close to $1$ when $N_{1}$
is about one fourth of all network nodes. The fewer nodes involved, the
smaller the total monetary reward that the network needs to pay to sensors,
and the smaller the economic burden for spectrum buyers. As $N_{1}$ grows, the
performance of different schemes will gradually close, since most of the
network nodes (including bad nodes) will participate in cooperative sensing.

(a) $P_{d}$ of cooperative sensing (b) $P_{f}$ of cooperative sensing

Figure 12: Performance of cooperative sensing under three selection schemes

###  VII-D Incentive Mechanism Analysis

Since both sensing and mining will consume SU’s computing power, an incentive
mechanism is needed to reward nodes for the work they have done. The users who
upload a sensing result that is consistent to the final cooperative sensing
result will be rewarded with $R_{s}$ tokens; The users who successfully mine
will be rewarded with $R_{m}$ tokens. The tokens can be used in auction to bid
for spectrum resources. In implementation, the tokens rewarded for accurate
spectrum sensing and successful mining, i.e., $R_{s}$ and $R_{m}$, need to be
designed based on the evaluation of the computation consumption of spectrum
sensing and mining.

This incentive mechanism not only encourages the nodes to participate in
spectrum sensing, but also encourage them to behave honestly and accurately in
spectrum sensing. This is because, on the one hand, an honest and accurate
sensing node is more likely to derive a sensing result that is consistent to
the final cooperative sensing result and obtain tokens rewarded for spectrum
sensing. On the other hand, with the proposed consensus algorithm, the node
with a higher trust value is easier to mine successfully so that they have a
higher probability of obtaining tokens for mining. On the contrary, the
dishonest nodes will be discouraged since they are less likely to obtain
rewards since they need to spend more computing resources on mining.

###  VII-E Security Analysis

  * •

_Distributed Denial of Service (DDoS) Attack_ : The DDoS attack here means
that malicious users try to make the sensing service unavailable to other
users. Our system is resist to this attack since we adopt the deposit
mechanism. Thus, under our scheme, the cost of launching large-scale DDoS
attack is very high since the attackers need to obtain lots of tokens in order
to launch the attack.

  * •

_Spoofing Attack_ : Spoofing attack means someone tries to masquerade others
to create forged transactions. Secure Elliptic Curve Digital Signature
Algorithm (ECDSA)[37] used in our blockchain can prevent this attack on the
premise that attack does not have the user’s private key.

  * •

_Free-riding Attack (lazy node)_ : The Free-riding attack here means lazy
users may directly copy others’ sensing results at the phase of uploading
sensing data. Firstly, there is no motivation for sensors to submit the
sensing result before sensing deadline. Thus, when the lazy nodes get the
sensing result, it is difficult for them to repack the sensing result and
submit before the deadline. Secondly, even if a few sensors submit sensing
results in advance, the connection between a user’s identity and sensing data
is cut by the ring signature, thus the lazy users cannot determine the owner
of the sensing data, and thus the credibility of the data cannot be
guaranteed. Thus, it is no better than submit a sensing result randomly.

  * •

_On-off Attack_ : On-off attack means that a node performs malicious behaviors
periodically. If a trust management mechanism satisfy the condition that the
dropping rate of trust value is larger than its increasing rate, it is
considered to be resist to the on-off attack [28]. However, the model in [28]
may cause the trust value drop a lot even the misbehavior is unintentional,
since the increasing rate is much smaller than dropping rate. In our proposed
model, as show in Fig.13, the unintentional mistakes made by sensors can be
compensated by making right sensing decision. When the parameters $\tau$ and
$\eta$ satisfy $\rho\textgreater\frac{\eta}{1-e^{-\eta}}-\eta$, our proposed
trust value management mechanism is considered to be resist to the on-off
attack, the proof is given in Appendix A.

(a) Existing model (b) Proposed model

Figure 13: Trust value of different types of nodes under two model

##  VIII Conclusion

In this paper, we have proposed a blockchain-based dynamic spectrum sharing
protocol. This protocol mainly consists of three parts: the first part is the
trust value management mechanism, which is designed to evaluate the
credibility of nodes; the second part is the PoT consensus algorithm, which
make the mining difficulty for malicious nodes greatly increased. The
combination of node’s trust value and their mining difficulty can motivate
nodes to be more willing to behave honestly; the third part is the privacy
protection mechanism, in which we combine the ring signature and the commit-
reveal scheme to solve the problem of privacy issue in the process of
cooperative spectrum sensing. Finally, we implemented the prototype of our
proposed smart contracts and analyzed the performance of PoT consensus
algorithm and the improvement in cooperative sensing. Security analysis of the
system show that our framework can resist many kinds of attacks which are
frequently encountered in trust-based blockchain systems.

##  Appendix A Proof of the resistance of on-off attack

######  Proposition 1.

The proposed trust model given in (1) is resistant to on–off attack when
$\rho\textgreater\frac{\eta}{1-e^{-\eta}}-\eta$.

###### Proof.

Let $f(N_{r},N_{w})=e^{-\rho\cdot N_{w}}\cdot\left(1-e^{-\eta\cdot
N_{r}}\right)$ denotes the trust value update function in (1). Because when
$N_{r}=0$, $f(N_{r},N_{w})$ can only increase, this situation is not discussed
here. At any other points $(N_{r},N_{w})$ in this function, the decreasing
rate should be larger than the increasing rate, that is:

$\left\lVert\frac{\partial f}{\partial
N_{w}}\right\rVert>\left\lVert\frac{\partial f}{\partial N_{r}}\right\rVert,$
(18)

where

$\left\lVert\frac{\partial f}{\partial N_{w}}\right\|=\rho\cdot e^{-\rho\cdot
N_{w}}\cdot\left(1-e^{-\eta\cdot N_{r}}\right)$ (19)

and

$\left\|\frac{\partial f}{\partial N_{r}}\right\|=\eta\cdot e^{-\rho\cdot
N_{w}}\cdot\left(e^{-\eta\cdot N_{r}}\right),$ (20)

then we have

$\left\|\frac{\partial f}{\partial N_{w}}\right\|>\left\|\frac{\partial
f}{\partial N_{r}}\right\|\Leftrightarrow\frac{\rho}{\eta}>\frac{e^{-\eta\cdot
N_{r}}}{1-e^{-\eta\cdot N_{r}}}$ (21)

which can also be denoted as:

$\left\|\frac{\partial f}{\partial N_{w}}\right\|>\left\|\frac{\partial
f}{\partial
N_{r}}\right\|\Leftrightarrow\frac{\rho}{\eta}>\frac{1}{1-e^{-\eta\cdot
N_{r}}}-1$ (22)

When $N_{r}\geq 1$,

$\frac{1}{1-e^{-\eta\cdot N_{r}}}-1\leq\frac{1}{1-e^{-\eta}}-1,$ (23)

Therefore, as long as it is satisfied
$\frac{\rho}{\eta}>\frac{1}{1-e^{-\eta}}-1$, the above inequality holds. ∎

## References

  * [1] G. Forecast, “Cisco visual networking index: global mobile data traffic forecast update, 2017–2022,” _Update_ , vol. 2017, p. 2022, 2019.
  * [2] P. Kolodzy and I. Avoidance, “Spectrum policy task force,” _Federal Commun. Comm., Washington, DC, Rep. ET Docket_ , vol. 40, no. 4, pp. 147–158, 2002\.
  * [3] I. F. Akyildiz, B. F. Lo, and R. Balakrishnan, “Cooperative spectrum sensing in cognitive radio networks: A survey,” _Phy. Commun._ , vol. 4, no. 1, pp. 40–62, 2011.
  * [4] J. Wang, M. Li, Y. He, H. Li, K. Xiao, and C. Wang, “A blockchain based privacy-preserving incentive mechanism in crowdsensing applications,” _IEEE Access_ , vol. 6, pp. 17 545–17 556, 2018.
  * [5] L. Xiao, Y. Ding, D. Jiang, J. Huang, D. Wang, J. Li, and H. Vincent Poor, “A reinforcement learning and blockchain-based trust mechanism for edge networks,” _IEEE Transactions on Communications_ , vol. 68, no. 9, pp. 5460–5470, 2020.
  * [6] G. Liu, H. Dong, Z. Yan, X. Zhou, and S. Shimizu, “B4SDC: A blockchain system for security data collection in MANETs,” _IEEE Transactions on Big Data_ , pp. 1–1, 2020.
  * [7] W. Feng and Z. Yan, “MCS-Chain: Decentralized and trustworthy mobile crowdsourcing based on blockchain,” _Future Generation Computer Systems_ , vol. 95, pp. 649–666, 2019.
  * [8] M. Li, J. Weng, A. Yang, W. Lu, Y. Zhang, L. Hou, J. Liu, Y. Xiang, and R. H. Deng, “CrowdBC: A blockchain-based decentralized framework for crowdsourcing,” _IEEE Transactions on Parallel and Distributed Systems_ , vol. 30, no. 6, pp. 1251–1266, 2019.
  * [9] M. Yang, T. Zhu, K. Liang, W. Zhou, and R. H. Deng, “A blockchain-based location privacy-preserving crowdsensing system,” _Future Generation Computer Systems_ , vol. 94, pp. 408 – 418, 2019. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0167739X18320909
  * [10] M. B. H. Weiss, K. Werbach, D. C. Sicker, and C. E. C. Bastidas, “On the application of blockchains to spectrum management,” _IEEE Transactions on Cognitive Communications and Networking_ , vol. 5, no. 2, pp. 193–205, 2019.
  * [11] E. D. Pascale, J. McMenamy, I. Macaluso, and L. Doyle, “Smart contract slas for dense small-cell-as-a-service,” _CoRR_ , vol. abs/1703.04502, 2017. [Online]. Available: http://arxiv.org/abs/1703.04502
  * [12] G. Qiao, S. Leng, H. Chai, A. Asadi, and Y. Zhang, “Blockchain empowered resource trading in mobile edge computing and networks,” in _ICC 2019 - 2019 IEEE International Conference on Communications (ICC)_ , 2019, pp. 1–6.
  * [13] J. Qiu, D. Grace, G. Ding, J. Yao, and Q. Wu, “Blockchain-based secure spectrum trading for unmanned-aerial-vehicle-assisted cellular networks: An operator’s perspective,” _IEEE Internet of Things Journal_ , vol. 7, no. 1, pp. 451–466, 2020.
  * [14] T. Ariyarathna, P. Harankahadeniya, S. Isthikar, N. Pathirana, H. M. N. D. Bandara, and A. Madanayake, “Dynamic spectrum access via smart contracts on blockchain,” in _2019 IEEE Wireless Communications and Networking Conference (WCNC)_ , 2019, pp. 1–6.
  * [15] S. Bayhan, A. Zubow, and A. Wolisz, “Spass: Spectrum sensing as a service via smart contracts,” in _2018 IEEE International Symposium on Dynamic Spectrum Access Networks (DySPAN)_ , 2018, pp. 1–10.
  * [16] Solidity webpage, https://docs.soliditylang.org/en/v0.7.5/.
  * [17] N. Szabo, “Formalizing and securing relationships on public networks,” _First Monday_ , vol. 2, no. 9, Sep. 1997. [Online]. Available: https://firstmonday.org/ojs/index.php/fm/article/view/548
  * [18] R. L. Rivest, A. Shamir, and Y. Tauman, “How to leak a secret,” in _Advances in Cryptology — ASIACRYPT 2001_ , C. Boyd, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 2001, pp. 552–565.
  * [19] K. Kotobi and S. G. Bilen, “Secure blockchains for dynamic spectrum access: A decentralized database in moving cognitive radio networks enhances security and user access,” _IEEE Vehicular Technology Magazine_ , vol. 13, no. 1, pp. 32–39, 2018.
  * [20] S. Zheng, T. Han, Y. Jiang, and X. Ge, “Smart contract-based spectrum sharing transactions for multi-operators wireless communication networks,” _IEEE Access_ , vol. 8, pp. 88 547–88 557, 2020.
  * [21] X. Fan and Y. Huo, “Blockchain based dynamic spectrum access of non-real-time data in cyber-physical-social systems,” _IEEE Access_ , vol. 8, pp. 64 486–64 498, 2020.
  * [22] H. Zhang, S. Leng, and H. Chai, “A blockchain enhanced dynamic spectrum sharing model based on proof-of-strategy,” in _ICC 2020 - 2020 IEEE International Conference on Communications (ICC)_ , 2020, pp. 1–6.
  * [23] X. Ling, J. Wang, T. Bouchoucha, B. C. Levy, and Z. Ding, “Blockchain radio access network (b-ran): Towards decentralized secure radio access paradigm,” _IEEE Access_ , vol. 7, pp. 9714–9723, 2019.
  * [24] M. A. A. Careem and A. Dutta, “Sensechain: Blockchain based reputation system for distributed spectrum enforcement,” in _2019 IEEE International Symposium on Dynamic Spectrum Access Networks (DySPAN)_ , 2019, pp. 1–10.
  * [25] A. Vosoughi, J. R. Cavallaro, and A. Marshall, “Trust-aware consensus-inspired distributed cooperative spectrum sensing for cognitive radio ad hoc networks,” _IEEE Transactions on Cognitive Communications and Networking_ , vol. 2, no. 1, pp. 24–37, 2016.
  * [26] Vitalik Buterin, Thoughts on UTXOs, 2016, http://timmurphy.org/2009/07/22/line-spacing-in-latex-documents/.
  * [27] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” pp. 1–32, 2014.
  * [28] X. Kang and Y. Wu, “A trust-based pollution attack prevention scheme in peer-to-peer streaming networks,” _Computer Networks_ , vol. 72, pp. 62 – 73, 2014. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1389128614002667
  * [29] D. Boneh, B. Bünz, and B. Fisch, “Batching techniques for accumulators with applications to iops and stateless blockchains,” in _Annual International Cryptology Conference_. Springer, 2019, pp. 561–586.
  * [30] G. Ateniese, B. Magri, D. Venturi, and E. Andrade, “Redactable blockchain – or – rewriting history in bitcoin and friends,” in _2017 IEEE European Symposium on Security and Privacy (EuroS P)_ , 2017, pp. 111–126.
  * [31] S. Li, H. Zhu, Z. Gao, X. Guan, Kai Xing, and X. Shen, “Location privacy preservation in collaborative spectrum sensing,” in _2012 Proceedings IEEE INFOCOM_ , 2012, pp. 729–737.
  * [32] P. Rogaway and T. Shrimpton, “Cryptographic hash-function basics: Definitions, implications, and separations for preimage resistance, second-preimage resistance, and collision resistance,” in _Fast Software Encryption_ , B. Roy and W. Meier, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2004, pp. 371–388.
  * [33] Solidity webpage, https://docs.soliditylang.org/en/v0.7.5/.
  * [34] Y.-C. Liang, _Blockchain for Dynamic Spectrum Management_. Singapore: Springer Singapore, 2020, pp. 121–146. [Online]. Available: https://doi.org/10.1007/978-981-15-0776-2_5
  * [35] Remix-Ethereum IDE, https://remix-ide.readthedocs.io/en/latest/.
  * [36] X. Kang, Y.-C. Liang, H. K. Garg, and L. Zhang, “Sensing-based spectrum sharing in cognitive radio networks,” _IEEE Transactions on Vehicular Technology_ , vol. 58, no. 8, pp. 4649–4654, 2009.
  * [37] D. Johnson, A. Menezes, and S. Vanstone, “The elliptic curve digital signature algorithm (ecdsa),” _Int. J. Inf. Sec._ , vol. 1, pp. 36–63, 08 2001.