eBC System Architecture

In real-world application domains, the IoT design architecture is often distributed. However, a conventional distributed IoT architecture lacks a distributed management framework that is both secure and scalable. If carefully designed, blockchain network architecture exhibits both of these features. In this chapter, we propose such a solution in the form of an edge-based blockchain (eBC) system architecture. Using smart contracts, the proposed architecture also possesses features of synchronization, fault- tolerance, transparency, and enforcement agreements. As shown in Figure 10.6, our proposed eBC system consists of the layers, including a local IoT device layer, an edge computing layer, and a cloud layer, which are described as follows.

• • Local IoT Device Layer. This layer consists of all the IoT devices, also called nodes, w'hich could be as simple as sensor devices for weather, smart metering, etc., or more complex, as video cameras, etc.
• • Edge Computing Layer This layer could include the network gateways that are responsible for collecting data from IoT devices and passing them on to the cloud, either directly or after some basic processing, such as information extraction or edge-based machine learning. The network gateway architecture is designed using Docker containers, such that DNN (deep neural network) models. BC (blockchain) modules, and manager modules are containerized and deployed into different containers. This architecture allows for dynamic orchestration by Kubernetes (in the cloud layer).
• • Cloud Layer This layer is responsible for the overall management of the containers in the edge computing layer, the deployment of containerized applications into the containers, including deep neural network and blockchain modules, and the training environment for DNN models.

FIGURE 10.6 Overview of the Proposed Edge-Based Blockchain Network [There are three layers, where the Local IoT devices Layer sends data to the Edge Computing Layer then synchronizes it to the BC container on the Cloud Layer.]

The proposed edge-based blockchain network is deployed in one or more containers in the edge computing layer of the overall architecture. Figure 10.7 depicts the role of our proposed edge-based blockchain network. Within the network, there are two connectors, namely, the BC connector and the edge connector. The BC connector is responsible for managing local IoT devices, while the edge connector is responsible for providing services for edge computing. In the following, we describe the functions of the two connectors.

• 1. Role of Blockchain Connector: The blockchain connector is mainly responsible for the services that are required to maintain a blockchain system running in an IoT network, including permission management, transaction validation, access control, digital signature, and invoke/query verification, as detailed in the following.
• • Permission Management Conventional blockchain systems such as Ethereum and Bitcoin are public, which means that any node can participate in the consensus process to order the transactions and to bundle data into blocks. However, our proposed eBC system is permissioned, that is, only specific nodes with permission can participate in the consensus. We use the Hyperledger Fabric, which is permissioned. In our permissioned blockchain system, permission management is used to manage the identity of its participants (IoT devices or Blockchain nodes). In our system, only the Orderers in each organization are permissioned, so that they can participate in the Raft consensus (leader elections). Because IoT systems require high

FIGURE 10.7 Overview of Role of Blockchain Network in Edge-based IoT Security [Blockchain Network contains the BC Connector and Edge Connector being responsible for Local IoT devices and Edge computing services.]

scalability and performance, permissioned blockchain is the correct choice, as these kinds of blockchain systems are more efficient in terms of consensus, more cost-effective, and provides private membership. The negative aspects of permissioned blockchains, such as partial decentralization (as opposed to full decentralization) and lower security, can be accommodated by careful design, as in our proposed system.

• • Transaction Validation: For successful deployment of blockchain in the IoT, instead of the complex transaction validation process in Bitcoin, our edge- based blockchain system adopts a more flexible execute-order-validate approach. Before a transaction is committed to the ledger in the blockchain, it needs to be executed by running a smart code (chaincode in Fabric), ordered through a consensus protocol (Raft here), and validated (endorsed by some predefined peers). Some features that make this deployment suitable for the IoT include (a) efficient endorsing, where a transaction needs to be endorsed by only a subset of peers, and (b) parallel execution, where transactions can be endorsed in parallel by different peers.
• • Access Control: In a permissioned blockchain, access control is one of the critical mechanisms used to deal with the protection and privacy issues in the IoT. With access control, the users of IoT applications have full access to their data and can control how the information is shared. Our method uses access control lists (ACLs) to manage access to resources by associating a policy with the resource. A policy specifies a rule that evaluates to true or false, given a group of identities and the target resource. Hyperledger Fabric includes a variety of default access control lists. To access a resource with an associated policy, the accessing identity (or set of identities) needs to be checked against the policy. There are two types of default policies, namely Signature and ImplicitMeta. Signature policies specify the combination of endorsing peers needed for signing a resource requesting transaction before the transaction is allowed access to the resource. ImplicitMeta policies aggregate the results of policies, such as Signature policies.

• • Digital Signature: The confidentiality, integrity, and authenticity (CIA) of the data in an IoT needs to be ensured. Confidentiality can be ensured by access control. Integrity is ensured by the hashing mechanism in block- chain. Authenticity is ensured in our system through the notarization of documents using digital signatures. Each IoT node (blockchain user) enrolls with the Fabric CA and collects the signing key and an authentication certificate (e.g., X.509), stored in its own wallet. For each document (or data) to be signed, a hash (e.g., SHA-256) is computed from the document and a signature of the hash using the signing key from the user’s wallet. For authentication, the document to be verified is obtained from the ledger. A hash is computed from the document and compared to the computed hash, which is obtained by decrypting the signature using the public key in the authentication certificate. The blockchain connector thus implements the authentication procedures for the local IoT edge devices.
• • Invoke/ Query Verification: The blockchain connector also provides the chaincode services for IoT nodes, including the invoke and query functions for application logic. For example, in the smart meter application, meter data to be logged into the ledger consists of Meterld. Timestamp, Status (normal/ abnormal). Consumption, and Gatewayld, which are explained in detail later in the chapter. Our chaincodes are implemented in the GoLang language. Create, update, and delete operations are all encapsulated within the invoke/ query method. IoT security policies are implemented as TLS certificates in the X.509 public key certificate format. Different channels are used for different purposes or organizations, depending on the IoT application.
• 2. Role of Edge Connector: The edge connector is mainly responsible for managing the application logic in an IoT network, including mainly the edge functions, such as synchronization, processing request, and historical record/log, as detailed in the following.
• • Sychronization: An inherent characteristic of a blockchain network is state replication, where the participating nodes can always update their ledger states to the latest committed version. This characteristic is achieved via a blockchain’s sync mechanism, where a node in the network communicates with other nodes to request and import the full history of blocks on the ledger. It involves multiple components of the kernel, notable among them being: the peer-to-peer protocol, which enables communication, and the consensus algorithm, which ensures that all nodes agree on how the information in each block is interpreted. For IoT deployment, the synchronization service helps maintain consistency across all the nodes at the edge layer. In other words, the conventional method of using cloud-based MQTT servers for schronization (publish/subscribe topics) can be fully replaced with the more secure and scalable, distributed blockchain sychronization mechanism. This is also one of the innovations of this work.
• • Processing request: The edge connector provides service for processing requests from the application logic, in the form of smart contracts or chaincodes. Security is ensured in the processing request, because each communicated message is signed by its sender IoT node and validated by the endorsing peers, before being committed by the leader node. Thus, even if there exists a malicious leader, it cannot compromise the network, because synchronization from other nodes will eventually lead to the eradication of the effects of the malicious leader’s attack, such as man-in-the-middle, impersonification, etc.
• • Historical Record/Log: To support client application requirements, the proposed edge-based blockchain system design provides services to access and query transaction history. This service focuses on the precision and reliability with which the system can record, prove, and audit events related to data in the ledger.