A Lightweight Blockchain Framework for IoT Integration in Smart Cities

Smart cities heavily rely on technological enablers for their success, and more specifically on the IoT. This network, which will reach billions of components, now suffers from several constraints. In recent research, the blockchain has been proposed to provide answers on the limits of the centralized model, and on security. The integration of blockchain and IoT, however, still has issues that are being resolved, which are energy consumption, computing capacity, and storage capacity, due to the low capabilities of connected objects. In this article, we present our lightweight framework that we implemented for the integration of blockchain and IoT, and simulating on machines close to the configuration of the majority of current connected objects.


Introduction
The IoT is a real accelerator for the development and success of smart cities, allowing it to migrate all components of the city to the digital world by connecting these physical objects and endowing them with digital capabilities. Connected objects will reach billions in 2020 according to Gartner [1], and they have low, to medium, then high capacities; and they are provided by different suppliers. These factors pose the problems of network bottleneck, adapting to advanced standards of security, standardization, and homogeneity [2]. Blockchain technology provides solutions for several fields of application through its decentralization, disintermediation, transparency, and security features [3]. Its application integrated with IoT has been the subject of varied research, including Smart Transportation [4, Smart Home [5], Smart healthcare [6], and smart agriculture [7]. The constraints encountered during this integration are mainly: energy consumption, computing capacity, and storage capacity to access and participate in the blockchain network with devices, the majority of which are of limited capacity.
The different proposed implementations can be classified under the following three categories of architecture models [8]: (i) The IoT to IoT architecture, whose devices can communicate with each other and then communicate with the blockchain network via capable devices ( Figure 1).   In this paper, we propose a lightweight blockchain framework, which brings decentralization, security and disintermediation to the IoT. Initially, we put in place the main operating bricks of a Blockchain, with the necessary interfaces for IoT devices, all implemented by the Node.js framework.

Proposed Framework
Our aim is to arrive at a lightweight blockchain framework for computing and processing data from a consumer point of view, integrated with IoT to meet the expectations of smart cities. This starting model that we are proposing is part of both an IoT to IoT and IoT to Blockchain architecture, in which IoT devices participate in the blockchain network, and other devices are connected directly to these blockchain devices when their capacity is not sufficient. Node.js was chosen as the framework for implementing the blockchain application of the participating nodes. This framework is known for its richness in development tools, and for its few requirements in terms of machine resources. The consensus implemented in this initial model is the Proof of Work, a security and integrity mechanism implemented by Bitcoin. Since this mechanism is known for its very high computing capacity requirements, we have chosen the validation of the block by the Binary Hash algorithm instead of the Hash, which is less resource intensive. This consensus has been put in place in a flexible manner, in order to easily replace it with another more efficient mechanism, depending on the context of application.

Architecture
The model we offer allows devices in the IoT network to connect to the Blockchain network. We define 3 roles for a device to participate in the IoT and Blockchain environment. (i) The Node Validator role, where the device holds its key pair, stores the Blockchain register locally, creates signed transactions, and participates in the validation of newly created blocks according to the consensus. (ii) The role of Node Wallet Only, whose device does not participate in the validation of blocks, but can create signed transactions, as well as storing the blockchain ledger locally. This role is justified for devices that do not have sufficient computing capacity, or sufficient battery power, or timely availability to demonstrate proof of consensus work. (iii) The third role is Thing Only, whose device does not participate in block validation, does not have a key pair and therefore cannot create signed transactions. On the other hand, it can store the ledger of the blockchain locally by synchronizing itself with the other nodes; through it cannot store it, it solicits the reading and writing from the other nodes with the roles of Node Validator or Node Wallet Only, via the interfaces implemented in our architecture. We can say that it is a hybrid architecture between the IoT to the IoT and the IoT to the Blockchain (Figure 4).

Blockchain Node's Components
The blockchain node is an application that can play the role of Node Validator or Node Wallet Only. It consists of a Blockchain Application in order to provide the main functionalities, namely the storage of the ledger, the security keys, the signature, the control and the validation, and the consensus mechanism ( Figure 5). The nodes form the blockchain network by connecting to each other through the Peer to Peer Websocket interface. The blockchain node also implements the connection interfaces with connected objects, the most used at the moment and which are: MQTT, CoAP, and REST API.

Logic
The process of running the solution from starting a node is described by Algorithm 1, shown below: The pseudo code of the block validation logic according to the used PoW consensus is described below: Pseudo Code 1 PoW Block validation Input: lasgBlock, Data Output: Block{timestamp, lastHash, hash, data, nonce, difficulty} Declare: hash, timestamp, nonce, difficulty Initialize: nonce := 0, difficulty := lastBlock->difficulty 1 Do 2 nonce := nonce+1 3 timestamp := currentTime() 4 difficulty := adjustDifficulty(lastBlock, timestamp) 5 hash := hash(timestamp, lastHash, data, nonce, difficulty) 6 While (Substring(hash, 0 to difficulty) != Repeat ('0', difficulty)) As described by the PoW consensus, the difficulty of performing proof of work increases with the growth in the overall processing capacity of the Blockchain network. The adjustment procedure has been implemented by using the pseudo code described below:

Simulation and Results
We simulated our proposed framework on a blockchain made up of 10 nodes and a connected objects simulator. Each node of the blockchain is a server under Amazon Linux 2 AMI, configured with a minimum of necessary resources close to an IoT component such as Raspberry Pi 2. The nodes of the blockchain are t2.micro instances (Variable ECU, 1 vCPU, 2.5 GHz, Intel Xeon Family, 1 GB memory, EBS only). We simulated the interactions of connected objects by Curl requests in Shell Bash scripts, which send data to the nodes of the blockchain through the REST API interface. We ran a transaction recording scenario on the different nodes, with a block validation triggered every 5 minutes. Since the computing capacity of the entire blockchain remained the same during the simulation phase, the difficulty of PoW stagnated in 4.
We recorded the CPU and RAM consumption of the Node process of the blockchain application by using the System information 4.0 module, during the validation phase of the block, and in the replacement phase of the local chain during the synchronization between nodes. This moment of replacing the local chain by the node is important from our point of view, because we will base our future work on its improvement, with a new model of organization and prioritization of data.
In the graph (Figure 6), we show the CPU usage per Node Blockchain process, during block validation. There is a frequent exceeding of the capacity of the resources initially allocated for the node, going up to 500%, by drawing available reserves in the cloud. The calculation of Binary hash responding to the difficulty of PoW has also been shown to be CPU resource intensive, and in the case of a hardware component with inelastic and limited resources, like the AWS Cloud, the model will arrive at its limits without being able to offer good performance. RAM usage remained between 7% and 10%. For the chain synchronization function after block validation, the graphs (Figure 7) show stable and low consumption of CPU and RAM. This is because of the low degree of complexity of the synchronization function.
This will not be the case when the size of the blockchain register is very large. For the validation of the contents of the register, each node will have to recalculate a large number of hashes in the order of the size of the chain. The nodes must also all have a large storage capacity when the amount of data is important.

Conclusion
In our current work, we proposed an initial lightweight blockchain framework to meet the constraints of IoT objects, and we implemented it to verify these limits with the PoW consensus. The only implementation of a blockchain with the node.js framework is not sufficient with the PoW binary hash based consensus, and requires optimization at the level of the consensus mechanism and the ledger storage mechanism.
Our future work aims to improve this initial framework with a consensus model and data storage more suited for the context of IoT with limited resources.