# A Trusted Routing Scheme Using Blockchain and Reinforcement Learning for Wireless Sensor Networks
## 3 Approach
### Blockchain Network Procedure  
To effectively operate the blockchain-based routing network architecture, information related to the routing network needs to be transferred to the blockchain network. The related routing information is recorded in the smart contracts including the registration contract, the token contract, and blockchain transactions, i.e., the token transaction as shown in Figure 4. All of these contents are verified by the server nodes then released to the blockchain. All the smart contracts are manipulated by the authenticated servers nodes and the results of the execution are returned to the blockchain network. The registration contract records the identity information (e.g., the physical address of a node) of all the routing nodes and server nodes to facilitate the query of the entire network node. The specific procedure for generating the registration contract is described as Algorithm 1. The mapping \(map\) is an inherent variable of the registration contract and contains the mapping of the blockchain addresses to the physical addresses. The mapping _state_ is also an inherent variable that stores the state of whether a node is registered or not. When a new node wants to register on a registration contract, it should trigger the contract as a contract caller. It then inputs its physical address \(pa\) as the identity information, and the registration contract automatically records its blockchain address \(ba\). The registration contract checks whether \(ba\) exists in the \(state\) mapping or not. If \(state=0\), the registration contract stores the map \(ba\to pa\) into the \(map\) mapping and the map \(ba\to 1\) into the \(state\) array, the result of this operation is a success. If \(state=1\) indicates that the node has been registered, the result of this operation is a failure. The logic of the code makes the blockchain address of the node corresponding to the identity, and the registration information cannot be changed once it is registered. Each routing node can release a token contract to generate a certain number of tokens by giving the correlated variables on the blockchain [29]; the release's blockchain address, the token name, an empty table mapping the routing node \(R\) to the token balance \(B_{R}\), the supply of the tokens, the destination routing node \(R_{t}\) of the tokens, etc. After releasing the token contract, the contract will automatically generate a corresponding supply of tokens for the release. Then the routing nodes can transact the tokens by triggering the \"transfer\" and \"confirm\" functions of the token contract. The process of transferring tokens is recorded as a token transaction on the blockchain. Figure 5 depicts the implementation details of one complete token transaction and we divide a token transaction into three processes:  
1. We initialize the number of packets in \(R_{i}\) as \(p\) and in \(R_{\pi}\) as \(q\), i.e., \(B_{R_{i}}=p\) and \(B_{R_{\pi}}=q\). First, \(R_{i}\) transmits \(n\) unit data packets to \(R_{\pi}\). In the traditional routing network, \(R_{\pi}\) will send back an acknowledgement (ACK) to confirm that the packets have been received and the token balances  
Figure 4: Specific formats of smart contracts and blockchain transactions. (**a**) Registration contract. (**b**) Token contract. (**c**) Token transaction. should be \(B_{R_{i}}=p-n\) and \(B_{R_{\pi}}=q+n\). Meanwhile, each routing node performs routing scheduling based on the routing information released by neighbor routing nodes in the traditional routing network. However, if \(R_{\pi}\) is a malicious routing node, it can deny the routing process to its neighbor routing nodes, such that the token balances for its neighbor routing nodes will be \(B_{R_{i}}=p\) and \(B_{R_{\pi}}=q\), so such these schemes cannot guarantee the trustworthiness between the routing nodes. 2.