TY - JOUR
AU - Antonelli, Fabio
AB - Abstract Within internet of things (IoT) research, there is a growing interest in leveraging the decentralization properties of blockchains, towards developing IoT authentication and authorization mechanisms that do not inherently require centralized third-party intermediaries. This paper presents a framework for sharing IoT data in a decentralized and private-by-design manner in exchange for monetary services. The framework is built on a tiered blockchain architecture, along with InterPlanetary File System for IoT data storage and transfer. The goal is to enable IoT data users to exercise fine-grained control on how much data they share with entities authenticated through blockchains. To highlight how the framework would be used in real-life scenarios, this paper presents two use cases, namely an IoT data marketplace and a decentralized connected vehicle insurance. These examples showcase how the proposed framework can be used for varying smart contract-based applications involving exchanges of IoT data and cryptocurrency. Following the discussion about the use cases, the paper outlines a detailed security analysis performed on the proposed framework, based on multiple attack scenarios. Finally, it presents and discusses extensive evaluations, in terms of various performance metrics obtained from a real-world implementation. 1. Introduction The internet of things (IoT) has experienced exponential growth and is hailed as a revolution to industry and modern life [1]. The IoT forms a network of interconnected devices that collect data from their surroundings for automated tasks and services. Despite the benefits IoT promises, the sheer volume of data generated and the methods with which these data are handled raise privacy concerns [2]. Current IoT services operate on a centralized client-server access model, where user data are analysed by service providers for automated IoT services. This centralized form of service provision can compromise IoT users’ personal information and can reveal behaviours and preferences. Above all, third-party IoT service providers can sell users’ data to advertisement agencies and mass-monitoring programs [3]. Effectively, IoT users involuntarily have to entrust and surrender their data to centralized service providers. In a world where data are currency, IoT users do not have the opportunity to exercise ownership or control of their data and the means to monetize their sensor data [4]. In current IoT cloud-based architectures, users surrender their data while gaining access to third-party services. Data privacy regulations can enforce service providers to declare the quality and quantity of the data being harvested, but, more often than not, these declarations go unnoticed in a lengthy terms and conditions document. In distributed cloud services provided by the edge or fog computing, the security mechanisms over the edge remain disparate and controlled by third-party entities, thus further complicating the design of a truly private-by-design architecture for the IoT. A solution to introducing private-by-design monetization mechanisms for IoT users is to develop a decentralized, privacy-preserving access model for the IoT. Democratizing IoT data and allowing users to have authority over their wealth will give way to revolutionized business models. Blockchains offer a fundamental rethinking for developing decentralized transaction-based network applications and have features that enable authentication and authorization without the need for a central authority. Therefore, blockchains are being widely researched as a conduit to decentralize IoT services as well as the IoT in general [5]. Blockchains emerged as the underlying technology for the cryptocurrency platform Bitcoin [6]. Blockchains are decentralized ledgers that maintain records of transactions that occur over a network. These transactions involve exchanges of digital tokenized assets. This ledger is replicated over nodes of a peer-to-peer network, and the canonical shared state of the network is maintained through algorithmic consensus between blockchain peers, thus eliminating the need for a single, trusted and centralized authority. The reason for the blockchain’s recent popularity is in its immutability, security and decentralization features. The following are the potential benefits blockchains can bring to the IoT as a virtue of their inherent design properties. The shift from centralized infrastructure to a blockchain-based IoT greatly enhances fault tolerance and eliminates singular points of failures. Blockchains can provide a truly decentralized secure fabric for the IoT, since security mechanisms in the existing IoT edge still remain non-uniform, disparate and under the control of third-party authorities. Blockchain-based solutions eliminate the need for centralized third-party authorities for file handling, authorization, authentication and service provision. In a blockchain-based IoT, edge devices would be able to democratically communicate to other edge devices without centralized intermediaries. Transactions recorded in a blockchain are signed, time-stamped and immutable; therefore, blockchain networks provide a transparent, accountable environment for conducting exchanges. In the IoT, this can translate to perform identity management and data exchange and monetization. In private blockchain deployments, this design virtue can translate into delivering a secure medium for edge segments without relying on centralized authorities, such is the case with existing identity management mechanisms. Terms and conditions for engaging in blockchain transactions can be enforced using smart contracts. Through these terms and conditions, IoT users can implement access control and perform negotiations for microtransactions. Since smart contracts do not belong to a single authority and are stored within the shared state of the blockchain, the need for entrusting third parties is eliminated. Apart from developing applications entirely through smart contracts, application code can be containerized, which can be traded as a commodity over the blockchain, with secure terms and conditions enforced by smart contracts. A decentralized IoT can empower IoT users to use containerized applications while exercising control over their data. However, the challenges associated with integrating blockchains with the IoT are those of privacy, scalability and resource constraints [5, 7]. Interconnecting IoT devices by making them a part of a blockchain network proves to be a hurdle to scalability. Every data generation event originating in every IoT device would result in a volume of transactions a public blockchain network cannot scale up to, since all transactions are logged in the blockchain through distributed consensus. IoT edge devices are resource-constrained; therefore, they are limited in their capability to engage in blockchain consensus. Furthermore, blockchains achieve privacy and accountability by having the entire record of transactions replicated within all participating nodes; therefore, having all data generation events logged in a publicly accountable blockchain still has privacy implications. The contribution of this paper is a framework that aims to provide scalable, private and secure monetary services for the IoT, while leveraging the unique capabilities of decentralized accountability, authentication and authorization offered by blockchains. Our proposed framework is designed to securely exchange IoT data for monetary services, and it is built on a tiered blockchain architecture to enable horizontally scalable deployments, as seen in Fig. 1. The framework utilizes the decentralized application stack of blockchain smart contracts and peer-to-peer data storage and sharing techniques, to provide a medium for private-by-design data transactioning. The framework is built on a multi-tiered architecture of public/private blockchains for delivering decentralized accountability and security and privatizing IoT edge segments. We propose computationally capable IoT gateways for engaging in the blockchain networks, to alleviate the load of resource-constrained edge devices. We have discussed in detail how the private/public blockchain networks are protected by compromised edge devices. The proposed framework is an application-agnostic, private-by-design solution that allows IoT users to exercise discretion upon how their IoT data are shared and with whom. Figure 1. Open in new tabDownload slide The proposed tiered public/private blockchain architecture. Figure 1. Open in new tabDownload slide The proposed tiered public/private blockchain architecture. To demonstrate and analyse the proposed framework’s usability in real-world scenarios, we developed a real-world implementation and explored two use cases. One of the two use cases is an IoT data marketplace, where IoT users can participate in a data-driven economy by monetizing their sensor data and third-party entities can purchase IoT data for crowdsourced training of machine learning models or market analysis purposes. This use case is meant to demonstrate how IoT users themselves can reap the benefits of data ownership, while maintaining control on how much of their data is made available to third parties. The second use case is a decentralized connected vehicle insurance, where insurance companies can interact with customers in a secure fashion and offer them flexible premiums through usage-based insurance (UBI) schemes. Users do not have to surrender all their usage data to the insurance company and can choose to send pertinent data in the event of an accident, for fast processing of insurance claims. We are implementing this use case to shed light on the security provided by the framework for delivering monetary services using IoT data, without centralized data-handling authorities. As a demonstration of the framework’s security features, we have included a security analysis and a discussion on the design considerations within the framework, to provide confidentiality, integrity and availability. The remainder of this paper is organized as follows. Section 2 outlines the architecture and components of our proposed framework. Section 3 delves into the design specifics and working principles of the decentralized access control mechanism, and it illustrates how the proposed framework can be implemented for two distinct monetary service use cases. Section 4 contains a security analysis conducted using the connected vehicle insurance use case, and Section 5 details a performance analysis we conducted on the functioning of the framework using various performance metrics. In Section 6, we discuss previous related work in developing blockchain-based frameworks for monetizing the IoT. Finally, in Section 7, we summarize our findings and discuss future research directions. 2. The Proposed Blockchain-Based Framework Building a blockchain-based solution involves tackling a four-way trade-off between decentralization, scalability, privacy and latency [5]. While public blockchains offer great accountability and non-repudiation, a single, monolithic blockchain may not be suitable in use cases where transaction events may be required to remain private within a consortium or federation. To complicate things further, there is a scalability/throughput trade-off between public and private blockchain deployments. While private blockchains provide higher transaction throughput, the voting mechanisms involved in private blockchain deployments severely limit scalability. The proposed framework is built on a tiered architecture of public and private blockchains and is based on a decentralized application stack of smart contracts [8] for network control, InterPlanetary File System (IPFS) [9] for IoT data storage and BigchainDB [10] as an immutable and auditable database. In this section, we outline the decentralized technologies used in developing our proposed blockchain-based framework, as well as the network architecture designed to mitigate the privacy and scalability concerns that arise when integrating blockchains with the IoT. Blockchains, along with decentralized storage mechanisms used in a multi-tiered architecture form the basis of the framework for monetizing IoT data and securely availing IoT services involving monetary transactions. 2.1. Core components of the framework 2.1.1. Blockchain Blockchains are distributed time-stamped records of all network transactions, replicated over the nodes of a peer-to-peer network. Block validator nodes participate in consensus algorithms, for validating and appending new blocks to the blockchain, as well as maintaining an immutable, canonical shared-state of the blockchain. Transaction information is grouped together into blocks, and each block is linked to its predecessor block, similar to a linked list. In order to perform a modification attack, an adversary would have to alter the contents of a single block, as well as all the subsequent blocks, over a majority of the blockchain peers at the same time. Therefore, to further the degree of decentralization, and for robustness and security in blockchain deployments, it is necessary to have a large block-validator pool [5]. For the proposed framework, the basic components required are the blockchain itself, smart contracts for programmable service-level agreements and decentralized file storage for hosting the application data. Further pertinent details on blockchains and the specific consensus algorithms used for the proposed framework are discussed below. Transactions and addressing: each peer |$y_r$| on the blockchain has a public/private keypair |$\{k^r_p, k^r_s\}$|⁠, which is used for addressing and creating digital signatures on each transaction, for guaranteed non-repudiation. Since these keypairs are not associated to real-life identities, blockchains offer pseudonymity to its users [7]. Signed transactions are made for transferring cryptocurrency tokens or interacting with the application binary interface of functions written in deployed smart contracts. Smart contracts: a smart contract is simply a piece of code stored in the blockchain itself and is able to enforce programmatic terms and conditions over transactions occurring in the network. In our proposed framework, for private-by-design IoT data transactioning, we use smart contracts to enable IoT users to decide when and how much data to share with entities of their choosing, in exchange for monetary incentives and/or services. Consensus algorithm: the most commonly used consensus algorithm for publicly deployed blockchains is proof-of-work (PoW), commonly known as ‘mining’ [6]. Miner nodes group new transactions into blocks and engage in a race to find a nonce that, when hashed with the candidate block, produces a resultant that satisfies a predetermined difficulty level. The nonce serves as a verifiable proof of computational work done. The PoW consensus algorithm provides fault tolerance of |$n \geq 2f+1$|⁠, where |$n$| is the total computational power of the network and |$f$| is the computational power of an adversary to the network. In public blockchains, the throughput can be evaluated using the parameters of block size and block interval, where block interval is the average time required to publish a new block [11]. The average transaction throughput can thus be theoretically calculated by $$\begin{align}& \Omega(S_{b}, T_{i}) = \frac{\left [ S_{b}\, /\, \chi \right ]}{T_{i}}, \end{align}$$(1) where |$S_{b}$| represents block size, |$T_{i}$| represents the average block interval and |$\chi $| is the average transaction size. For our framework, we used proof-of-authority (PoA), a variation of PoW, which limits mining only to delegated block validators. In the framework, the compromise for scalability is that the block validation is not fully decentralized and open to the public; however, with a sufficiently large validator pool, the immutability of the blockchain contents will remain secure. For private blockchains, we used a variation of the voting-based practical Byzantine fault tolerance (PBFT) consensus algorithm [12]. Under PBFT, new candidate blocks are validated through multiple rounds of voting among block validators, instead of expending computational effort. PBFT is computationally efficient, with a fault tolerance of |$n \geq 3f+1$|⁠, where |$n$| is the total number of validating nodes and |$f$| is the number of compromised or faulty nodes. PBFT is only suitable for private deployments, where participants are known to one another. Furthermore, PBFT blockchains are only suitable for private deployments since the high network overhead generated severely limits the scalability of the validator pool. For applications involving data storage and transfer, relying on a blockchain as-is is highly inefficient, since storing data onto the blockchain will bloat it and will cause high network overheads [13]. Therefore, for distributed file storage, off-chain decentralized file storage mechanisms are an important addition to the decentralized application stack. Common examples of such storage systems are the BitTorrent protocol [14], IPFS [9] and Provable1 . 2.1.2. InterPlanetary File System The IPFS is a peer-to-peer network and protocol for storing and sharing data [9]. Using IPFS is particularly advantageous in our case, since files stored on IPFS are content-addressed. In order to deliver a file from one point to another, one needs only to send the cache-friendly hash of the file in an Ethereum transaction, so as to let the other person retrieve it through IPFS. 2.1.3. BigchainDB BigchainDB is a distributed database with blockchain characteristics [10]. BigchainDB boasts scalability and immutable record-keeping, and in our framework, we use BigchainDB to complement the decentralized application stack of Ethereum and IPFS. BigchainDB is essential for the framework, to maintain data integrity in private blockchains. We maintain a database of the block hashes from private blockchains that contain users’ personal IoT data in BigchainDB. The entries to the database serve as an immutable record of the private blockchain contents, and users can provide these records as auditable proof of the integrity of their private blockchain contents. 2.2. Tiered blockchain architecture Blockchains, from a data structure perspective, are distributed databases with decentralized consensus on the entries being added to them. In networks generating data, a blockchain can be used to create an immutable log of all data generation and access events, while smart contracts can be used to program responses to certain events or to enforce service-level agreements, as well as access control policies [15]. Subsequently, this log can be used for transparency and accountability. However, this poses unique challenges in the IoT domain. First, since all records in publicly deployed blockchains can be read by every node in the network, issues related to privacy arise. While blockchain addressing does provide pseudonymity, inferences can be made about the accounts that generate specific kinds of data. In the IoT, prevalent privacy issues pertain to third-party entities monitoring user behaviour and preferences, and logging all IoT data generation events on a public blockchain will lead to privacy breaches [5]. Second, for IoT applications, to maintain IoT data records in a single publicly deployed blockchain severely limits scalability. Considering the sheer amount of traffic generated by the IoT, the added latency of the consensus algorithm will be a bottleneck to record every IoT data generation event. Other than this, it is worth recalling that blockchains are linearly growing data structures. Therefore, to log every single IoT event on a public blockchain will cause an explosion in the storage requirements of blockchain full nodes. To address these limitations, we have designed and implemented a two-tiered architecture consisting of a public blockchain at the overlay core tier and multiple private blockchains at the edge tier. Figure 2 illustrates the tiered architecture of public core-tier and private edge-tier blockchains, where each edge-tier blockchain is connected to the core-tier blockchain through an inter-blockchain gateway (IBGW) node, which is capable of issuing transactions over both blockchains. This public/private implementation allows for a functional split in responsibilities allocated to the public and private blockchains. The private blockchains can be used as a time-stamped log of the high-traffic data generation events within IoT edge federations and to define fine-grained access control policies on a per-block basis, while the public blockchain can be used as a secure fabric for orchestrating data sharing events and to perform monetary transactions with requester nodes present in the public blockchain network. Figure 2. Open in new tabDownload slide The two-tiered public/private blockchain architecture. Figure 2. Open in new tabDownload slide The two-tiered public/private blockchain architecture. 2.2.1. Privacy and scalability benefits The split in functionality over the private and public blockchains has 2-fold benefits. Firstly, all data generated within edge-tier blockchains can be kept secluded until the edge-tier blockchain owner chooses to express parts of their data in a fine-grained fashion to selected nodes on the core-tier blockchain, which makes the architecture private-by-design. Secondly, one of the key contributions is the horizontal scalability afforded by this architecture. While the core-tier blockchain only logs access events occurred over the public tier, the validator nodes for one edge-tier blockchain do not have to validate data generation transactions occurring in a separate edge-tier blockchain. The effect is similar to sharding [16], where validators manage isolated shards of the blockchain network. This split of responsibilities at the public/private tiers significantly reduces the overhead on the publicly deployed core-tier blockchain and makes the design of the architecture more edge-centric. Private edge-tier blockchain owners can choose to join or leave the public core-tier blockchain network in a modular fashion. The framework is horizontally scalable, since separate public networks can be set up to cater for multiple use cases and industrial verticals. Using the public core-tier blockchain as a medium for transferring data has the benefit of decentralized security provision, since signed transactions allow member nodes on the core-tier blockchain to communicate with one another securely without relying on certificates or centralized authorizing entities. Applications built on public blockchains can make use of cryptocurrencies with actual monetary value to create monetized contracts for sharing data. 2.2.2. Securing the IoT edge Splitting responsibilities between the private and public blockchains in the tiered blockchain architecture has its benefits in securing the IoT edge. The edge nodes that maintain the private blockchains are responsible for registering and authorizing IoT devices. IoT devices are resource constrained, so they are simply registered as transaction issuers to the private blockchain, thus alleviating any computational or storage requirements on IoT devices. Publicly deployed blockchains are resistant to denial-of-service (DoS) attacks because each transaction issued carries a monetary cost, i.e. transaction fees. In the case of an edge-tier blockchain with compromised edge devices, a DoS attack becomes significantly difficult to launch since in our proposed framework, we implement custom tokens and transaction fees at the edge-tier level. They do not carry monetary value; however, transaction fees limit the amount of transactions a device can issue over a period of time. 2.3. Entities involved in the architecture In the tiered blockchain architecture of the proposed framework, the entities involved are the IBGWs and the requester nodes interacting with the IBGWs. A requester node can be someone simply looking to buy or crowdsource IoT data or someone providing a monetary service. Upon receiving a data access request from a requester node, the IBGW allows access in accordance to the specific access privileges defined in the edge-tier blockchain’s ‘privileges’ smart contract. Between the IBGW and the distant node, a smart contract is deployed over the core-tier blockchain, which defines the digital terms and conditions for monetizing IoT data, while IPFS is used for privately storing and sharing IoT data. Figure 3 depicts the entities involved in the framework. Figure 3. Open in new tabDownload slide Entities involved in the architecture of the proposed framework. Figure 3. Open in new tabDownload slide Entities involved in the architecture of the proposed framework. IBGW: it is responsible for maintaining a copy of the edge-tier blockchain that contains the time-stamped logs of sensor data coming from IoT devices that were registered through it. The IBGW is also connected to the core-tier blockchain. Upon receiving access requests, it reads specific access privileges written in the edge-tier blockchain and uses IPFS to transfer selected blocks from the edge-tier blockchain to a requester node in an IPFS file. Requester node: it is a peer on the core-tier blockchain that either buys data from an edge-tier blockchain or provides monetary services based on the data sent to it by an IoT user. Provided that the terms and conditions written into the core-tier smart contract are fulfilled, the edge-tier blockchain’s IBGW sends IPFS file keys and the requester node retrieves the IPFS files. Smart contract: the smart contract code lives in the blockchain as an autonomous entity, with its own blockchain address. It is used by a blockchain node (either an IBGW or a requester node) to invoke specific functions written in it. Hence, the functions are a digital parallel to the terms and conditions written in a traditional monetary contract. It is worth mentioning that functions that either update stored information or transfer cryptocurrency incur transaction fees, while methods that merely read stored information are free of charge. Transaction fees are key to preventing a compromised edge-tier node to launch a DoS attack. Decentralized storage: the decentralized storage in the blockchain-based application stack, including IPFS and BigchainDB, acts as a key component for sharing data from edge-tier blockchains and providing the requester node with a mechanism for verifying the integrity of the edge-tier blockchain contents. In Section 3, we discuss specific design choices involved in developing the decentralized access control and monetization mechanism. Furthermore, we present two distinct IoT use cases: an IoT data marketplace and a blockchain-based connected vehicle insurance. These use cases aim to demonstrate how alterations in the smart contracts can be made to adapt the framework to specific applications and show scalable performance without relying on central third-party entities for authentication and data handling. 3. Use Cases for the Proposed Framework The proposed blockchain-based framework is first and foremost an application-agnostic private-by-design solution for performing transactions involving IoT data and cryptocurrency, with fine-grained access control policies. In this section, we will outline the decentralized access control mechanism involved in the framework. We will use two use cases to discuss the usage of the proposed framework in real-world scenarios. These use cases further highlight how the specifics of the edge-tier and core-tier smart contracts can be tailored for specific business models and IoT applications. Typically, tokenized approaches for blockchain-based access control allow any participant in the blockchain network to access digital assets in exchange for a predetermined amount of cryptocurrency tokens [17]. In contrast, the access control technique presented in this paper empowers IoT users to decide whether they want their digital assets open to any public paying member of the blockchain network or they only want to allow restricted access to requesters of their choosing. The design trade-off in designing blockchain-based access control is between absolute anonymity and public accountability. The decentralized access control mechanism proposed here is privacy-preserving to the extent where users are in full control of how much of their data is expressed to third-party entities. The smart contracts proposed do not inherently anonymize users on the blockchain. The proposed framework relies on pseudonymous addressing; therefore, for added anonymity, users can utilize multiple addresses to reasonably obfuscate their identity within the blockchain network. Using multiple addresses effectively masks the identity of IoT users, without hindering the accountability features of the blockchain. In the event of an investigation, users can provide a trail of transactions signed off under all of the addresses they have chosen to use in the past. Here, let |$Y=\{y_0, y_1, \ldots , y_n\}$| be the requester nodes, such that each requester node |$y_r$| has a public/private keypair |$\{k^r_p, k^r_s\}$|⁠. Additionally, let |$C=\{c_0, c_1, \ldots , c_n\}$| be the set of edge-tier blockchains and |$X=\{x_0, x_1, \ldots , x_m\}$| be the set of IBGW nodes, such that $$\begin{align}& \forall c_i \exists X^i \subset X: (c_i \ni X^i), \end{align}$$(2) where |$\ni $| denotes ownership. The IBGWs owned by a specific edge-tier blockchain |$c_i$| are the points of contact over the core-tier blockchain, between requester nodes and the edge-tier blockchain. A requester |$y_r$| would conduct transactions with |$c_i$| through |$x_j$| such that |$x_j \in X^i$|⁠. $$\begin{align}& \forall x_j \exists s^r_j=\langle y_r, x_j \rangle: (r,j \geq 0) \land (r \leq p) \land (\,j \leq m). \end{align}$$(3) Upon receiving access request from |$y_r$|⁠, or to obtain remuneration or monetary services from |$y_r$|⁠, an IBGW |$x_j$| is made responsible for performing data delivery through IPFS. Firstly, |$x_j$| queries access privileges written in the edge-tier smart contract. If access privileges are given, or requirements for access privileges are met, |$x_j$| will query blocks from the requested time interval stored in the edge-tier blockchain. Then, |$x_j$| adds these blocks to an IPFS file and encrypts the IPFS file hash with |$y_r$|’s public key. $$\begin{align}& \forall y_r \exists \langle k^r_p, k^r_s \rangle: d_{k^r_s}(e_{k^r_p}(h_t))=h_t \end{align}$$(4) $$\begin{align}& h_t=IPFS(\varrho^{\,j}), \end{align}$$(5) where |$\varrho^{\,j}$| denotes the requested blocks of the edge-tier blockchain and |$h_t$| is the hash value returned by IPFS for transaction |$t$|⁠. Access policies can be made further fine-grained by allowing access to specific edge-tier transactions. In this case, in addition to the edge-tier block hashes, the edge-tier blockchain owners will need to upload the private block headers (containing each block’s Merkle tree) to BigChainDB, so requesters can verify each edge-tier transaction being sent. The following is a discussion on how the aforementioned access control and data delivery mechanisms are applied in two distinct use-case scenarios. The smart contracts on both the edge tier and core tier are programmed to tailor the framework to these use cases. Figure 4. Open in new tabDownload slide Components of the proposed framework, as they are used in the IoT data marketplace use case. Here, IBGW represents the seller, while the requester is the buyer. Figure 4. Open in new tabDownload slide Components of the proposed framework, as they are used in the IoT data marketplace use case. Here, IBGW represents the seller, while the requester is the buyer. 3.1. Use case #1: decentralized IoT data marketplace To illustrate how the proposed framework would be used in a real-world scenario, we first draw the use case of a decentralized IoT data marketplace. The objective is to allow users to monetize (i.e. to sell) their IoT data and engage with anonymous buyers in a trustless way, without the need of intermediary parties for authentication and authorization. Besides giving IoT users the flexibility to exercise control when transacting with anonymous buyers, it gives buyers a way to ensure that the data they are receiving have not been doctored or tampered with. Along with providing verifiability to the buyers, the architecture can also be used to put a decentralized reputation system in place, which is a blockchain-based parallel to online marketplaces of physical goods. The distributed reputation system aims to incentivize trade with reputed sellers and discourage creating multiple seller accounts or selling fraudulent data. On the public core-tier blockchain, the register contract is where edge-tier sellers can advertise their offerings. Through their IBGWs, edge-tier owners can deploy marketplace contracts at the core tier, where requesters can invoke functions to interact with the IBGW. On each edge-tier blockchain, the privileges contract enables users either to let the entire contents of the private blockchain to be openly available to any paying requester or to define fine-grained privileges and service-level agreements for specific requesters. Figure 5 shows the components, as they are used in this use case, while in the following, we describe the two contracts in more details. 3.1.1. Edge-tier privileges smart contract The private edge-tier blockchain not only helps in keeping IoT data private within federations, or smart-city communities [18], but also allows users to exercise fine-grained control over whom they want to share their data with and at what price. For edge-tier blockchains deployed over consortia with sufficiently large validator pools, the edge-tier blockchain itself provides assurity of data integrity. For smaller edge-tier deployments, the hash of each block gets stored into BigChainDB, which serves as a verifiable public repository that can be looked up to verify the integrity of the data. The privileges contract has three functions. The OpenForAll() function sets a flag that indicates whether the edge-tier blockchain has agreed upon letting the contents of their blockchain become available to any paying requester on the core-tier blockchain. The SetPrivileges() function allows participants within an edge-tier blockchain to define access privileges for specific core-tier addresses in a fine-grained fashion. The IBGW looks up these privileges and responds to incoming requests accordingly. In case a requester has no access privileges, and the OpenForAll flag is not TRUE, the IBGW does not respond and the request times out at the requester’s end. Figure 5. Open in new tabDownload slide Sequence diagram of a buyer requesting data and a seller fulfilling the request. All interactions with the smart contract represent transactions. Dashed arrows represent interactions that are instantaneous and free of charge. Figure 5. Open in new tabDownload slide Sequence diagram of a buyer requesting data and a seller fulfilling the request. All interactions with the smart contract represent transactions. Dashed arrows represent interactions that are instantaneous and free of charge. 3.1.2. Core-tier register contract The register contract is where IoT data buyers go to choose which seller they want to interact with. Edge-tier owners willing to monetize their data can store their marketplace contract’s addresses in the register contract as a form of advertisement, through the RegisterMarketplace() function. Here, |$Y=\{y_0, y_1, \ldots , y_n\}$| are the requester nodes and |$X=\{x_0, x_1, \ldots , x_m\}$| are the IBGWs with deployed marketplace smart contracts on the core-tier blockchain. A requester |$y_r$| can invoke the ViewSellers() function, look up the listings on the register contract and engage with the marketplace contract of |$x_j$|⁠. In case the owner entities of an edge-tier blockchain turn off their OpenForAll flag, the IBGW for that edge-tier blockchain will issue a transaction to update advertisement details on the register contract, to timely inform potential requesters. Table 2 is a list of the functions written in the register contract, along with their input and output parameters. The register contract also serves the purpose of maintaining a record of decentralized reputation for the sellers. Legitimate buyers use their transaction IDs to give sellers a rating based on the data they buy. The reputation system discourages sellers to register with new accounts, since sellers with higher ratings will be favoured by buyers. To finalize each data transaction, requesters will leave a rating through the ReviewSeller() function. Table 1. Functions written in the edge-tier privileges contract. Functions . Input parameters . Output parameters . OpenForAll() Bool open, unit price, String metadata void SetPrivileges() Address requester, String metadata void Functions . Input parameters . Output parameters . OpenForAll() Bool open, unit price, String metadata void SetPrivileges() Address requester, String metadata void Open in new tab Table 1. Functions written in the edge-tier privileges contract. Functions . Input parameters . Output parameters . OpenForAll() Bool open, unit price, String metadata void SetPrivileges() Address requester, String metadata void Functions . Input parameters . Output parameters . OpenForAll() Bool open, unit price, String metadata void SetPrivileges() Address requester, String metadata void Open in new tab Table 2. Functions written in the register contract. Functions . Input parameters . Output parameters . RegisterMarketplace() Address contract, String metadata void ReviewSeller() Address contract, String txID, unit rating void ViewSellers() void Array sellers Functions . Input parameters . Output parameters . RegisterMarketplace() Address contract, String metadata void ReviewSeller() Address contract, String txID, unit rating void ViewSellers() void Array sellers Open in new tab Table 2. Functions written in the register contract. Functions . Input parameters . Output parameters . RegisterMarketplace() Address contract, String metadata void ReviewSeller() Address contract, String txID, unit rating void ViewSellers() void Array sellers Functions . Input parameters . Output parameters . RegisterMarketplace() Address contract, String metadata void ReviewSeller() Address contract, String txID, unit rating void ViewSellers() void Array sellers Open in new tab 3.1.3. Core-tier marketplace contracts Each seller entity has his/her own marketplace smart contract deployed on the core-tier blockchain, which is advertised in the register contract. Buyers engage with seller entities through their specific marketplace contracts. Table 3 contains details on the functions written in each of the marketplace smart contracts. Requesting data: in a scenario where a requester |$y_r$| looks up a marketplace contract address from the register contract, |$y_r$| will invoke the RequestData() function written in the marketplace contract. If |$y_r$| is requesting data from |$x_j$| for the first time, |$y_r$|’s blockchain address is registered within |$x_j$|’s marketplace contract. Thus, the owners of the edge-tier blockchain can maintain records of the number of sales conducted with |$y_r$|⁠. Through input arguments of the RequestData() function, |$y_r$| can specify time intervals for which he/she wants to request IoT data. Last, but not the least, while issuing an IoT data request, |$y_r$| includes the ETH value for the requested data within the ‘value’ field of the method invocation. Responding to data requests: in the event of an incoming data request from |$y_r$|⁠, the IBGW checks access privileges written in the edge-tier privileges smart contract to see if privileges are given and the payment is correct. If so, the IBGW invokes the SendData() method in the contract and adds the encrypted IPFS file hash to |$y_r$|’s customer object in the |$x_j$| smart contract, so |$y_r$| can retrieve and decrypt it. This hash will allow |$y_r$| to access the requested data. Figure 5 shows the sequence diagram of an interaction between |$y_r$| and |$x_j$|⁠. Other functions: other functions written in the contract are the ones that supplement the data transactioning procedure. The CheckPrice() function is a free-of-charge, read-only function that Bob can invoke to inquire the price of the data being sold over a specific period of time, while the BanRequester() function allows Alice to ban certain buyers, hence preventing them from making further requests for data. Table 3. Functions written in the marketplace contract. Functions . Input parameters . Output parameters . CheckPrice() Int hours Int price RequestData() String from, String to, msg.value price void SendData() String IPFShash void RequestPending() void Bool pending, Address buyer BanRequester() Address customer void Functions . Input parameters . Output parameters . CheckPrice() Int hours Int price RequestData() String from, String to, msg.value price void SendData() String IPFShash void RequestPending() void Bool pending, Address buyer BanRequester() Address customer void Open in new tab Table 3. Functions written in the marketplace contract. Functions . Input parameters . Output parameters . CheckPrice() Int hours Int price RequestData() String from, String to, msg.value price void SendData() String IPFShash void RequestPending() void Bool pending, Address buyer BanRequester() Address customer void Functions . Input parameters . Output parameters . CheckPrice() Int hours Int price RequestData() String from, String to, msg.value price void SendData() String IPFShash void RequestPending() void Bool pending, Address buyer BanRequester() Address customer void Open in new tab 3.2. Use case #2: connected vehicle insurance As connected vehicle technology continues to evolve, telematics-based insurance is gaining momentum, promising it to provide insurances based on the data collected from connected vehicles [19]. In UBI, the insurance company may analyse how well a driver uses a vehicle, adjusting premium payments accordingly. UBI has recently experienced substantial growth [20], and insurance companies are experimenting with various data collection techniques. Due to less reliable and accurate data collected through mobile phones, most companies providing UBI opt for proprietary solutions, where a black box installed inside the vehicle collects data including GPS location, acceleration and overall usage. The data collected are analysed and used to assess customers’ driving behaviours. This approach requires users to involuntarily surrender the entirety of their personal driving data to third-party entities, and despite the existing regulatory guidelines, there is absolutely no guarantee that such a black box will collect only the strictly necessary data required for the purpose. Considering the privacy implications of currently existing black-box solutions, there is a need for a private-by-design solution able to not only give users complete control over what and when they share with third-party entities but also to facilitate fast insurance claims and premium payments. Our proposed framework is suited for this problem, since it facilitates selective expression of IoT data and ensures integrity of data sent to insurance companies. For the connected vehicle insurance use case, the architecture remains the same as before, such that |$Y=\{y_0, y_1, \ldots , y_n\}$| are the insurance companies and |$X=\{x_0, x_1, \ldots , x_m\}$| are the IBGWs for edge-tier vehicle blockchain networks. One important design consideration in the vehicle insurance use case is that while a PoW consensus may be beneficial to provide distributed security for the marketplace use case, it would not be suitable for the vehicle insurance use case. At the core tier, it would be preferable to use a PoA blockchain with a significantly large validator pool, spanning multiple insurance companies. This is to prevent insurance customers from publicly validating blocks at the core tier, since mining tokens will be a detriment to the business model. Figure 6 shows the components of the framework. Figure 6. Open in new tabDownload slide Components of the proposed framework, as they appear in the connected vehicle insurance use case. Figure 6. Open in new tabDownload slide Components of the proposed framework, as they appear in the connected vehicle insurance use case. Insurance companies deploy insurance smart contracts that customers can register their vehicles to. The flexibility afforded to the insurance company is that it can deploy multiple contracts in case it needs to offer various insurance premium packages. Customers can then choose which specific smart contract from an insurance company they want to interact with. In order to update insurance premiums or issuing insurance claims, edge-tier owners privately share IPFS files that contain edge-tier blocks, through the insurance smart contracts. Table 4 contains details of the functions written in an insurance provider’s smart contract. Together, the edge-tier and core-tier blockchains come into play while offering the services decribed as follows. Table 4. Functions of the connected vehicle insurance smart contract. Functions . Input parameters . Output parameters . StartCoverage() msg.value payment void SendClaimData() String IPFShash void SendPremiumData() String IPFShash void RequestPending() Address customer Bool pending IsInsured() Address customer Bool insured CheckPayment() Address customer Bool overdue UpdatePremium() Address customer, Int newPremium void MakePayment() msg.value payment void ProcessClaim() msg.value claim, Address customer void Functions . Input parameters . Output parameters . StartCoverage() msg.value payment void SendClaimData() String IPFShash void SendPremiumData() String IPFShash void RequestPending() Address customer Bool pending IsInsured() Address customer Bool insured CheckPayment() Address customer Bool overdue UpdatePremium() Address customer, Int newPremium void MakePayment() msg.value payment void ProcessClaim() msg.value claim, Address customer void Open in new tab Table 4. Functions of the connected vehicle insurance smart contract. Functions . Input parameters . Output parameters . StartCoverage() msg.value payment void SendClaimData() String IPFShash void SendPremiumData() String IPFShash void RequestPending() Address customer Bool pending IsInsured() Address customer Bool insured CheckPayment() Address customer Bool overdue UpdatePremium() Address customer, Int newPremium void MakePayment() msg.value payment void ProcessClaim() msg.value claim, Address customer void Functions . Input parameters . Output parameters . StartCoverage() msg.value payment void SendClaimData() String IPFShash void SendPremiumData() String IPFShash void RequestPending() Address customer Bool pending IsInsured() Address customer Bool insured CheckPayment() Address customer Bool overdue UpdatePremium() Address customer, Int newPremium void MakePayment() msg.value payment void ProcessClaim() msg.value claim, Address customer void Open in new tab 3.2.1. Edge-tier blockchains for data integrity As discussed in Section 3.1, the privileges smart contract within the edge-tier blockchain is meant to set access privileges for third-party data requesters. In this use case, drivers will only want their data available to the insurance company when updating their insurance premium and making insurance claims. Here, of course, since the edge device is mobile and is utilizing mobile infrastructure for networking, the aim was to keep networking overheads at a bare minimum. Since there is only one entity involved at the edge-tier, a bare-bones blockchain without consensus mechanisms is used, simply to locally store data in a structured manner. The privileges smart contract operates as described in Section 3.1; however, the main reason for structuring the data as in a blockchain is to let the IBGW store block hashes onto BigChainDB. With BigChainDB’s significantly large validator pool, hashes stored onto BigChainDB serve as a time-stamped proof of non-repudiation and integrity of the data stored locally. An insurance company can verify the integrity of the blocks a user sends to either process insurance claims or to update a user’s insurance premium. 3.2.2. Functions at the core-tier blockchain In this use case, the core-tier blockchain will have methods to register new customers, to make insurance premiums, processing insurance claims and more. For registration and activation of vehicle insurance coverage, a customer invokes the StartCoverage() method of the smart contract. The inputs arguments of this method are the customer’s blockchain address, as well as an initial payment to start the insurance coverage. If a car owner pays the correct amount as initial payment, he/she is registered as a new customer in the insurance company’s smart contract. The customer object within the smart contract code comes with multiple attributes, including a string variable for storing the last hash of the IPFS file that a customer sent to the insurance company. Again, since values of stored variables are publicly accessible to all blockchain peer nodes, the IPFS file hash is encrypted with the insurance company’s public address, so as to allow only the insurance company to obtain the decrypted hash. Paying insurance premium: usually, to encourage safe driving, connected vehicle insurances offer flexible premiums, where safe drivers have lower insurance premiums to pay. To deliver the same functionality in a decentralized private-by-design fashion, we wrote conditions in the MakePayment() method for users to obtain an updated insurance premium value from the insurance company before making the payment. Figure 7a shows the sequence of steps required for making an insurance premium payment. To obtain an updated insurance premium value, users select from their own private blockchain blocks from a required time frame to send to the insurance company. This could be, for instance, the last month or the last year, but clearly, it completely depends on the insurance policy. The selected blocks are added to IPFS, the file hash is encrypted and stored in the contract itself, using the SendPremiumData() method. This time, while there is no ETH being transferred, transaction fees will be incurred, since the transaction is resulting in a state update within the blockchain. The insurance company can read the hash from the customer object within the smart contract and can then retrieve the associated IPFS file. After analysing the contents of the file, the insurance company issues a new cost for the insurance premium, invoking the UpdatePremium() method. Upon retrieving this update, the customer can perform the appropriate payment. Processing insurance claims: applying for an insurance claim takes similar steps as making an insurance premium payment, as shown in Fig. 7b. In the event of an accident, the customer adds blocks from its private blockchain collected during the time of the accident to IPFS. The customer applies for an insurance claim and stores the encrypted file hash into the contract, invoking the SendClaimData() method. Then, the insurance company retrieves the IPFS file, analyses the received data and eventually pays the adequate amount for the insurance claim to the customer. In the event of a customer not paying the insurance premium after a grace period following the due date, the insurance company has the option to deactivate the customer’s insurance coverage, by setting the customer.PolicyActive attribute to ‘false’. Checking payment status: finally, an important function is to enable insurance companies to check if customers are making timely payments for their insurance premiums. The CheckPayment() method written in the smart contract checks if the customer has not gone over the deadline for making an insurance premium payment. If the customer has indeed gone over the deadline, then the insurance company can deactivate the customer’s insurance policy. Figure 7. Open in new tabDownload slide Sequence diagrams of a customer (a) paying insurance premium and (b) making an insurance claim. All interactions with the smart contract represent transactions. Dashed arrows represent interactions that are instantaneous and free of charge. Figure 7. Open in new tabDownload slide Sequence diagrams of a customer (a) paying insurance premium and (b) making an insurance claim. All interactions with the smart contract represent transactions. Dashed arrows represent interactions that are instantaneous and free of charge. 4. Security Analysis In this section, we outline the security analysis we performed on the proposed blockchain-based framework based on multiple attack scenarios. The main security requirements these scenarios address are as follows. Data integrity: the viability of any data transacting system would rely upon the integrity of the actual data being shared. While public blockchain data are kept secure through algorithmic consensus and a replicated shared state, design considerations are made for the private edge-tier blockchains. Scenario 1 addresses this requirement. Confidentiality: scenario 2 addresses the design considerations in the proposed framework aimed preventing any unauthorized peers from accessing the confidential data being shared between two transacting parties. Availability: the history of IoT has seen challenges in mitigating threats to service availability, in terms of flooding and DoS attacks. Scenarios 3 and 4 highlight how the framework prevents DoS attacks on the core-tier blockchain and how compromised edge-tier blockchains can be isolated to prevent the other edge-tier blockchains as well as the core-tier blockchain from being brought down. Trustlessness: though not a core security requirement in most applications, leveraging blockchains is proving to be a key component in eliminating the need for trusted third-party intermediaries. Therefore, for achieving trustlessness, two parties need to be able to securely interact without the need for ‘trust’. Scenario 5 addresses this requirement. Scenario 1 Data modification in edge-tier blockchains: while data integrity and immutability are inherent features of public blockchains, privately deployed edge-tier blockchains do not have built-in guarantees for data integrity. IoT data are collected and pushed into the edge-tier blockchains, which can be selectively expressed to third parties for monetary services. In this scenario, a malicious edge-tier owner entity modifies edge-tier blocks |$\varrho ^{\,j}$|⁠, since it is computationally feasible within private blockchains. In order to circumvent this threat, the IBGW of the edge-tier blockchain automatically keeps uploading the hashes of |$\varrho ^{\,j}$| to a BigChainDB repository, which is available to third-party requesters. Since each block is linked to its predecessor, modifying a single block will alter all subsequent block hashes and the hashes of the actual blocks sent to the requester, |$e_{k^r_p}(h_t)$|⁠, will not match up with the block hashes stored in the BigChainDB repository. Scenario 2 Sniffing data sent from an edge-tier blockchain: keeping the vehicle insurance use case in mind, let us assume an insurance company |$y_r^{\prime}$|⁠, acting as an adversary, is interested in getting access to the data of the customer |$c_i$| where |$y_r \in S^i$| while |$y_r^{\prime} \notin S^i$|⁠. |$y_r^{\prime}$| needs |$h_t$| in order to get access to the |$c_i$|’s data. |$h_t$| is encrypted with |$k^r_p$|⁠, it can be only decrypted with |$k^r_s$| and the insurance companies do not share their private keys, |$y_r^{\prime}$| is not able to get access to the customers of other companies. Scenario 3 Launching a DoS attack on the core-tier blockchain: briefly, vast amounts of fake requests are sent to a target, in order to overwhelm it and make it unavailable to legitimate users. Such an attack is often performed through a network of infected devices (i.e. a botnet) in a distributed manner, hence the name distributed DoS (DDoS) [21]. The public blockchain used by the proposed framework is a distributed system that has monetary cost for signing transactions (i.e. transaction fees). It follows that, from an economic perspective, to perform a (D)DoS attack on this framework is very expensive. Moreover, generally speaking, the collective computing power available in blockchain makes it extremely hard to launch successful DoS attacks. Indeed, in order to overwhelm the entire blockchain system, multiple nodes across a significant number of various institutions must be attacked. At the time of writing, the average daily hash rate of the main Ethereum public blockchain is 275 TH/s. This means that, to successfully perform a 51% attack, either to alter the blockchain contents or to hinder the network availability, adversaries would have to amass more than 137.5 TH/s of hashing power. Scenario 4 Launching a DoS attack on an edge-tier blockchain through a corrupted device: in various IoT use cases, there is the possibility of an edge-tier device being compromised by an adversary. While each IoT device can only issue transactions to the edge-tier blockchain, a DoS attack can be fatal for private organization or federation edge-tier blockchains. To mitigate this threat, we have used a tokenized approach at the edge-tier level. At the edge-tier, we are using the Tendermint consensus engine with a custom token. While these tokens do not carry any real monetary value, implementing transaction fees ensures that there is a limit to how many transactions a compromised device can issue. Each device is given a limited required amount of tokens |$T$| to be able to issue transactions over a period of time. If the transaction fees for a single transaction are |$F_t$|⁠, the maximum number of transactions a compromised device will be able to make is |$T/F_t$|⁠. Scenario 5 Double-spending on the core-tier blockchain network: through its virtue of maintaining a replicated shared state of all blockchain records, cemented with algorithmic peer-to-peer consensus, blockchain networks prevent any double-spending of tokens in publicly deployed networks. This inherent feature benefits the proposed framework in providing a fabric for data transactions without the need to trust intermediary third parties. 5. Performance Analysis This section details the performance analysis based on the experiments we conducted to validate the proposed framework. The proposed framework was developed and deployed on a PoA-based blockchain. We used the publicly deployed Ethereum Rinkeby network as our core-tier blockchain. This blockchain is maintained by a validator pool spread all over the world2 . We used the Remix Ethereum IDE3 for writing, compiling, debugging and locally testing the smart contract. Remix Ethereum is an in-browser IDE for solidity, the language for writing smart contracts in Ethereum. After locally testing the smart contract functionality, we deployed it to the Rinkeby Ethereum test network. The details of the publicly deployed contracts and the transactions we carried out can be accessed by monitoring the following addresses on he Rinkeby test network: |$ 0xb45d0cc4883ae0c18469904181d68775436b2eb7 0x82A4958337eCE6E358851F073AF123662b8Ce194 $| We considered the case where one laptop (i.e. a Dell Inspiron core-i7) represents the distant node and a single-board computer (i.e. a Raspberry Pi 3 Model B+) represents an IoT edge segment’s IBGW. These devices were both connected over the publicly deployed Ethereum blockchain network Rinkeby. Rinkeby is a network of blockchain nodes spread all across the globe with designated nodes for validating new blocks on the blockchain. Our IBGW was ingesting data from multiple IoT devices and committing it to the private blockchain. Choosing Hyperledger Burrow was based on the fact that both Ethereum and Burrow use the Solidity scripting language for their smart contracts. In our testbed, the private blockchain was deployed over five nodes using Hyperledger Burrow. It is worth remembering that the private blockchain is maintained by IoT gateways (in our testbed’s case, they were transmitting data to the Raspberry pi IBGW) and the computationally capable gateways maintain the private blockchain. The IBGW, being connected to both the public and private blockchain is able to read and write transactions onto both blockchains. To calculate the real-world transaction processing fees incurred by the smart contracts, we have used values equivalent to Ethereum, where each state altering transaction requires an amount of ‘gas’ depending upon the complexity of the transaction. The price for each unit of gas at the time of writing this paper was noted to be 1 Gwei (equivalent to 0.000000001 ETH). The results were obtained with a Raspberry pi 3 board serving the function of an IBGW within the architecture of the proposed framework. Table 5 shows the experimental parameters used for our evaluation. Table 5. Parameters for evaluating the performance of the proposed framework in two use cases. Parameter . Value . Core-tier testnet Ethereum Rinkeby Edge-tier testnet Hyperledger Burrow Transactions on public blockchain 300 per minute Transactions on private blockchain 1000 per minute Gas price 0.000000001 ETH Parameter . Value . Core-tier testnet Ethereum Rinkeby Edge-tier testnet Hyperledger Burrow Transactions on public blockchain 300 per minute Transactions on private blockchain 1000 per minute Gas price 0.000000001 ETH Open in new tab Table 5. Parameters for evaluating the performance of the proposed framework in two use cases. Parameter . Value . Core-tier testnet Ethereum Rinkeby Edge-tier testnet Hyperledger Burrow Transactions on public blockchain 300 per minute Transactions on private blockchain 1000 per minute Gas price 0.000000001 ETH Parameter . Value . Core-tier testnet Ethereum Rinkeby Edge-tier testnet Hyperledger Burrow Transactions on public blockchain 300 per minute Transactions on private blockchain 1000 per minute Gas price 0.000000001 ETH Open in new tab For the performance analysis, we considered the computational and networking overheads of the IBGW for participating in the core-tier blockchain, as well as the latency involved in signing transactions involving IoT data and cryptocurrency. The functions written in both smart contract implementations were kept at |$\mathcal{O}(1)$| algorithmic complexity to minimize computational overheads and associated transaction fees. 5.1. Computational overhead We used the web browser plugin Metamask4 and the light-client Geth5 implementation for our decentralized applications. The light-client implementation allows IBGW to issue transactions without needing to store a full copy of the core-tier blockchain. Additionally, since our nodes do not mine and validate new blocks, the computational overhead on the IBGW is negligible. 5.2. Transaction processing speed Over the multilayered blockchain architecture, our observation is that the deciding factor of the throughput is the transaction finality time. Our implementation in Ethereum appends new blocks over the core-tier blockchain each 14 seconds. We compared the transaction finality time of single monolithic blockchain implementation of Bitcoin, versus our layered implementation on an Ethereum test network. In our experiments, we verified that the transactions we made were finalized at the rate of 32 seconds on average and 90 seconds at the most. Figure 8 shows the transaction processing times observed in our experiments for three separate operations. In the case of IoT data marketplace, to carry out one single sale of data, it would involve two transactions. Therefore, the average processing time is 64 seconds. In the case of connected vehicle insurance (not taking into account the time needed by the insurance company to analyse the received data), the time taken in transactions for making premium payments is |$\sim $|96 seconds (since this process involves 3 transactions) and 64 seconds for processing insurance claims (involving this process 2 transactions). It is worth noting that core-tier blockchain implementations with lower block publishing times, the throughput will further increase. Figure 8. Open in new tabDownload slide Transaction finality times in (a) making a sale in the data marketplace use case, (b) updating insurance premium and (c) processing an insurance claim in the vehicle insurance use case. Figure 8. Open in new tabDownload slide Transaction finality times in (a) making a sale in the data marketplace use case, (b) updating insurance premium and (c) processing an insurance claim in the vehicle insurance use case. Figure 9. Open in new tabDownload slide Network traffic overhead generated by using MetaMask on Chrome and Geth and with private blockchain hash storage in BigchainDB. Figure 9. Open in new tabDownload slide Network traffic overhead generated by using MetaMask on Chrome and Geth and with private blockchain hash storage in BigchainDB. 5.3. Network overhead The tiered network architecture of the proposed framework significantly cuts down the network overhead, which would have been generated in the case where all IoT data generation events were logged on a public blockchain. The added benefit of using MetaMask to push transactions is that there is no incoming traffic from the core-tier network for updating a local copy of the core-tier blockchain. Therefore, the overall network overhead experienced by the IBGW includes the periodic upload of each edge-tier block hash to BigchainDB through the HTTP POST API, along with the transactions that need to be made over the core-tier blockchain. To analyse the network overhead of our application, we compared the traffic generated when using MetaMask on a Google Chrome front-end and the traffic generated in running an Ethereum light client on Geth. The memory and storage requirements of running a full Ethereum node are far and beyond the hardware limitations of a RaspberryPi IoT gateway, so the light client is a more suitable option. By storing edge-tier block hashes onto the BigchainDB testnet at a speed of one transaction per minute, we maintained a 17 bps traffic for maintaining data integrity in the private blockchain. For interacting with the public blockchain, we considered the traffic generated in running MetaMask as well as the Ethereum light client on Geth, while executing one read function per second. Figure 9 illustrates the overall traffic rates generated over a 24-hour period. We observed that since we do not maintain a full node on the core-tier public blockchain, the cost of decentralized authentication and authorization is minimal to the overall network traffic. Additionally, while the overall network traffic overhead from light-client Geth is very small, simply running MetaMask on Chrome further decreases the network overhead. This is because the light-client implementation consistently maintains a record of the block headers in the core-tier blockchain. Table 6. Gas usage and transaction fees for executing functions in the data marketplace smart contract. Functions Invoked by When it is invoked Gas usage ETH price USD DeployContract() Local IoT GW One-time 746 108 0.000746108 0,1145 RequestData() Requester First data request (registration) 63 251 0.000063251 0,0097 RequestData() Requester All subsequent data requests 27 978 0.000027978 0,004 SendData() Local IoT GW In the event of a data request 79 136 0.000079136 0,012 BanRequester() Local IoT GW One-time 28 601 0.000028601 0.004 Functions Invoked by When it is invoked Gas usage ETH price USD DeployContract() Local IoT GW One-time 746 108 0.000746108 0,1145 RequestData() Requester First data request (registration) 63 251 0.000063251 0,0097 RequestData() Requester All subsequent data requests 27 978 0.000027978 0,004 SendData() Local IoT GW In the event of a data request 79 136 0.000079136 0,012 BanRequester() Local IoT GW One-time 28 601 0.000028601 0.004 Open in new tab Table 6. Gas usage and transaction fees for executing functions in the data marketplace smart contract. Functions Invoked by When it is invoked Gas usage ETH price USD DeployContract() Local IoT GW One-time 746 108 0.000746108 0,1145 RequestData() Requester First data request (registration) 63 251 0.000063251 0,0097 RequestData() Requester All subsequent data requests 27 978 0.000027978 0,004 SendData() Local IoT GW In the event of a data request 79 136 0.000079136 0,012 BanRequester() Local IoT GW One-time 28 601 0.000028601 0.004 Functions Invoked by When it is invoked Gas usage ETH price USD DeployContract() Local IoT GW One-time 746 108 0.000746108 0,1145 RequestData() Requester First data request (registration) 63 251 0.000063251 0,0097 RequestData() Requester All subsequent data requests 27 978 0.000027978 0,004 SendData() Local IoT GW In the event of a data request 79 136 0.000079136 0,012 BanRequester() Local IoT GW One-time 28 601 0.000028601 0.004 Open in new tab Table 7. Gas usage and transaction fees for executing functions in the vehicle insurance smart contract. Functions Invoked By When it is Invoked Gas Usage ETH Price USD DeployContract() Insurer One-time 1258610 0.00125861 0.1932 StartCoverage() Customer One-time 103605 0.000103605 0.016 SendClaimData() Customer In case of an accident 92832 0.000092832 0.014 ProcessClaim() Insurer In case of an accident 22587 0.000022587 0,003 SendPremiumData() Customer Once in a decided time period 92832 0.000092832 0.014 MakePayment() Customer Once in a decided time period 23045 0.000023045 0,003 UpdatePremium() Insurer Once in a decided time period 38805 0.000038805 0,006 CheckPayment() Insurer Once in a decided time period 23933 0.000023933 0.004 Functions Invoked By When it is Invoked Gas Usage ETH Price USD DeployContract() Insurer One-time 1258610 0.00125861 0.1932 StartCoverage() Customer One-time 103605 0.000103605 0.016 SendClaimData() Customer In case of an accident 92832 0.000092832 0.014 ProcessClaim() Insurer In case of an accident 22587 0.000022587 0,003 SendPremiumData() Customer Once in a decided time period 92832 0.000092832 0.014 MakePayment() Customer Once in a decided time period 23045 0.000023045 0,003 UpdatePremium() Insurer Once in a decided time period 38805 0.000038805 0,006 CheckPayment() Insurer Once in a decided time period 23933 0.000023933 0.004 Open in new tab Table 7. Gas usage and transaction fees for executing functions in the vehicle insurance smart contract. Functions Invoked By When it is Invoked Gas Usage ETH Price USD DeployContract() Insurer One-time 1258610 0.00125861 0.1932 StartCoverage() Customer One-time 103605 0.000103605 0.016 SendClaimData() Customer In case of an accident 92832 0.000092832 0.014 ProcessClaim() Insurer In case of an accident 22587 0.000022587 0,003 SendPremiumData() Customer Once in a decided time period 92832 0.000092832 0.014 MakePayment() Customer Once in a decided time period 23045 0.000023045 0,003 UpdatePremium() Insurer Once in a decided time period 38805 0.000038805 0,006 CheckPayment() Insurer Once in a decided time period 23933 0.000023933 0.004 Functions Invoked By When it is Invoked Gas Usage ETH Price USD DeployContract() Insurer One-time 1258610 0.00125861 0.1932 StartCoverage() Customer One-time 103605 0.000103605 0.016 SendClaimData() Customer In case of an accident 92832 0.000092832 0.014 ProcessClaim() Insurer In case of an accident 22587 0.000022587 0,003 SendPremiumData() Customer Once in a decided time period 92832 0.000092832 0.014 MakePayment() Customer Once in a decided time period 23045 0.000023045 0,003 UpdatePremium() Insurer Once in a decided time period 38805 0.000038805 0,006 CheckPayment() Insurer Once in a decided time period 23933 0.000023933 0.004 Open in new tab 5.4. Transaction fees Each Ethereum transaction requires gas for execution, which has a fixed price in ETH. Therefore, the number of computational steps involved in any given transaction dictates how much gas is required to execute it. Our aim for the smart contract function design was to reduce the algorithmic complexity as much as possible and minimize the transaction costs that the edge-tier blockchain owners and requesters would have to pay when interacting with the core-tier smart contract. For our experiments, we deployed our smart contract on the Rinkeby test network and made observations on the transaction fees. At the time we obtained these results, the conversion rate from USD to ETH was recorded at $153.50 per ETH. Once again, it is worth recalling that reading functions in the smart contract that simply return stored values on the blockchain are free of cost and instantaneous. In the vehicle insurance use case, these functions allow customers to view their updated insurance premiums and monitor the time of their last payment and they allow the insurance company to check if customers have made timely premium payments and monitor customers’ payment information. All functions that either transfer funds from one side to another, or alter the stored state of a smart contract’s object variable have associated transaction fees, in order to incentivize miners and secure the network. IoT data marketplace Table 6 shows the transaction fees incurred when executing the smart contract functions that update the stored state of the smart contract’s object attributes. We can observe that for making a single sale of IoT data, a buyer would have to pay a minimum of 0.97 cents as transaction fee, and the cost to the seller would be 1.2 cents. Connected vehicle insurance Table 7 shows the transaction fees incurred when interacting with functions in the smart contract. Note that the CheckPayment() function only incurs a function if a customer has not made timely premium payments and the company decides to terminate their insurance policy. Read-only functions in the connected vehicle insurance contract that do not require transaction fees are not included in this table. We can infer the overall transaction cost for making a premium payment, both for the customer and the insurer. For making an insurance premium, a customer sends data for obtaining an insurance premium update and pays the premium after the insurer updates it. Therefore, the cost to the customer is 1.7 cents and, to the insurer, the cost is 0.6 cents. Similarly, for making and processing an insurance claim, the transaction cost to the customer is 1.4 cents and 0.3 cents to the insurer. 6. Related Work Recent related work in developing decentralized platforms for the IoT show us various techniques for handling the aforementioned challenges. Zhang et al. [22] illustrate a potential in developing e-business models with IoT data on top of blockchains. For decentralized data management, Enigma [23] introduced off-chain storage and utilizes distributed hash tables for storing and managing IoT data. FairAccess [17] is a multi-layered architecture that focuses on delivering privacy-preserving IoT data access. FairAccess provides transactions based on smart contracts, where access is given to IoT data in exchange for cryptocurrency. Similar tokenized approaches for access control are seen in [24], where the authors propose blockchains for renting out IoT resources hosted on the cloud. These approaches open the doors to new innovative IoT business models. These proposed solutions also highlight identity management solutions for entities in the IoT. For decentralized storage, the recent work in [25] proposes using a DHT for IoT data storage and a blockchain for maintaining records of every storage and access event. The limitation in this storage approach is in the lack of scalability in single monolithic blockchains. Recent research literature shows multiple integration schemes for bringing the IoT and blockchain together [26]. One such integration scheme involves computationally capable blockchain-connected gateways that manage IoT devices. In [27], authors have blockchain-connected gateways being used for an isolated IIoT vertical. Simply having the gateways manage a single blockchain will not be efficient in the case of widespread IoT use cases, since each gateway would have to maintain a full copy of the blockchain. For performing security analysis in our work, we have consulted recent work in [28, 29] to formalize our findings and discussions. In the areas of adding monetization to the IoT, recent literature shows the potential benefits of using the blockchain as a fabric for conducting transactions [22, 30]. Recent efforts towards blockchain-based monetization include renting out cloud-hosted resources [24] and facilitating energy transactions in smart grid applications [31–33]. To combat the scalability issues faced when integrating blockchains with the IoT, using multiple blockchains is the most promising approach. Recent research indicates efforts towards developing inter-blockchain communications, for limiting the overall incoming transactions to a single blockchain [15, 34, 35]. 7. Conclusions Towards developing a decentralized fabric for IoT data exchange, in this paper, we proposed a private-by-design, blockchain-based framework for exchanging IoT data in return for monetary services. We demonstrated the proposed solution through full-fledged implementations over two use cases and made important observations by conducting a performance analysis. The main contribution of the work is a scalable, multi-tiered private/public blockchain architecture, which enables IoT edge segments to exercise control over their data and monetize it at will. Through our results, we have shown that the cost of achieving decentralized IoT data monetization can be very low, in terms of computational and networking overhead. Moreover, our analysis included detailed observations on the transaction processing fees and transaction throughput. While our work has delved into an application-level framework design, further directions into this area of research lead us towards protocol level design, where we can analyse the propagation time when the IoT devices interact with the IBGWs, and in turn, the IBGWs interact with the public blockchain. This becomes an especially interesting question for the connected vehicle use case where IoT devices are not static. Further analysis of the bit error rates can lead to an investigation of suitable propagation channels for the IBGWs. At the core blockchain tier of the framework, the existing limitations of public blockchain platforms lead us in future research directions towards lightweight public blockchain consensus mechanisms, as well as public blockchain sharding. Footnotes 1 https://provable.xyz/ 2 www.rinkeby.io 3 http://remix.ethereum.org/ 4 https://metamask.io/ 5 https://www.ethereum.org/cli References 1 Al-Fuqaha , A. , Guizani , M., Mohammadi , M., Aledhari , M. and Ayyash , M. ( 2015 ) Internet of things: A survey on enabling technologies, protocols, and applications . IEEE Commun. Surv. Tutor. , 17 , 2347 – 2376 . Google Scholar OpenURL Placeholder Text WorldCat 2 Alaba , F.A. , Othman , M., Targio Hashem , I.A. and Alotaibi , F. ( 2017 ) Internet of things security: A survey . J. Netw. Comput. Appl. , 88 , 10 – 28 . Google Scholar OpenURL Placeholder Text WorldCat 3 Greenwald , G. and MacAskill , E. ( 2013 ) NSA Prism program taps in to user data of Apple, Google and others . The Guardian , 7 , 1 – 43 https://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-data (accessed September 3, 2020). Google Scholar OpenURL Placeholder Text WorldCat 4 Clarke , J. , Castro , R.R., Sharma , A., Lopez , J. and Suri , N. ( 2012 ) Trust & Security RTD in the Internet of Things: Opportunities for International Cooperation . In Proc. First Int. Conf. Security of Internet of Things , Kollam, India, August 17–19 , pp. 172 – 178 . ACM . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 5 Ali , M.S. , Vecchio , M., Pincheira , M., Dolui , K., Antonelli , F. and Rehmani , M.H. ( 2019 ) Applications of blockchains in the internet of things: A comprehensive survey . IEEE Commun. Surv. Tutor. , 21 , 1676 – 1717 . Google Scholar OpenURL Placeholder Text WorldCat 6 Nakamoto , S. ( 2008 ) Bitcoin: A Peer-to-Peer Electronic Cash System . Manubot . https://git.dhimmel.com/bitcoin-whitepaper/. 7 Biryukov , A. , Khovratovich , D. and Pustogarov , I. ( 2014 ) Deanonymisation of Clients in Bitcoin P2P Network . In Proc. ACM SIGSAC Conf. Computer and Communications Security , Scottsdale, USA, November 3–7 , pp. 15 – 29 . ACM . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 8 Wood , G. ( 2014 ) Ethereum: A secure decentralised generalised transaction ledger . Ethereum Project Yellow Paper , 151 , 1 – 32 . Google Scholar OpenURL Placeholder Text WorldCat 9 Benet , J. ( 2014 ) IPFS—Content addressed, versioned, P2P file system . arXiv:1407.3561v1, 1–11 . https://arxiv.org/abs/1407.3561 10 McConaghy , T. , Marques , R., Müller , A., De Jonghe , D., McConaghy , T., McMullen , G., Henderson , R., Bellemare , S. and Granzotto , A. ( 2016 ) BigchainDB: A Scalable Blockchain Database. Technical Report, ascribe GmbH . 11 Liu , M. , Yu , R., Teng , Y., Leung , V. and Song , M. ( 2019 ) Performance optimization for blockchain-enabled industrial internet of things (IIoT) systems: A deep reinforcement learning approach . IEEE Trans. Ind. Informat. , 15 , 3559 – 3570 . Google Scholar OpenURL Placeholder Text WorldCat 12 Castro , M. and Liskov , B. ( 1999 ) Practical Byzantine Fault Tolerance . In Proc. Third Symposium on Operating Systems Design and Implementation (OSDI) , New Orleans, USA, February 22–25 , pp. 173 – 186 . USENIX Association . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 13 Zheng , Z. , Xie , S., Dai , H.-N. and Wang , H. ( 2018 ) Blockchain challenges and opportunities: A survey . Int. J. Web Grid Serv. , 14 , 352 – 375 . Google Scholar OpenURL Placeholder Text WorldCat 14 Cohen , B. ( 2008 ) The BitTorrent protocol specification . http://www.bittorrent.org/beps/bep_0003.html (accessed September 3, 2020). 15 Ali , M.S. , Dolui , K. and Antonelli , F. ( 2017 ) IoT Data Privacy via Blockchains and IPFS . In Proc. 7th Int. Conf. Internet of Things , Linz, Austria, October 22–25 (Vol. 14). ACM . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 16 Ethereum ( 2018 ) Sharding FAQ . https://github.com/ethereum/wiki/wiki/Sharding-FAQ (accessed September 3, 2020) . 17 Ouaddah , A. , Abou Elkalam , A. and Ait Ouahman , A. ( 2016 ) FairAccess: A new blockchain-based access control framework for the internet of things . Secur. Commun. Netw. , 9 , 5943 – 5964 . Google Scholar OpenURL Placeholder Text WorldCat 18 Poncela , J. et al. ( 2014 ) Smart cities via data aggregation . Wirel. Pers. Commun. , 76 , 149 – 168 . Google Scholar OpenURL Placeholder Text WorldCat 19 Husnjak , S. , Peraković , D., Forenbacher , I. and Mumdziev , M. ( 2015 ) Telematics system in usage based motor insurance . Procedia Eng. , 100 , 816 – 825 . Google Scholar OpenURL Placeholder Text WorldCat 20 Derikx , S. , de Reuver , M. and Kroesen , M. ( 2016 ) Can privacy concerns for insurance of connected cars be compensated? Electron. Mark. , 26 , 73 – 81 . Google Scholar OpenURL Placeholder Text WorldCat 21 Mirkovic , J. and Reiher , P. ( 2004 ) A taxonomy of DDoS attack and DDoS defense mechanisms . ACM SIGCOMM Comput. Commun. Rev. , 34 , 39 – 53 . Google Scholar OpenURL Placeholder Text WorldCat 22 Zhang , Y. and Wen , J. ( 2017 ) The IoT electric business model: Using blockchain technology for the internet of things . Peer-to-Peer Netw. Appl. , 10 , 983 – 994 . Google Scholar OpenURL Placeholder Text WorldCat 23 Zyskind , G. , Nathan , O. and Pentland , A. ( 2015 ) Enigma: Decentralized computation platform with guaranteed privacy . arXiv:1506.03471v1, 1–14 . https://arxiv.org/abs/1506.03471. 24 Samaniego , M. and Deters , R. ( 2016 ) Hosting Virtual IoT Resources on Edge-Hosts with Blockchain . In Proc. IEEE Int. Conf. Computer and Information Technology (CIT) , Fiji, December 7–10 , pp. 116 – 119 . IEEE . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 25 Li , R. , Song , T., Mei , B., Li , H., Cheng , X. and Sun , L. ( 2019 ) Blockchain for large-scale internet of things data storage and protection . IEEE Trans. Serv. Comput. , 12 , 762 – 771 . Google Scholar OpenURL Placeholder Text WorldCat 26 Reyna , A. , Martín , C., Chen , J., Soler , E. and Díaz , M. ( 2018 ) On blockchain and its integration with IoT: Challenges and opportunities . Futur. Gener. Comput. Syst. , 88 , 173 – 190 . Google Scholar OpenURL Placeholder Text WorldCat 27 Cha , S.-C. , Chen , J.-F., Su , C. and Yeh , K.-H. ( 2018 ) A blockchain connected gateway for BLE-based devices in the internet of things . IEEE Access , 6 , 24639 – 24649 . Google Scholar OpenURL Placeholder Text WorldCat 28 Kosba , A. , Miller , A., Shi , E., Wen , Z. and Papamanthou , C. ( 2016 ) Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts . In Proc. IEEE Symposium on Security and Privacy (SP) , San Jose, USA, May 23–25 , pp. 839 – 858 . IEEE . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 29 Juels , A. , Kosba , A. and Shi , E. ( 2016 ) The Ring of Gyges: Investigating the Future of Criminal Smart Contracts . In Proc. ACM SIGSAC Conf. Computer and Communications Security , Vienna, Austria, October 24–28 , pp. 283 – 295 . ACM . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 30 Huckle , S. , Bhattacharya , R., White , M. and Beloff , N. ( 2016 ) Internet of things, blockchain and shared economy applications . Procedia Comput. Sci. , 98 , 461 – 466 . Google Scholar OpenURL Placeholder Text WorldCat 31 Aitzhan , N.Z. and Svetinovic , D. ( 2018 ) Security and privacy in decentralized energy trading through multi-signatures, blockchain and anonymous messaging streams . IEEE Trans. Depend. Sec. Comput. , 15 , 840 – 852 . Google Scholar OpenURL Placeholder Text WorldCat 32 Laszka , A. , Dubey , A., Walker , M. and Schmidt , D. ( 2017 ) Providing Privacy, Safety, and Security in IoT-Based Transactive Energy Systems Using Distributed Ledgers . In Proc. 7th Int. Conf. Internet of Things , Linz, Austria, October 22–25 , pp. 1 – 13 . ACM . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 33 Knirsch , F. , Unterweger , A., Eibl , G. and Engel , D. ( 2018 ) Privacy-Preserving Smart Grid Tariff Decisions with Blockchain-Based Smart Contracts . In Rivera, W. (ed.) , Sustainable Cloud and Energy Services , pp. 85 – 116 . Springer International Publishing . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 34 Dorri , A. , Kanhere , S.S., Jurdak , R. and Gauravaram , P. ( 2017 ) Blockchain for IoT Security and Privacy: The Case Study of a Smart Home . In Proc. IEEE Int. Conf. Pervasive Computing and Communications Workshops (PerCom Workshops) , Kona, USA, March 13–17 , pp. 618 – 623 . IEEE . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC 35 Chen , Z.-d. , Zhuo , Y., Duan , Z.-b. and Kai , H. ( 2017 ) Inter-Blockchain Communication . In Proc. Second Int. Conf. Computer Science and Technology , Guilin, China, May 26–28 , pp. 448 – 454 . DEStech . Google Scholar Google Preview OpenURL Placeholder Text WorldCat COPAC © The British Computer Society 2020. All rights reserved. For permissions, please e-mail: journals.permissions@oup.com This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/open_access/funder_policies/chorus/standard_publication_model)
TI - A Blockchain-Based Framework for IoT Data Monetization Services
JF - The Computer Journal
DO - 10.1093/comjnl/bxaa119
DA - 2021-02-19
UR - https://www.deepdyve.com/lp/oxford-university-press/a-blockchain-based-framework-for-iot-data-monetization-services-5vuwKqou2x
SP - 195
EP - 210
VL - 64
IS - 2
DP - DeepDyve
ER -