# A Lightweight Hash-Based Blockchain Architecture for Industrial IoT
## 3 Proposed Lightweight Hash Based Blockchain Architecture for IIoT  
### Overview of Proposed Lightweight Hash Based Blockchain Architecture  
In this section, we propose a lightweight, hash-based blockchain architecture for IIoT. In the previous section, we mentioned that the selection of hash function can affect the performance of the blockchain network due to the computational burden for block mining, which means that the performance of the hash function can affect the availability of the blockchain. However, IIoT devices have limited resources (low power, small area, and small memory). We selected some lightweight hash \begin{table}
\begin{tabular}{c c c} \hline \hline
**Hash Function** & **Example Coins** & **Number of Coins** \\ \hline X13 & Bitcoin Diamond, Straits, Navcoin & 27 \\ \hline Ethash & Ethereum, Ethereum Classic & 22 \\ \hline NeoScrypt & Red Pulse Pheonix & 22 \\ \hline Equihash & Zcash, Zcoin & 13 \\ \hline Keccak & SmartCash, Nexus, Maxcoin & 10 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: _Cont._functions which can be implemented using small area and perform with low-power, small memory. The proposed blockchain network consists of \"Cell node\" and \"Storage node\", and it operates between the field layer and control layer. We referred to the Purdue model to design the proposed architecture. Purdue model (ISA-95) is a standardized reference model proposed by [PERSON] [31] for Industrial Control System (ICS). Field layer of our proposed architecture correspond with level 0 and level 1 in Purdue model. And control layer of our proposed architecture correspond with level 2 in Purdue model. For covering many heterogeneous devices in a broad area, we separate the field to a small areas, which is mentioned as \"Cell\", and all IIoT devices connected to cell node, which is nearly located. And the cell node makes a block from data gathered by connected devices and broadcast to other nodes in blockchain for block validation after block mining. After the block validation process, all node participating in block validation send the return message to the storage node for notice validating results and then block update is processed. The storage node is responsible for managing block update and ledger management. In the block update process, the storage node appends the validated block. All of the processed transaction can be checked from the distributed ledger in the storage node. Figure 1 shows our proposed architecture, and brief explanations of the cell node and storage node are as follows, and we discuss more detailed description and process of each function in Section 3.3. * Cell node: The cell node is a miner node in blockchain, and it consists of \"LW Hash Manager, Device Manager, Traffic Analyzer, Mining Pool, Block Mining Manager, and Block Validation Manager\". The LW hash manager contains lightweight hash functions used in blockchain. The device manager is responsible for device registration required for participation in the cell area. The gathered data is stored in the mining pool as transactions that have yet to be processed. The traffic analyzer investigates the number of transactions. The calculated amount used to select a hash function from the lightweight hash list for block mining according to the predefined threshold. The hash list includes three hash functions--QUARK, PHOTON, and SPONGENT, please see the detailed description of the lightweight hash list in Section 3.2.1. The block mining manager operates block construction and searches the hash value, which satisfies the target difficulty. Last, the block validation manager operates the block validation process when other nodes request a block validation. Using these components, the cell node performs three functions (device management, block mining management, and block validation management) in the blockchain network.