IoT-Chain and Monitoring-Chain Using Multilevel Blockchain for IoT Security

In general, the Internet of Things (IoT) relies on centralized servers due to limited computing power and storage capacity. These server-based architectures have vulnerabilities such as DDoS attacks, single-point errors, and data forgery, and cannot guarantee stability and reliability. Blockchain technology can guarantee reliability and stability with a P2P network-based consensus algorithm and distributed ledger technology. However, it requires the high storage capacity of the existing blockchain and the computational power of the consensus algorithm. Therefore, blockchain nodes for IoT data management are maintained through an external cloud, an edge node. As a result, the vulnerability of the existing centralized structure cannot be guaranteed, and reliability cannot be guaranteed in the process of storing IoT data on the blockchain. In this paper, we propose a multi-level blockchain structure and consensus algorithm to solve the vulnerability. A multi-level blockchain operates on IoT devices, and there is an IoT chain layer that stores sensor data to ensure reliability. In addition, there is a hyperledger fabric-based monitoring chain layer that operates the access control for the metadata and data of the IoT chain to lighten the weight. We propose an export consensus method between the two blockchains, the Schnorr signature method, and a random-based lightweight consensus algorithm within the IoT-Chain. Experiments to measure the blockchain size, propagation time, consensus delay time, and transactions per second (TPS) were conducted using IoT. The blockchain did not exceed a certain size, and the delay time was reduced by 96% to 99% on average compared to the existing consensus algorithm. In the throughput tests, the maximum was 1701 TPS and the minimum was 1024 TPS.


Introduction
The use of the Internet of Things (IoT) has been increasing, and it is applied to various services in numerous fields [1], such as healthcare, energy, and smart homes. The anticipated IoT device growth is also on the rise. According to Exploding Topics [2], there are over 700 million IoT devices installed worldwide. That number is expected to over 30 billion by 2025. As IoT devices in homes, industrial environments, transportation networks, and elsewhere continue to proliferate, so does the attack surface for malicious IoT network attackers.
The IoT attack activity in 2020 dramatically surpassed the combined volume of IoT activity observed by IBM Security X-Force [3] in 2019. The IoT network is a centralized structure, and all IoT devices mainly use a structure that is linked to the central cloud, or data are stored in the cloud storage using fog and edge computing technologies. Owing to the centralized structure, the central server processes all data, and security vulnerabilities exist owing to the risk of data forgery and falsification, along with attacks on the central processing system, such as distributed denial of service (DDoS) [4] attacks. Depicted in Figure 1 is the centralization problem of existing IoT servers.
Vulnerabilities in centralized server architecture (1) Problems owing to IoT device performance limitations: The data measured by the sensor are transmitted to the server. The performance is worse than those of the existing PCs and servers, so there exists a limit [5] to applying existing security vulnerability solutions. Therefore, the Mirai botnet [6] may become a device that executes a server DDoS attack owing to malware infection through firmware updates.
Vulnerabilities in centralized server architecture (2) Vulnerabilities owing to fog and edge nodes: These nodes receive real-time data from IoT devices and provide temporary data storage until the necessary data are sent to the cloud. If the fog node is subjected to a security attack [7], it is possible that IoT-generated data may be forged or tampered with. Furthermore, the edge node computes and processes data in edge computing close to the data collection source and sends the data to the cloud. It serves to transmit data. Edge nodes also exhibit a problem in that data are forged and stolen when subjected to a security attack [8].
Vulnerabilities in centralized server architecture (3) Security weakness owing to centralized structure: The administrator is responsible for the performance and management of data stored in the central server. Data may be forged or falsified because of the authority of the administrator of the centralized server [9]. Moreover, owing to attacks by hackers and infected devices, the centralized server affects all systems if one server is attacked as a result of a single point of failure [10].

Motivation
Blockchain technology is used to solve the problem of centralized structures [11]. Blockchain is a distributed system that shares information with all non-central participants and distributes data to all network nodes using a peer-to-peer (P2P) network. The problem of data forgery and falsification of existing centralized servers can be solved by allowing nodes in all networks to store the same data. In addition, by securing the reliability of data through an inter-node consensus algorithm, the security problem of IoT devices can be solved with the blockchain function.
However, due to the limitations of blockchain technology, there is a limit to operation in IoT devices, and high-performance external cloud and edge computing technologies are used. This guarantees the immutability of the stored data, but it goes through multiple gateways and nodes during the storage process and cannot guarantee the reliability of the data. Therefore, the blockchain-based IoT data management method cannot achieve decentralization and cannot solve the limitations of the existing centralized structure.

Challenges
Blockchain technology can solve the security vulnerabilities of IoT devices, but it has the following limitations.

Capacity Requirement
For an IoT device to become a full node that maintains the blockchain in the blockchain network, all of the blockchains must be stored in storage. However, IoT devices are not suitable for participating as full nodes in blockchain networks because of their low storage capacities.

Consensus Requirement
The consensus algorithm for block generation uses proof of work (PoW) [12], which requires a high amount of CPU operation, or practical Byzantine fault tolerance (PBFT) [13], which requires a certain amount of network communication. For IoT devices, a consensus algorithm that requires substantial computation is not suitable owing to its low performance [14], and a consensus algorithm that requires substantial communication in an IoT network with many nodes is not effective, particularly when using a wireless network.

Data Privacy
Blockchain discloses data transparently, as all nodes have the same blockchain. As IoT data are increasingly used, personal data are also created and managed; thus, data privacy must be guaranteed.

Contribution
We propose an IoT-operable blockchain that overcomes the limitations of the blockchain that cannot guarantee privacy because of the storage space requirement owing to the increase in the blockchain length, the amount of computation and network communication of the consensus algorithm, and data transparency. To this end, we present a multilevel blockchain structure consisting of the IoT-Chain, which is a lightweight blockchain that operates on IoT devices and is pluggable into Hyperledger Fabric or Ethereum, and the Monitoring-Chain, which is implemented based on Hyperledger Fabric.
The IoT-Chain, which is a blockchain that operates on IoT devices, and a monitoring chain to solve the performance limitations of devices that operate nodes of the IoT-Chain, are configured. In addition, by applying the lightweight consensus algorithm of IoT-Chain and the process of periodically distributing and storing IoT-Chain and storing only metadata after verification through consensus of all nodes, a reliable lightweight technique is applied to centralize existing IoT device data management. The limitations of the existing server structure can be solved through blockchain.

Capacity Requirement
We propose the IoT-Chain and Monitoring-Chain to lighten the blockchain. Blocks are created in the IoT-Chain through a consensus method in which all nodes using the Schnorr signature participate and verify the hash value of the last block to ensure the reliability between the two blockchains that can be operated on IoT devices. After distributing and storing the chain in a distributed file system, only the address value is embedded into the Monitoring-Chain, following which the blockchain of the IoT-Chain is initialized so that the blockchain capacity stored in the IoT-Chain does not exceed a specific size. The blockchain can be maintained even in IoT devices with limitations.

Consensus Requirement
We propose a block generation consensus algorithm that overcomes the limitations of the IoT device CPU operation and network communication volume. By using the verifiable random function (VRF) [15] and public key infrastructure (PKI) [16], we present a method to select a leader node for generating a block by determining verifiable random values.

Data Privacy
After distributing the IoT-Chain and embedding the returned address in the Monitoring-Chain, it was stored in the Monitoring-Chain network that is constructed based on Hyperledger Fabric [17], which is a permissioned blockchain, and it is only accessed by authorized users through smart contracts [18]. The data can be accessed to ensure the privacy of IoT data. The proposed blockchain structure was implemented and registered as an open source program [19]. It was verified that it can operate in IoT devices. Subsequent papers will consist of research relating to the proposed blockchain structure, and descriptions of the constructed blockchain module and system, architecture, analysis, experiments, and results.

Related Work
We compare existing lightweight blockchains in Table 1. The comparison is based on the node's operating location, TPS, storage overhead, amount of computation, whether access control is supported, scalability, and whether off-chain storage is used. The amounts of computation were divided into PoW (high), PoS (mid), and PBFT (low) series based on the consensus algorithm. Sensor-chain [20] was proposed as a lightweight solution to use IoT devices appropriately for blockchain. Spatial blockchain [21], which divides the blockchain into spatial units, and the migration manager function [22], were used when migrating according to time. Each blockchain owns the blockchain according to the space, and as time passes, the contents of all blockchains are summarized in one block, following which the blockchain size is reduced by starting from that block. However, data loss may occur by summarizing the data that are collected from IoT devices as data such as averages, and only simple data such as sensor values can be used.  [23] is a cryptocurrency platform that is designed to apply blockchain to the IoT. It uses the proprietary tangle algorithm of the blockchain to reduce the blockchain size and to make it suitable. However, owing to the semicentralized form that cannot achieve complete decentralization of the IoT of the blockchain, the nodes that store a large amount of data may be attacked, and there are vulnerabilities in the hacking methods, such as centralized attacks. Furthermore, it is not suitable for IoT devices with low computing power using PoW as a consensus algorithm.
In BPIIoT [24] and Fusion-Chain [25], the InterPlanetary File System (IPFS) that utilizes a distributed hash table (DHT) for lightweight functions is used to store transactions, which are sensor data, in blocks, and to distribute and store blocks and accessible addresses. It uses a method to store only the values. However, in this study, the IPFS is not a method for distributing and storing the blocks to be stored. The blockchain is distributed and stored after the consensus of all nodes at a specific cycle, and then exported to another blockchain, and the blockchain is restarted.
EdgeChain [26], using edge computing, applies a credit-based resource management system to control all IoT devices from the edge server. Moreover, it stores all activations and transactions created by the IoT devices, and audits the data resources of the IoT devices through records. In the case of BlockEdge, blockchain is used to audit the different processes involved in industrial IoT applications.
HyperLoRa [27] detects tampering of IoT data using Hyperledger Fabric. Certain studies [28] have also used a smart grid network and permissioned blockchain.
BLA [29] uses blockchain in a fog-based IoV environment, and the Group Signature and Authentication Scheme for Blockchain-Based Mobile-Edge Computing [30] was used to authenticate new users in multi-access edge computing. This enables local authentication without the need for authentication from the cloud; thus, it is possible to reduce the latency required for verification in edge computing.
However, in all of the above methods, the blockchain does not work in IoT devices, and vulnerabilities exist, as illustrated in Figure 1. Regarding blockchains based on sharding, OmniLedger [31], RapidChain [32], and RepChain [33] are limited to cryptocurrency applications. RepChain also defines the reputation by using the trust and activeness of validators, based on their decisions on the list of transactions. RepChain uses the accumulated reputation values for balanced sharding and leader selection. However, when the leader node is selected through the accumulated values of the reputation, the randomness is reduced. In this study, a leader node was randomly selected using VRF.  HomeChain [34], which is a novel attribute-based access control scheme for IoT systems [35], and Fabric-IoT [36], have been used for the access control of IoT devices based on blockchain. In this study, the access control function for the user is implemented for security by using the smart contract of the blockchain, but forgery and falsification of the sensor data storage generated by the IoT device mean that stability is not guaranteed. Studies on consensus algorithms have been conducted, including PoBT [37], Algorand [38], and Tendermint [39].
PoBT consists of a structure that is suitable for IoT scalability and performance based on the consensus structure of Hyperledger Fabric, and Algorand is a VRF-based consensus algorithm. Tendermint is a PBFT-based consensus algorithm. In this study, although Hyperledger Fabric is used, a new blockchain that operates on IoT devices is proposed. A random-based consensus algorithm is suitable for IoT performance. Unlike PBFT, a consensus method and lightweight method that are suitable for network traffic and sensor generation speed are proposed. Moreover, as opposed to Algorand, this study presents a blockchain that is suitable for IoT devices by selecting a consensus leader node based on the size of a value without using VRF to form a committee.
Reference [40] proposed a consensus algorithm that improves the performance of the routing algorithm. A lightweight blockchain-based secure routing algorithm has been proposed to address the challenges [41] of swarm unmanned aircraft system (UAS) networking, and a proof of traffic consensus algorithm that reduces passive broadcasts is used.
Reference [42] proposed a consensus construction with high verification efficiency with base stations for cellular network connection. Unlike the above paper, in this paper, we propose an efficient group authentication method based on the consensus algorithm and Schnorr signature based on lightweight communication in IoT-Chain.
Reference [43] proposed a blockchain that requires minimal hardware and software performance. To this end, we propose a witness protocol, which can maintain a blockchain with minimal hardware, and does not require additional equipment or access to a centralized network. In contrast, the blockchain in this paper is a multi-level blockchain configuration so that blockchain nodes can participate in the maintenance of the blockchain and participate in the consensus algorithm and data verification process.

Hyperledger Fabric
Hyperledger Fabric [17] is a private blockchain that provides network security and distributed ledger technology with scalability, confidentiality, and improved performance. Furthermore, as network roles are assigned for each node type in Hyperledger Fabric, network concurrency and parallelism are provided, which offers the advantage of high TPS compared to public blockchain platforms. In this study, the monitoring chain was implemented with Hyperledger Fabric, and the chaincode of Hyperledger Fabric was used to monitor the data generated by the IoT sensors and to implement the access control function to check the user's authority when accessing the data.

InterPlanetary File System
The IPFS [44] distributes files such as photos, texts, and videos on the Internet and uses a unique hash value to load the distributed data rapidly. High-capacity files can be loaded quickly and efficiently, and by using a unique hash value, the existence of duplicate files can be known for efficient file storage. The nodes participating in the IPFS network manage the hash table independently and store data without a server. This provides a method of mapping filenames to values in the hash table that is held by each node without using a central server through the DHT. The DHT can suppress the load on the network, and enables the fast and accurate retrieval of files in the network. The IPFS is content addressed, where the file itself acts as an address. If the file name (CID) is found in the DHT through data, the node that has the distributed fragment of the file is found and the file is loaded. When distributing files, the IPFS converts all files on the network into the Merkle-DAG format. For each node, the CID, which is a hash of the node content, is used for Merkle-DAG. By using Merkle-DAG, the IPFS can address content, and prevent tampering and duplication. By using these functions, the IPFS distributes and stores the blockchain for every round of the IoT-Chain and returns a hash value to the monitoring chain. Data can be accessed on the IoT-Chain through the hash value that is stored in the Monitoring-Chain.

Schnorr Signature
The Schnorr signature [45] is similar to the method of extracting a public key from a single number (e.g., private key) in the elliptic curve digital signature algorithm (ECDSA) [46], but has the characteristic of linearity. The ECDSA involves many heavy operations, such as modular inverse and points multiplication, in the calculation process, whereas Schnorr has relatively few heavy operations in comparison. Schnorr signatures also enable collective signatures that combine the signatures of multiple signers into a single signature. As a result, N signatures can be verified once instead of N times, and the size of the signature is reduced. In this study, the Schnorr signature is used when signing following the verification of all nodes.

Verifiable Random Function
The VRF [15] is a function that outputs a verifiable pseudo-random value for the input. The VRF generates a unique and verifiable pseudorandom number Y for input X when the key pairs VK and SK are fixed. The VRF is similar to the digital signature method in that the output can be verified using a separate verification key. However, the digital signature differs from the VRF function in that multiple valid signatures exist for one input, and the output value is not sufficiently random to satisfy the pseudorandom number condition. In this study, it is used to select a leader node in the consensus process of the IoT-Chain that can be operated in IoT devices. All IoT-Chain nodes that create a transaction execute the VRF function, include the returned result value in the transaction, and send it to the leader node. The leader node selects the node with the largest VRF value as the next leader node and creates a block to propagate to all of the nodes.

Architecture
The proposed architecture is a multi-level blockchain structure consisting of an IoT-Chain network that can only be configured with IoT devices, and a monitoring chain to increase the size of the IoT-Chain and solve the limitations of controlling access to data. Through a multi-level blockchain structure, decentralized data management is possible only with IoT devices, and blocks are verified using consensus that does not require a computational load through a PBFT-based consensus algorithm in the IoT chain. In addition, when exporting blockchain from IoT-Chain to Monitoring-Chain, signatures of all IoT-Chain nodes are required during the consensus process, and network communication must be guaranteed not to be lost during consensus. Therefore, by using the Schnorr signature method, the capacity of the signature is reduced in the consensus process to reduce the message size during the consensus of the export process, and there are nodes that deliver only the external monitoring chain and metadata through the Exporter node. Forgery and falsification of the node's data can be guaranteed through the Schnorr signature, which contains the compressed signatures of all nodes. The following describes the overall architecture of the structure proposed in this paper, the structure and operation of the IoT-Chain, and the Monitoring-Chain.

System Design
As depicted in Figure 2, Network ic runs on IoT devices and maintains the IC that stores the sensor data. It consists of Node ic , Node leader , and Node export . Node ic generates sensor data to generate TX. Node leader is randomly selected, collects TX generated by the node, generates Block ic , and propagates them to all nodes. Node export maintains a routing table for consensus, sets a path to receive the signatures of all nodes, detects a certain size, and verifies that BH last of all Node ic is the same to start an agreement. Every Node ic encrypts BH last via Key priv to create Sig, which is combined with the signatures generated by other Node ic in the consensus path Sig schnorr and adding Key pub to create Key schnorr , and can verify the signatures of all nodes with one verification. All BH last are verified to be the same, and Node export uploads IC to DFS and returns Address ic to create Block export . Network mc is implemented based on Hyperledger Fabric, receives Block export generated by Block export , and sends Sig schnorr through SC to Key schnorr . If the decoded value is the same as BH last , it is stored in MC, and the IC of all Node ic starts from Block genesis again. In the IoT-Chain, there are nodes that generate transactions and exporter nodes that lighten the IoT-Chain by periodically communicating with a leader node and a monitoring chain that are randomly selected among nodes and generate blocks. In the case of a leader node, a block is created by receiving the broadcast transaction. An exporter node is a node registered in the monitoring chain as a gateway that ensures network communication rather than a general IoT device for communication with the monitoring chain. In addition, stable communication is ensured through the exporter node, preventing data loss during network communication, and it is possible to ensure that all nodes have verified data for the lightweight blockchain through a compressed signature during the consensus process. Table 2 lists the terms used in this study.

3/0& )"
IoT Chain System Architecture: (1) All Node ic register their identity through CA and then participate in the network and register the IC by storing the Genesis Block hash value in the MC. All IoT-Chain nodes must obtain a key through CA and register a certificate for the public key. In (2) Network ic , Nodeic generates the sensor data, Block ic is generated, and the length of the IC increases. (3) To maintain the IC at no more than a certain size (storage capacity of IoT device), Node export is all BH last of all Node ic . By starting a consensus to verify that all Node ic have the same IC, Sig schnorr and Key schnorr are created. (4) Node export uploads IC to DFS and returns Address ic and Block export with Sig schnorr , and BH last is created and passed to Network mc . Node mc requests Key pub from CA, creates Key schnorr , validates Sig schnorr , and if verified, Block export is MC, which is saved and embedded. (5) For user access control, the smart contract verifies the access rights of the user, and if verified, it allows access to Block export stored in the MC. (6) The user can access the IC stored in the DFS through Address ic stored in Block export .

Multilevel Blockchain
This section explains why it is composed of a multilevel blockchain. As depicted in Thus, if it goes above a certain size, IoT devices will not be able to sustain the blockchain due to insufficient storage capacity. In addition, the consensus process is essential for block creation in the blockchain. The consensus algorithm is divided into PoW consensus, which requires CPU operation, and PBFT, which proceeds only through network communication. However, as both consensus algorithms have to be operated on IoT devices as in (B-2), they require CPU computation or high network traffic. (C) is a multi-level blockchain structure to supplement the limitations of (A) and (B). In this structure, IoT devices maintain the IoT-Chain. The monitoring chain supports the IoT-Chain. (C-1) When the storage capacity becomes insufficient, the blockchain from the genesis block to the present is recorded externally (C-2) to the external distributed file system. After recording, the data are backed up in the monitoring chain, and in this process, the export process is performed for data verification. This process is not verified by a single node, but by (C-3) monitoring chain nodes. Therefore, the monitoring chain supports the IoT-Chain in performing data backup and decentralized verification. In addition, the IoT-Chain network is not a private network, but it is necessary to record node information in the monitoring chain for verification in the export process. Therefore, anyone can participate in the network, and the participating sensors are based on P2P communication, ultra-low power, and ultra-low performance hardware, so basic calculations are possible, unlike in a sensor network environment.

IoT-Chain
Network ic creates a block through a lightweight consensus algorithm, and following consensus using Sig schnorr for each round, the address is returned after storing the blockchain in an external distributed file system (DFS). After transferring only the value to Network mc , IC is lightened by starting from the Genesis Block. As depicted in Figure 4, presents the block structure of IC. The data in the block are composed of Index, BlockHash, PreviousHash, timestamp, and Node leader . Node leader recorded in the block instructs the generation of the next block. TX is created as a node. TX is stored in the body and includes the sensor data, Sig, and Val rand . 31

Genesis Block
IoT   Figure 5 depicts the process in which Node ic generates TX and sends TX to Node leader , and Node leader generates Block ic . The node that generates TX from Network ic executes the VRF and includes the returned value, sensor data, and Sig generated through Key priv in TX, which is sent to Node leader .
x x 1. Execute the VRF function 2. Send a transaction to the leader node 3. The leader node selects the next leader node and distributes blocks. Figure 5. Block ic generation process: (1) Node ic executes the VRF function when TX is created, returns Val rand , and encrypts data with its own Key priv and Sig. After generation, Node leader is checked to generate the next block in the last block of the blockchain and to send TX. (2) The TX structure, Sig, and Val rand of Node leader that received TX are verified. (3) If all Val rand are verified, the node with the largest Val rand among the nodes that transmitted TX is selected as the next Node leader , recorded in a block, and distributed to all nodes.
The Node ic executes VRF every set round and delay, the Node ic with the lowest value is selected as the Node leader , and a Block ic is generated from the Node leader . In this way, the next Node leader is unpredictable, thus preventing the attack. Round means the cycle to create a Block ic , and delay is the time to select a Node leader . The selected Node leader creates as many blocks as rounds, and then all nodes execute VRF during delay and broadcast the result to the Network ic in the gossip protocol. After the delay time is over, the node with the lowest value among the nodes is selected as the Node leader .
In this paper, to lighten the IoT chain, the blockchain is stored in a distributed file system, and only metadata are stored in the monitoring chain. This process corresponds to the export process, and a monitoring chain and exporter node are required for operation. The monitoring chain enables decentralized verification of the Schnorr signature, the result of the export process, as nodes verify through smart contracts. In addition, the export agreement proceeds in the ring signature [47] method. Therefore, it is necessary to have a node that initiates and terminates consensus, collects it, and sends the result of the consensus to the monitoring chain. The export node is responsible for initiating the export consensus and transferring the generated Schnorr signature to the monitoring chain.

Monitoring-Chain
The monitoring chain serves to support the export process in the IoT-Chain. In the IoT-Chain, after the export process is performed, the "Schnorr signature" is created by combining the signatures of the nodes. If the Schnorr signature is verified with the stored public key, it is verified that all Node ic signed it. However, due to the centralization problem, it cannot be guaranteed that all Node ic signed after a single Node exporter verifies the signature. Node mc is verified through smart contracts, enabling decentralized verification of the export process. Additionally, for decentralized verification through smart contracts, IoT-Chain nodes do not need to know each other, but the monitoring chain needs to know all IoT-Chain nodes. Therefore, in order to participate in the IoT-Chain, Node ic must register the IoT-Chain node in the monitoring chain to participate in the IoT-Chain. This course is essential for lowering storage weight. In addition, the monitoring chain can maintain data and record metadata about the distributed storage of the IoT-Chain. The value maintained in the monitoring chain is an IoT-Chain of a certain length, which is maintained even when all IoT-Chain networks are terminated, and the recorded hash value allows access to the IoT-Chain stored in the distributed file system.
Network mc stores IC in DFS every round in Network ic and returns Address ic and Sig schnorr . BH last receives Block export and stores it in MC. Depicted in Figure 6 is the block structure of MC. The BlockHeader includes Index, BlockHash, PreviousHash, and timestamp. TX is stored in the body and Block export is stored in TX.  In Network ic , Network mc is exported to round, where the IC is larger than a certain size. Depicted in Figure 7 is the process of embedding the IC from Network ic to Network mc . Node export acts as a gateway between Network ic and Network mc , and among the nodes of Network ic , the node with the highest network condition and hardware performance is selected. Alternatively, the routing protocol method of the inferior gateway routing protocol (IGRP), which is a dynamic routing method, maintains the routing table of the consensus process that checks that BH last of all Node ic is the same.

Workflow
This section describes the operation process of the proposed Network ic and Network mc . The processes of registering BH genesis to Network mc , creating TX and Block ic , embedding IC from Network ic to Network mc , verifying Blokc export in Network mc , and starting over from Block genesis in Network ic are explained in order.
Algorithm 1 is the process of saving the information of Node ic to register IC in Network mc . All Node ic sends BH genesis of the same IoT-Chain to MC and stores it through SC. The operation process consists of a process of generating a signature and requesting to register a node, and a process of registering node information by verifying the signature. In the case of signature generation, it runs on the nodes of the IoT chain, and in the case of verification, it operates on the nodes constituting the monitoring chain. To register Network ic in Network mc , it is necessary to verify that all BH genesis owned by the node are the same. Node ic encrypts BH genesis through Key priv to create Sig, and creates TX containing Sig and BH genesis to send to Network mc . Node mc requests Key pub from CA for Sig included in TX, and all Sig included in TX are sent from Network ic . If the decrypted value of BH genesis is the same, the corresponding BH genesis is stored in the MC. Multiple Network ic can be distinguished through the saved BH genesis , and Key pub of Node ic can be requested from the CA.

12:
Key pub ← CA 13: if Veri f ySig(Sig, BH last , Key pub ) is true then 14: SetState(BH last ) 15: end if 16: end for 17: end procedure Algorithm 2 is the process of creating blocks and transactions in the IoT-Chain. The operation process consists of the process of creating a transaction, including the data collected from the IoT device through the sensor, and the process of creating a block by including the transaction in the block after verification. In the case of transaction creation, it operates on the nodes of the IoT chain. In the case of block generation after transaction verification, it is operated by a leader node randomly selected from among the nodes of the IoT chain every block generation round. Node ic generates sensor data and encrypts the sensor data using Key priv for TX generation. The VRF is executed to return Val rand and to transmit TX, including sensor data, Sig, and Val rand , to Node leader recorded in the last block. Node leader verifies the values stored in TX with Key pub and has the largest value of Val rand . After selecting Node ic as the next Node leader , it is recorded in Block ic , distributed to Network ic , and added to the IC. Unlike O(n 2 ), which is the communication amount of the PBFT-based algorithm that achieves consensus through network communication, a leader node is selected through a random function, and the block is verified with the communication amount of O(n). Through the consensus algorithm with a reduced number of messages compared to the PBFT-based consensus algorithm, consensus is possible even in IoT devices with low computational power without using the PoW-based consensus algorithm that requires more computational power. SendTX(TX, Node leader ) 9: end procedure 10: 11: procedure PROCEDURE Node leader : 12: TX ← ReceviceTX() 13: if TXs.Length is count then 14: TXs ← TX 15: Count(TXs) is not count 16: Node leader ← GetMaxRandomValueNode(TXs) 17: Block ic ← CreateBlock(Txs, Node leader ) 18:

Broadcast(Block ic )
19: end if 20: end procedure Algorithm 3 is a lightweight storage process for IC. Nodes in Network ic proceed with "export consensus" to store IC in DFS. After the export consensus process, Block exports with the Schnorr signature is delivered to Network mc through the export node. This process is used to periodically store the IoT chain in a distributed file system and record only metadata for verification in the monitoring chain in order to reduce the capacity of the IoT chain. For verification, it is necessary to start the process of verifying data through the hash value of the last block of the IoT chain. In addition, the final block hash value, which is the verified result, and the signatures of IoT-Chain nodes, must be compressed to generate a Schnorr signature. For operation, the export process of the IoT chain is executed in the Exporter Node. The process of verifying and signing the last block hash value is executed in the nodes of the IoT-Chain. Block ic is created in Network ic , the size of the IC increases, and the round exceeds a certain size. Each Node ic initiates a consensus verifying that BH last are all the same for embedding into Network mc . Among the nodes, Node expoert , which is a pre-selected gateway node based on the network and hardware status, is the route of consensus of all nodes through the routing protocol. Node expoert creates a Sig encrypted with BH last with Key priv , creates Block export containing BH last and Sig, and delivers it to the next node on the route. After receiving it, Node ic sends Sig schnorr to Key pub , which is verified through the CA. If the BH last returned by creating and decrypting Key schnorr is the same as the BH last of its own IC, the corresponding BH last is encrypted with Key priv to create a Sig, the Sig is combined with a Schnorr signature method, and the Sig is added by Sig schnorr to generate the combined Sig. It is created, passed to the next Node ic in the route, and this is repeated until the next Node ic does not exist. Every node in the Network ic repeats this process, the last Node ic sends a Block export to Node export , and Sig schnorr sends a Block export to all nodes in CA. If the same BH last value is returned after decrypting with Key schnorr created by combining Key pub , the IC is distributed and stored in the DFS, and subsequently, Address ic is returned. Node export transmits Block export to Network mc . When using the existing multi-signature method, a signature size of about O(n) and a number of verifications are required, depending on the number of network nodes. The proposed algorithm compresses the signature using the Schnorr signature method. As a result, the number of validations required for group signatures and the storage capacity of the signatures are reduced by O(1). To create metadata of the IoT-Chain, signatures of all IoT-Chain nodes are required. However, in order to receive the signatures of all nodes, the number of signatures increases as much as the number of nodes, the size of the message also increases, and O(n) signature verification processes exist. In the structure of this paper, verification and verification data transmission are possible in a single signature by compressing the signature using the Schnorr signature.

21:
end if 22: if exist(consensusRoute.Next) is true then 23: Broadcast(Block Export , Key schnorr , Route) 24: exist(consensusRoute.Next) is f alse 25: Broadcast(Block Export , Key schnorr , Node export ) 26: end if 27: end for 28: end procedure Algorithm 4 is the process of transferring and saving Block export from Network ic to Network mc . In this process, after verifying the block hash value made by the nodes of the IoT chain, it is guaranteed that all nodes maintain the same blockchain. After this verification process is performed, the process of transmitting the compressed signature and hash value to the monitoring chain is performed. In addition, the process of verifying the result value delivered to the monitoring chain and storing it in the monitoring chain is performed. The resulting value of the export process is executed by the exporter node and transmitted to the monitoring chain, and the verification process is performed in the monitoring chain node. In Network mc , Sig schnorr , which is stored in Block export and delivered by Node export , is requested by the CA. The returned Key pub is combined and verified, and Block export is stored in the MC. In Network ic , the IC is restarted by storing the address in the MC and embedding the IC and then performing the hash operation with the stored BH last and creating the connected block.

Security Analysis
In this section, on the lightweight blockchain using the proposed multilevel structure of Network ic and Network mc , we analyze the existing security solution application's limitations owing to the low performance, which is the weakness of existing IoT devices, security vulnerabilities of fog nodes and edge nodes, and whether vulnerabilities caused by data forgery owing to the centralized server structure, single-point errors of the central server, and DDoS attacks can be resolved. The STRIDE threat model technique was applied for the existing IoT blockchain threat analysis.

STRIDE Threat Modeling
According to the Microsoft Threat Modeling Tool threats in Table 3, there are six threats in the STRIDE model: identity spoofing, data tampering, denial, information disclosure, denial of service, and elevation of privilege. We applied the STRIDE model to analyze the threats of existing blockchain-based IoT data management methods and compared them with the proposed structure. Figure 8 shows the data flow of the proposed structure and the existing blockchain-based IoT device data management method. The existing blockchain-based IoT data management method consists of the IoT Device Zone, IoT Filed Gateway Zone, and Cloud/Edge Computing Zone, and the threats of each component were analyzed and compared with those identified in this paper. Table 4 is the analysis of results, and its contents are as follows.

IoT Device Zone Threats
As for the existing IoT device zone threats, there is a method that attempts to log in with spoofed authentication and a threat that exploits it through authentication information.
In the structure of this paper, a private key exists for each device and is managed through CA, and all device requests can be used if they are authenticated through a signature. In addition, it is assumed that the private key is not leaked to anyone other than the device and the user.

IoT Flied Gateway Zone Threats
IoT devices are not suitable for application to existing security solutions owing to their low performances. However, the storage requirements of the blockchain and excessive computational amounts of the consensus algorithm will result in traffic problems in the network. Therefore, in the existing blockchain-based IoT data management method, it acts as a client that stores data by sending a transaction through the gateway to a blockchain node operating in an external cloud with a gateway. However, this can lead to information disclosure and data tampering through spoofing attacks on the gateway. In this study, we minimized the use of gateways by using a lightweight blockchain that can operate on IoT devices rather than external blockchain nodes. In addition, during the export process for storage lightening, gateways are randomly selected to prevent attacks.

Cloud and Edge Computing Zone Threats
Existing blockchain-based IoT data management stores data in the cloud and central server. Additionally, the central server is managed by an authorized administrator. Data reliability and integrity cannot be guaranteed due to the possibility of data tampering by privileged administrators and DDoS and SPOF attacks. Through the proposed lightweight blockchain, all IoT devices participate as nodes rather than clients of Network ic to generate Block ic through a consensus algorithm and maintain the IC to ensure data reliability, and the same ledger is held by all Node ic , thereby eliminating the possibility of forgery. Moreover, by uploading the IC for each specific round to the DFS, Address ic is returned and embedded into Network mc , implemented based on the private blockchain HF, and distributed and stored because of the decentralized structure, whereby all Node ic agree for consensus. Thus, decentralization can be guaranteed, and there is no possibility of service failure owing to DDoS attacks and single-point errors. Table 5 is the experimental environments. An experiment was conducted using three Raspberry Pi 4 B computers (system on chip: Broad-com BCM2711, quadcore Cortex-A72 (ARM v8) 64-bit SoC @ 1.5 GHz, memory: 4 GB LPDDR4-3200 SDRAM, OS: Raspbian GNU Linux 10). As depicted in Figure 9, an IoT device network was configured to verify whether the Network ic configuration can be built in an IoT network. Furthermore, by considering the increase in the blockchain size and latency according to the data generated by the actual IoT device, the average file size according to the file format, and the average data size generated by the IoT device for TPS measurement, the experimental data were converted into 8, 128, 1K, and 10K. Decentralization was guaranteed, and there was no possibility of service failure owing to DDoS attacks and single-point errors.

IoT-Chain Size
In Network iot , after consensus is reached for each round in which the IC becomes a specific size, the IC is distributed and stored in the DFS to convert Address ic into Network mc . The blockchain size is lightened through the process of sending it, embedding it, and starting the IC again. Depicted in Figure 10 are the size of the IC to which the proposed export was applied and the IC to which the proposed export was not applied. The standard of the round was when the size of the IC became 5 kB. The experiment demonstrated that the size of IC to which the export process was applied did not exceed 5000 kB, but it was confirmed that the size of the blockchain continued to increase when it was not applied.

Consensus Algorithm
In Network ic , the delay time is reduced by randomly selecting Node leader for consensus when creating Block ic . As a result, only the delay time corresponding to 0.004 s is displayed. For a performance comparison, the PBFT consensus algorithm implemented in the Fusion-Chain of the IoT-Chain node was applied, and the PoW consensus algorithm with Nonce = 2 was applied to compare the delay time. As a result of generating Block ic from Network ic by applying the proposed consensus algorithm, there was an average delay of 0.0044 s, as depicted in Figure 11. However, when blocks were generated through the PBFT consensus algorithm, the average delay time was 0.1266 s. The average delay time of 5.528 s was measured when using PoW. Through the proposed consensus algorithm, the block generation time was reduced by 96% compared to PBFT and 99% compared to PoW. Moreover, when a leader node is selected, a DDoS attack can occur because all nodes can know the leader node when using the method of sending a transaction to the leader node recorded in the last block, but the problem could be solved with a delay of only 0.0044 s. The experimental results confirmed that the latency was reduced compared to the representative consensus algorithm with high CPU computation and network communication. As depicted in Figure 12, which is the experimental result of comparing the average CPU usage of the leader node and the consensus participating node during consensus for block generation, it was confirmed that the proposed consensus algorithm had the lowest average CPU usage. The experiments were conducted by changing the consensus algorithm of IoT-Chain to PoW, PBFT, and the proposed consensus algorithm. In the case of CPU usage, average CPU usage was sampled for 1 s, and the average CPU usage values of the leader node (PBFT, proposed consensus algorithm) and mining node (PoW) were measured from block creation to consensus. The number of nodes of all IoT-Chains was the same, five, and the difficulty nonce value of PoW was set to two.

Block Propagation Delay
The time for the block to propagate from Node leader to Node ic was measured according to the data size to check whether the data size affected the propagation to nodes after the block was created in Network ic . To measure the block propagation delay time according to various data sizes in Network ic , the data were divided into sizes of 8, 128, 1K, and 10K bytes; and blocks were created in the leader node for five IoT devices, Node ic .
For the experiment, after the block was created, the block propagation delay time from Node leader to all Node ic was measured, and the maximum, minimum, and average Boxplot graphs are displayed.
By operating and configuring NetworK ic , we measured the propagation time after agreeing to Block ic , as depicted in Figure 13. It was confirmed that the propagation time of Block ic increased depending on the data size, but the increase was not large, and the maximum average delay time was only 36 ms.

Schnorr Signature
To export the IC from Network ic to Network mc , Sig was created using the Schnorr signature method to verify that the IC of Node ic was the same as BH last . To measure the delay time of the method, the delay time of generating Sig schnorr by combining the signatures generated by encrypting 128 bytes of data with Key priv according to the number of nodes was measured, as depicted in Figure 14. The experimental results revealed that the IoT device generated Sig schnorr while increasing the number of Node ic , but the delay time for generating Sig schnorr from each Node ic was constant. It was confirmed that when generating the Schnorr signatures, there was no significant difference in delay time, even if the number of signatures to be combined increased.  Figure 15 depicts the results of measuring the delay time when exporting the IC from Network ic to Network mc . The delay time consisted of three parts: generating the Schnorr signature, uploading the IC to the DFS, and transferring Network ic to Network mc Block export . The transmission latency consisted of Network ic using the DFS to embed the IC with Network mc . Node export uploaded the IC held in the configured DFS by all Node ic that were verified, and it was confirmed that the delay time was only 50 ms. For embedding from Network ic to Network mc , all Node ic have the same IC and go through the process of agreeing to export. During this process, all nodes in Node ic must receive and verify Sig. However, since signatures of each node are all generated, there is an O(N) overhead due to signatures in Node ic . In this paper, the signatures of nodes participating in consensus can be combined into one signature through the Schnorr signature. In this way, each node reduces the storage capacity through Sig schnorr compressed with signatures in O(1), and verification is possible at the same time.

Export Latency
As a result of measuring the delay time of the Schnorr signature, it was confirmed that the total delay time of signature verification of Node ic increases linearly in the consensus process because each node verifies the signature O(1) times. Additionally, to insert IC from Network ic to Network mc , IC was uploaded to DFS, and the returned address and the combined signature of all nodes were sent to MC, so the final result, the size of the signature stored, is the size of one signature.Fabric SDK can be executed asynchronously with a delay that includes all processes from propagating a transaction to MC(Hyperledger Fabric), consensus and saving it, so it was confirmed that the delay in the export process takes about 2 s.

IoT-Chain Transactions per Second
As depicted in Figure 16, an experiment was conducted to confirm the change in the TPS according to the number of Node ic in Network ic and the data size. The size of the experimental data was 8, 128, 1K, or 10K bytes. TX was created, and for the TPS calculation, (1) Size Blockchain /Size Tx = Size TxPerBlock and (2) Size TxPerBlock /Time BlockCreation = TPS.
(1) and (2) were used to calculate the TPS. When the data size was 8 bytes, the TPS decreased to 1701, 1634, and 1542 as the number of Node ic increased. In the case of 128 bytes, it decreased to 1586, 1583, and 1487. In the case of 1K, it decreased in the order of 1517, 1453, and 1401. At 10K, the TPS decreased to 1220, 1178, and 1024. In all tested cases, the TPS was kept above 1000.

Conclusions
We have proposed a lightweight blockchain and multilevel blockchain structure for IoT security. The challenges of existing blockchains, such as increasing the blockchain capacity, the consensus algorithm's calculation amount, the network communication volume, and privacy not being guaranteed, can be overcome through this blockchain structure. To solve the problem of increasing the blockchain capacity, the IC that can be operated in the IoT is stored in the DFS for each specific round, and the returned Address ic is delivered to Network mc and stored to save the IC. To solve the problem of excessive computation and network traffic of the existing consensus algorithm, the VRF-based leader node election method, which is a random function, is used, and the average delay time was only 0.004 s. A stable and tamper-resistant embedding method was applied by constructing a multichain architecture and establishing a reliable metadata delivery consensus method and export node between chains (IoT-Chain-Monitoring-Chain). We have proposed a consensus algorithm that is suitable for IoT devices that produce data and generate transactions. It was confirmed that the block propagation time was not affected by the data size. Moreover, in the case of the IC export, when generating Schnorr signatures during the consensus process, the delay time was not affected by the number of nodes. As a result of the total time measurement analysis of the export, only the delay time of the Schnorr signature increased linearly according to the number of nodes. Furthermore, it was confirmed that the upload time to the DFS and the transfer time from Network ic to Network mc were constant. After distributing the IC to solve the privacy problem, Address ic was stored in the MC that was implemented based on the private blockchain HF so that only users who have been granted access to data can access the data. The results of the TPS measurement demonstrated that one of the performance indicators of the blockchain system, Network ic , is suited to devices similar to actual IoT devices. As a result of constructing and measuring the TPS, it was proven to maintain more than 1000 tps. In a future study, the Schnorr signature and data transmission delay time from NetworK ic to Network mc will be reduced to decrease the export time, and a study will be conducted on configuring the optimal route of the routing table of Node export .