# IoT-Chain and Monitoring-Chain Using Multilevel Blockchain for IoT Security
## 4 Architecture
### 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.  
Figure 2: 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}\), \(Node_{ic}\) 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_{expert}\) 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_{expert}\) uploads \(IC\) to \(DFS\) and returns \(Address_{ic}\) and \(Block_{expert}\) with \(Sig_{schnorr}\), and \(BH_{last}\) is created and passed to \(Network_{mc}\). \(Node_{em}\) requests \(Key_{pub}\) from \(CA\), creates \(Key_{schnorr}\), validates \(Sig_{schnorr}\), and if verified, \(Block_{expert}\) 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_{expert}\) stored in the \(MC\). **(6)** The user can access the \(IC\) stored in the \(DFS\) through \(Address_{ic}\) stored in \(Block_{expert}\).