More precisely, when some nodes are carrying a mes-
sage from a source node to the sink, their ownership
will be affected to the source node. At the first stage
all the nodes are owned by the sink. Each node that is
owned by the sink is considered to be inactive. Oth-
erwise, all the nodes which are not owned by the sink
are considered as active. When a node senses some
event, it looks up in the Blockchain and defines a list
of all inactive nodes, then it finds among them which
ones optimize its path to the sink, we will describe
the route choice process in the next subsection. Next,
it asks the sink to transfer the path’s nodes owner-
ship to it. Once the transaction is registered to the
Blockchain the node starts transmitting over the cho-
sen route. When the data is carried successfully to the
sink the transmitting node transfers back the owner-
ship of the path’s nodes, including itself, to the sink
as a way to inform the network’s peers that the trans-
mission was finished and these nodes were released.
We assume that a source node could own u nodes
while u ≤ n. We assume also that the nodes trans-
mit over two channels, the first one is dedicated to
the paths claiming and to the Blockchain transactions
transferring, and the second one is designated to carry
the sensed data. We are interested, primarily, in the
second channel which is used to transmit the message.
We suppose, also, that each intermediate node could
be owned, only, by one source node and a source node
is owned, only, by itself. When a node senses an event
while it is owned by an other node, the latter waits
until its ownership is transfered to the sink. In the
meantime, the node notifies the sink, through the first
channel, in order to be added to a waiting queue. The
waiting queue is mainly managed by the sink and it is
necessary to apply, a kind of, priorities to the waiting
nodes.
As we have seen, this technique allows for a good
knowledge of the source nodes as well as the paths
which they transmit on, at a given moment. It is
necessary, also, to mention that the nodes are rep-
resented in the Blockchain by their Ids. Hence, the
traffic load could be, easily, determined through the
Blockchain. Actually, it suffices to determine, di-
rectly from the chain, how many times the status of
a node has changed to be active. This changes num-
ber is, obviously, the number of messages carried by
a node, since a node status changes only when it is
in the path on which a message is transmitted. Now,
after we defined the traffic load at each node, we
have to define the routing determination process of
our model.
3.2 Route Determination Process
As each node knows the network’s map and as each
one can access the Blockchain and find which nodes
are transmitting and which nodes are not, it becomes
simpler to define the shortest path to the sink through
a set of inactive nodes. However, as said previously,
our main goal is to balance the traffic load and to re-
duce the interferences in the routing phase. So, we
have to define a cost function which optimizes the
path. First of all let us define the signal and inter-
ference to noise ratio (SINR) as (Gupta and Kumar,
2000),
SINR
(i, j)
=
p
i
d
a
i, j
!
/
N
0
+
n
∑
k=1
k6=i
p
k
d
a
k, j
(1)
where p
i
is the transmission power of the i
th
node,
d
i, j
is the distance between two nodes i and j, a is the
path loss exponent, and N
0
is the power of an additive
white Gaussian noise. The equation (1) is used beside
the load traffic to determine the routing cost to the
next hop. The cost function is defined as follow,
Cost
j
= SINR
(i, j)
/(1 + θ
j
) (2)
where j is the index of the next hop, SINR
(i, j)
is the
signal to interference and noise ratio, and θ
j
is the
traffic load of the j
th
node.
When an event is detected and a message is ready
to be sent, the source node k starts listing all the in-
active nodes, as explained before. Next, it calculates
the routing cost, using equation (2), for each of the
inactive nodes and determines the optimal path us-
ing dijkstra’s algorithm (Dijkstra, 1959). Once the
path determined, a chain verification is applied to
each node of the chosen path. If the chain of all the
nodes is verified, the source k claims for the owner-
ship of these nodes and the transaction is registered to
the Blockchain. Otherwise, k discards the untrusted
nodes and redefines a new optimal path. In case no
valid path is found to reach the sink, the source node
waits for active nodes to be libereted and notifies the
sink, through the first channel, in order to be added to
the waiting queue.
3.3 Security in the Routing Phase
We stated in the previous subsection that each source
node accomplishes a chain verification, right after it
chooses the optimal path, for each node on the cho-
sen route and we highlighted that all untrusted nodes
A Blockchain-based Approach for Optimal and Secure Routing in Wireless Sensor Networks
177