# A Lightweight Hash-Based Blockchain Architecture for Industrial IoT
## 3 Proposed Lightweight Hash Based Blockchain Architecture for IIoT
### Network Interaction Process
Also, if the lightweight hash functions that can operate with better performance are developed, we argue that this architecture can be applied to other industrial IoT applications, which requires latency to be under 1 s.

However, if we implement the hash function parallel, it causes additional costs. The costs for the parallel implementation of hash functions consist of two parts. The first is an implementation cost, and the second is an operation cost. The hash functions require some area (GEs) in hardware implementation, and the implementation cost means the required area for parallel implementing. In our case, each selected hash functions requires less than 5000 GEs (see Table 5), and the total area for the three hash functions is 12,283 GEs. However, if the hash functions are implemented parallel, the required area for implementing will be increased linearly, depending on \(p\). For example, if the three hash functions implemented doubly, the total area for implementing is 24,566 GEs. The operation cost means that the power consumption for calculating hash values in the mining process. When the hash functions are implemented parallel, it makes the hash modules calculate simultaneously the hash value, which satisfies the target difficulty in the mining process. It does not mean that the total amount of calculation reduced. Each hash modules require equal power separately. Therefore, the power consumption for searching the right hash value increases linearly; thereby, the operation cost will increase linearly similar to the implementation cost, depending on \(p\). Because of this trade-off between processing time and cost, \(p\) has to be selected according to their resources. We do not recommend parallel implementation for devices with a highly restricted battery or area. ### Availability of Proposed Architecture

In Section 2.3, we introduced three considerations including Computational resources, Latency, and Scalability. The explanation of how can we satisfy each consideration is as follows. 1. Lightweight hash for computational resources: IIoT network consists of IoT devices with limited resources, and the resource-constrained devices have a tiny area and low power. For reducing the computational burden of a consensus protocol, we selected the lightweight hash functions QUARK, PHOTON, and SPONGENT. These hash functions were implemented with a small area (GEs < 5000), and also consume little power (\(\mu\)W < 10). It can be easily applied to resource-constrained devices, in contrast with existing hash functions such as SHA-256. Therefore, the consensus protocol using these lightweight hash function can be performed more lightly. 2. Hash list for latency: The mining process in the typical blockchain is performed with a predefined hash function for searching the specific hash value. However, in the proposed architecture, the cell

Figure 6: Result of parallel QUARK: (Left) - non-fixed parameter, (Right) - fixed parameter \(D=9\). node is responsible for the mining process to select a hash function from the hash list according to the network traffic. The hash functions in the hash list have different performances in terms of throughput and security. In the case of throughput, they show good throughput, and are listed in descending order: QUARK, PHOTON, then SPONGENT. Oppositely, in the case of security, including pre-image resistance, second pre-image resistance, and collision resistance, they show good security in order SPONGENT, PHOTON, QUARK. If the transactions increase according to network traffic, the cell node changes the hash function to one that has better throughput. Even though this also means that the security level of hash function decreases, it does not mean these hash functions are not secure. This approach can reduce the latency of the mining and updating process. 3. Composing cell node for scalability: In the industrial field, field devices can be spread in a wide location. The broadcasting for block validation can cause scalability issue because IoT devices have low bandwidth.