Internet of Things and Blockchain Integration: History
Please note this is an old version of this entry, which may differ significantly from the current revision.

The Internet of things model enables a world in which all of our everyday devices can be integrated and communicate with each other and their surroundings to gather and share data and simplify task implementation.

  • BC
  • BIoT
  • challenge
  • integration
  • trend

1. Introduction

Academics, researchers, and entrepreneurs are all interested in the Internet of things (IoT) these days because of its ability to provide novel services across a wide range of applications such as COVID-19 [1] and intelligent healthcare [2]. The IoT connects diverse things and devices to establish a physical network where processing, sensing, and communication activities are automatically managed without human intervention [3]. In the last decade, there has been significant growth in the number of IoT devices on the market. The number of IoT devices on the market is nearing 25 billion, with predictions that this number will rise to 50 billion by the end of 2025 [4]. To achieve such massive development, new arrangements are required, such as following the centralized IoT–cloud approach. The organization’s system for cloud computing and data processing is referred to as IoT–cloud architecture. Here, the cloud manages and visualizes data flows from IoT devices while processing and analyzing them [5]. Although this approach may work well today, the projected development indicates that new approaches will be required in the future [6,7] due to several challenges of the centralized IoT–cloud approach. The following are some of the problems that a centralized IoT–cloud architecture faces [8,9,10,11,12]: (1) if the centralized server fails, the entire network system is at risk of being paralyzed and interrupted; (2) data fraud makes it difficult for IoT devices owners to trust partners who have oversight and access to the collected data; (3) data maintained in centralized clouds lack accountability and traceability because they depend on a trusted third party to store and retain data; (4) the central architecture is no longer robust enough to handle vast amounts of data and end-to-end interactions as a result of the rapid growth of IoT applications. Furthermore, due to the variety of smart devices on the market, maintaining and updating these devices are almost impossible; (5) since transparency is critical for promoting security and trust when designing next-generation IoT solutions, open-source techniques should be considered; (6) because most safe cryptographic methods need a large amount of processing power and energy, the encryption process is a big barrier due to the heterogeneity and limited compute capacity of IoT devices; (7) due to the constantly increasing number of IoT devices number, relevant IoT ecosystems must accommodate future network development while also processing a huge volume of data exchanged in a high-performance manner. The abovementioned challenges cannot be achieved in centralized IoT–cloud architecture. These problems necessitate a rethinking of the IoT’s structure. Although decentralized systems for enormous peer-to-peer (P2P) wireless sensor networks have been developed in the past to overcome the drawbacks of the centralized IoT–cloud architecture, security and privacy requirements were lacking until the advent of Blockchain (BC) technology [13].
BC can carry out, organize, and monitor transactions provided by several devices without the need for a centralized cloud. To validate a transaction, BC is a decentralized system that does not require trust among participants. Its origins can be traced back to the cryptocurrency Bitcoin system [14]. The integration of BC and IoT (BIoT) may result in several benefits [15,16,17,18] for IoT security. Firstly, it provides a P2P framework that does not require a middle layer such as a third trusted party. Secondly, BC technology has no single point of failure, and, when it is used with smart contracts, it enables more secure transactions, which protects against various scams since smart contracts provide access control and improve stability, confidentiality, and authentication. By ensuring the data are cryptographically encrypted and signed by the rightful sender, BC ensures data confidentiality and authentication. Thirdly, the capacity of the entire network can be expanded due to its P2P nature. Fourthly, BC enables transactions to be performed quickly. Once built and attached to the BC network, each IoT device will get symmetric key pair, eliminating the need for key management and delivery in the BC network. As a consequence, lightweight authentication protocols can be used. The need for computing and memory capacity in IoT devices can be met and organized by these lightweight protocols. Fifthly, the immutability of IoT using data logs stored on BC ensures traceability and transparency. Lastly, due to its tamper-proof design and safe storage, BC may enable the secure release of software updates to IoT devices.

2. Background and Related Work

BC’s novelty is one of the reasons that more professionals and academics are becoming interested in it. The structure and architecture of the BC are discussed and illustrated in the sections below. The basic features of BC, as well as three different types of BC (private, public, and consortium), are then explained in detail. It is important to note that the structure and architecture discussion is centered on Bitcoin, which is the most prevalent and documented BC in the literature. We also cover Ethereum, Hyperledger Fabric (HLF), and Multichain BC-based platforms.

2.1. Blockchain Structure and Architecture

Distributed ledger technology (DLT) and directed acyclic graph (DAG) are revolutionizing the way information is shared [24]. DLT is a P2P network that maintains a decentralized database [25]. The ledger is validated and copied by each node. The BC is one kind of DLT. The BC divides data into blocks, which are subsequently chained together (connected) using an append-only structure. Although it is far from the only DLT data format, the chain-based block structure is the most widespread [26]. DLT may also be implemented using other data structures such as DAG. DAG, like BC, may store transactions. Nodes connected to at least one, but possibly many additional transactions describe these data transactions. Links, on the other hand, are precisely directed, pointing from a previous transaction to a current one. It is also worth noting that because DAGs are acyclic, they do not allow loops [27]. There are no blocks in DAGs, and no mining is conducted, compared to BC. While transactions may authenticate one another, they cannot validate themselves. Furthermore, while entering the DAG, at least one prior transaction must be authenticated before a new transaction may be created. Each new transaction must refer to the previous one [27]. The hashes of the parent transaction are signed by the new transaction, which then integrates them into the new transaction [28]. DAG and BC technologies are combined in hybrid DLTs. Bexam is a hybrid DLT that combines flexible chains with hierarchical nodes to give the security of BC, generating roughly 40 million transactions per second. Bexam is highly scalable and simple to incorporate into large-scale systems. Furthermore, processing resources and power consumption are low. Token technology is also used by Bexam to create transactions [28]. We focus on BC in this paper because it is the most widely used distributed ledger system.
BC is a distributed and mutual ledger that keeps track of a constantly expanding list of blocks that are connected and guarded with cryptography. It is necessary to understand BC elements before diving into the activities of BC. The BC employs a decentralized architecture, with the user and data access permissions separated. The security problems associated with central controls are eliminated with BC-based applications [29]. To maintain data privacy and security, all processes are registered [30]. The BC, in a typical Bitcoin structure, is made up of three technical elements: a cryptographic hash function, a Merkle tree, and a BC. Hash functions are mathematical formulas that produce a lengthy sequence of characters as inputs. All of the previous inputs are combined into a single Merkle Tree, which links all of the transactions into the BC [31]. The block header is made up of the Merkle tree, the block stamp, and the preceding block header, which is a special ID. As a result, the BC uses the block header to track previous record history. The Merkle tree is a data structure for storing key-value pairs that are encrypted.
The Bitcoin BC system creates a secure public data reading process dependent on anonymity. Both nodes can instantly and safely validate and share data inside the device without any interference, thanks to agreements and protocols. The data in the BC system are encrypted and anonymized to different degrees. The most widely used hash functions in BC and cryptocurrencies are the SHA-256 series. There is no requirement to reveal or check each node’s identity or relevant information unless lawfully necessary. Before being written into the BC, data must be checked with a timestamp (used to assure the uniqueness of the transactions). All can write and read data and nodes with maintenance functions in the BC system, which is free and transparent. Via open interfaces, anybody can query BC data and create similar applications.
When any participant or node in the network makes a transaction, it is broadcasted to all nodes in the network after a so-called signing process, which involves two steps: hashing and encryption to generate a digital signature. The process starts by hashing the transaction with some hash function, such as SHA-256, which yields the hash value. Then, the sender’s private key encrypts the transaction, resulting in a digital signature. After that, the transaction, as well as the digital signature, are transmitted to the entire network [32,33]. A BC validator/miner is in charge of checking transactions on the network. After collecting a series of transactions, miners can begin the validation process by performing the following steps to ensure they are legal (i.e., no malicious transactions or double spends) [21]: (1) miners decode the digital signature using the sender’s public key, resulting in a decrypted hash value; (2) the miners use the same hash function to generate a new hash value from the received address; (3) if the current hash value meets the decrypted hash value, the transaction has not been tampered with, and the integrity, verification, and non-repudiation requirements have been met; (4) each miner creates a block of authenticated transactions, and that the validation process is accordingly finished [21,34].
The hardware layer, data layer, network layer, consensus layer, incentive layer, contract layer, and application layer are the seven major layers in a basic BC architecture [26,27,35,36]. The elements of each layer are depicted in Figure 1. In this section, we go through each of these levels and their functions.
Figure 1. BC layered architecture.
Hardware layer: Actuators, sensors, smart devices, controllers, and edge/fog nodes are all represented in this layer. The IoT is made up of these devices connected by a variety of wireless and wired communication protocols.
Data layer: Blocks, transactions, the hash function, the digital signature, and the Merkle tree are all part of this layer. This layer collects IoT data from the lower layer in the form of transactions and encrypts it using asymmetric cryptographic methods, hashes, and digital signatures.
Network layer: This layer serves as a P2P network on top of the communication layer. Only a network architecture that allows peers to trade resources without the participation of a third party allows for decentralization. While all P2P participants can operate as both a requestor and service providers, they can be divided into categories on the basis of the support services they provide, such as database, routing, and mining.
Consensus layer: The distributed consensus necessary to verify a block’s trustworthiness and guarantees that all peers have an accurate ledger copy are managed by this layer. However, owing to network failures, communication delays, or malevolent nodes, agents and nodes may end up with various perceptions of the system’s status (i.e., forks). As a result, avoiding such forks is one of the problems of a consensus method.
Incentive layer: The incentive layer is the heart of the BC network since it includes economic factors such as Ether (ETH) (a cryptocurrency that was created as a result of the confirmation of transactions on the Ethereum), Zcash (a protocol that provides a decentralized cryptocurrency, to store funds and generate a new private key for every new account [21]), and allocation methods to incentivize nodes to give their time and effort to data verification.
Contract layer: This layer is in charge of digital money, as well as the design and management of smart contracts. Algorithms, smart contracts, and scripts are applied to allow more sophisticated transactions.
Application layer: This layer offers services across a wide range of industries, including logistics, healthcare, IoT, and smart cities.

2.2. Blockchain Platforms

In general, two major categories can be identified for BC: permissionless and permissioned [25,26,27].
Permissionless: This form of BC, also known as public BC, permits transactions to be viewable to all nodes. To authenticate a transaction, every node in the network can participate in BC consensus. The node does not require authorization, and it may be unknown to the rest of the network. Nodes in a permissionless network support and collaborate on a large scale. Each transaction is associated with a processing fee, which offers an incentive for peers looking to add additional blocks to the BC [37]. Because altering the contents of the permissionless BC would be prohibitively costly, it is immune to hacking. Each transaction comprises an incentive (i.e., transaction fees) to the peer that approves the transaction into a new block because the decentralized consensus involves hundreds of other peers [36]. Bitcoin is the most well-known permissionless cryptocurrency. Another well-known permissionless BC is Ethereum.
Permissioned: This type of BC network may be classified as either private or consortium BCs.
  • Private: These BCs are generally located in the heart of a single company that can verify transactions. Transactions may be read by the public or authorized parties. Private BCs operate without the need for money or tokens, and their transactions are fee-free [38]. Because blocks are broadcasted by surrogate nodes, a private BC is not as impenetrable to tampering as a public BC, but the firm may roll back its BC at any point in time. Multichain is an example of a private BC. Multichain is a Bitcoin fork with several features, including rights management, rapid setup, and data streams [39].
  • Consortium: This type of BCs is managed by a small cluster of users from outside the group who are not allowed to confirm transactions. While the whole public may view transactions, only members of a limited group can write them. HLF is the most widely used and well-known federated BC. There are two sorts of HLF nodes: validating peers and nonvalidating peers. Validating peers are in charge of verifying transactions, establishing agreements, and keeping the ledger up to date. Nonvalidating peers can examine and verify transactions [36,40].
Due to the benefits that this technology provides, BC systems and implementation have recently arisen from a wide range of fields such as IoT, transportation, finance, eHealth, and energy applications. In the sections below, we survey some of the most widely used BC platforms. Since there are many platforms and they are constantly changing, it is difficult to study them all; thus, only the most common and most appropriate IoT domain platforms are surveyed (i.e., Bitcoin, Ethereum, HLF, and Multichain) [41]. Because investing in a specific BC technology is a mid- to long-term commitment, these are quite high levels of support. Some current systems are supported by a large number of individual developers, while others are supported by companies. The Ethereum Foundation, for example, is a nonprofit organization established in Switzerland, while the Bitcoin project has a large open-source development community [41]. IBM and the Linux Foundation support HLF. It is worth noting here that different authors refer differently to the specifications of the four platforms. The summary in the table is based on what was reported in [10,13,42,43,44].
Since many C platforms are built on Bitcoin BC, they share features such as using the proof-of-work (PoW) consensus protocol, not having specific hardware to generate new blocks, and being written in C++. All platforms use smart contracts, except for Bitcoin which does not use smart contracts. All the platforms do not use special hardware preparations, while only HLF and Multichain provide ID and key management, enable data confidentiality, and require trusted validators to validate the transactions.
It is essential to discuss the concept and functions of the smart contract in the context of BC platforms because they are a requirement of many BIoT platforms [45]. A smart contract is defined as a computerized protocol that implements a contract’s terms [46]. A smart contract’s ability to implement or self-execute contractual clauses is one of its most important characteristics [47]. Furthermore, smart contracts have greatly added to the energy of BC, and this integration has resulted in the second generation of BCs (i.e., BC 2.0). In a trustworthy environment, a mix of automatically executed contracts and no centralized oversight has the potential to revolutionize the way business is conducted today [47]. In essence, the smart contract code is stored on the BC, and each contract is known by a unique address, which users may access by sending a transaction to [28]. The BC consensus protocol ensures that the contract is executed correctly. Smart contracts provide several benefits, including cost savings, speed, accuracy, performance, and openness, which have prompted the development of a slew of new applications in a diversity of fields [48]. While Bitcoin includes a simple scripting language, it has proven inadequate, prompting the development of modern BC systems that provide Smart contract features [49].
Ethereum, the most common smart contract BC network, is a BC with a Turing-complete programming language that enables smart contracts and dispersed applications to be defined. Ethereum contracts are written in a stack-based bytecode language at a basic level called ‘‘Ethereum Virtual Machine (EVM) code” [50]. Financial smart contracts also require details about current events and states in the real world. The so-called oracles have this information. These institutions are essential for the efficient incorporation of smart contracts into the real world, but they add to the challenge by requiring authentication, confidentiality, and oracle trust [51].
The fact that all four most common BC platforms are open-source is a major factor in their success. While HLF and Multichain can provide high scalability and authentication, Bitcoin can provide low levels of authentication and scalability, and Ethereum can provide medium levels of scalability and authentication. Both Bitcoin and Ethereum are linked to a 51% attack level, while this value is 33% for HLF and Multichain. The security level provided by Bitcoin and Ethereum is low since the data are accessible to the public; however, the level is medium for HLF and high for Multichain. The privacy level is high when using HLF and Multichain, but low for Ethereum and Bitcoin since there is no authentication applied and they are publicly accessible.

This entry is adapted from the peer-reviewed paper 10.3390/fi14070216

This entry is offline, you can click here to edit this entry!