Recent advancements in the Internet of Things (IoT) has enabled the collection, processing, and analysis of various forms of data including the personal data from billions of objects to generate valuable knowledge, making more innovative services for its stakeholders. Yet, this paradigm continuously suffers from numerous security and privacy concerns mainly due to its massive scale, distributed nature, and scarcity of resources towards the edge of IoT networks. Interestingly, blockchain based techniques offer strong countermeasures to protect data from tampering while supporting the distributed nature of the IoT. However, the enormous amount of energy consumption required to verify each block of data make it difficult to use with resource-constrained IoT devices and with real-time IoT applications. Nevertheless, it can expose the privacy of the stakeholders due to its public ledger system even though it secures data from alterations. Edge computing approaches suggest a potential alternative to centralized processing in order to populate real-time applications at the edge and to reduce privacy concerns associated with cloud computing. Hence, this paper suggests the novel privacy preserving blockchain called TrustChain which combines the power of blockchains with trust concepts to eliminate issues associated with traditional blockchain architectures. This work investigates how TrustChain can be deployed in the edge computing environment with different levels of absorptions to eliminate delays and privacy concerns associated with centralized processing and to preserve the resources in IoT networks.
Internet of Things (IoT) data is becoming one of the most valuable assets in today’s data-driven digital economy as it leads to developing many business models providing numerous ubiquitous and intelligent services [
Worryingly, features of the IoT networks such as their distributed architectures, massive scale, and scarcity of the resources with respect to processing power, storage capacity, bandwidth, etc., do not provide a safe platform for privacy preserving applications. Further, traditional applications of IoT networks are designed in such a way that data management functions, i.e., data collection, data storage, data processing, data sharing, and data destruction, are executed in a centralized fashion, neglecting the distributed nature of IoT devices. This approach has proved to lead to significant delays and traffic congestion when used for delay sensitive applications and thus cannot satisfy the requirements of ultra-low delay sensitive IoT applications, such as a real-time computer vision for smart city security. It not only heightens the issues associated with scalability and latency, but also makes IoT nodes more vulnerable for privacy and security threats, including lack of control over personal data hence unauthorized user profiling and identity theft, fake knowledge propagation, network eavesdropping, illegal invasion, and denial of service (DoS) attacks.
On the other hand, a hierarchical edge computing architecture can resolve the issues associated with centralized architectures by pushing data pipeline functions towards the edge of the IoT networks depending on the resource availability and application requirements [
The fundamental concept behind blockchain technology provides a promising approach to establish a healthy interaction among untrustworthy and unknown entities, while supporting the distributed nature of IoT, eliminating the need of a central authority as in cloud computing architectures [
Motivated by the facts stated above, we first propose a novel variation of blockchain called TrustChain which removes the need for PoW by utilizing trust evaluation concepts discussed in our previous work [
The structure of this paper is as follows: Section
In this section, we briefly introduce the concepts and underlying technology associated with traditional blockchains and trust evaluation. In the context of TrustChain, we utilize these concepts to develop a novel blockchain technology to remove the issues related to privacy and efficient use of resources in a decentralized setting like the IoT.
Blockchain technology is one of the highly researched topics in the recent years, due to its distributed and immutable data storage mechanism enabling applications in almost any area including banking, supply chain, and other transaction networks like IoT. The concept of blockchain was first introduced by Satoshi Nakamoto [
Blockchain can be basically considered as a chain shaped data structure in which a chain of blocks are connected with each other through an address pointer based on a hash value; i.e., blockchain is a shared, decentralized, and distributed state machine. This means that all nodes independently hold their own copy of the blockchain, and the current known “state” is calculated by processing each transaction in order as it appears in the blockchain. Each block of a blockchain typically contains six parts; hash of the previous block, nonce (“number used once”), the hash of the current block, Merkle root (hash of multiple transactions), timestamp, and transaction data as shown in Figure
A typical structure of a blockchain.
In the context of Bitcoin, transactions generally consist of the sender’s address, recipients address, and the value. However, depending on the application this can vary. The header of each block contains a set of metadata that helps to validate each block and link to previous blocks in the public ledger. Having a public ledger means that the data and access to the system is available to anyone who is willing to participate (e.g., Bitcoin, Ethereum, and Litecoin blockchain systems).
However, depending on the application requirements, the structure of the blockchain can be designed in either a more centralized or a more decentralized manner. In this regard, private blockchain architectures are more centralized as they are controlled by a centralized authority that controls the access to the blockchain network. Similar to private blockchains, consortium blockchains are controlled by a set of selected nodes rather than one specific organization hence a suitable candidate for IoT applications.
Mining is the process that validates the blocks created by the blockchain nodes and attaches them to the genesis blockchain. However, the process is a computationally intensive procedure due to the cryptographic puzzle that needs to be solved in order to validate the block. In Bitcoin networks, this process is called PoW in which miners need to find a suitable nonce that gives a unique hash key for each block. Usually, this key is 256 bits long; hence breaking the key is extremely hard without controlling 51% of the total computing power available among miners. Miners receive a reward when they solve the complex mathematical problem. There are two types of rewards: new bitcoins or transaction fees. The overall process of bitcoin mining is shown in Figure
Bitcoin mining process.
The consensus is the process that allows every node in the blockchain network to agree upon connecting the new block to the chain. This involves the mining process as well as other rules including the maximum allowable mining time, how to treat blockchain divergence, signing transactions into blockchain block, rewarding miners, and choosing miners. Other than famous PoW consensus protocols, there are other alternatives including the Byzantine Fault Tolerance algorithm (BFT) [
A comparison of typical consensus algorithms [
Property | PoW | PoS | BFT | DPoS |
---|---|---|---|---|
Identity Management | Open | Open | Permissioned | Open |
Energy Saving | No | Partial | Yes | Partial |
Immunity | 25% of the Computing power | 51% of Stake | 33.3% of faulty replicas | 51% of Validators |
Example | Bitcoin [ | Peercoin [ | Hyperledger Fabric [ | Bitshares [ |
One of the significant parts of a blockchain is the smart contract entity as it bridges the gap between prosumers in terms of executing their preagreed rules and conditions without a centralized authority; i.e., it connects service providers with respectable consumers or connects blockchain service applications. The smart contract codes are otherwise known as executing contracts, blockchain contracts, or digital contracts that are stored in the ledger. Transactions can invoke smart contract functions. They not only define the rules and penalties around an agreement in the same way that a traditional contract does, but also automatically enforce those obligations. The concept of smart contract was first introduced by Nick Szabo [
In general, trust represents a measure of confidence that indicates how much an actor or entity will behave in an expected manner in a situation, and how much an actor is willing to rely on the actions of another actor or party in the future. The concept of trust is an abstract notion, with different meanings depending on both participants and scenarios and influenced by both measurable and nonmeasurable factors. Hence, inconsistency in trust definitions might lead to difficulty in establishing a common, general notation that holds regardless of personal dispositions or differing situations. To avoid such ambiguity, we define trust as “
Although the significance of trust in our physical world is as important as it is in the digital environment, building trust and confidence in the latter is much more difficult. This is due to our inability to have a physical view of an object, unlike in our physical world, where we can view the building of the bank, observe its safe deposits, meet the bank personnel, etc. Another issue with trust is that it is difficult to quantify the exact trustworthiness value of an object. This is even harder when each object has different interpretations and perceptions of the term “trustworthy.” Therefore, they may assign different trustworthiness values to the same provider or the service. For example, a service consumer assigns “very trustworthy” to the provider for a transaction that he has performed. However, another consumer assigns “untrustworthy” for a similar transaction from the same provider. These differences further increase the difficulty in determining the exact trustworthiness of an object.
Despite difficulties in trust evaluation, it shows quite a significant potential towards eliminating risks related to privacy and preserving the integrity of the interactions. Hence, we borrow a definition for trust and the trust model from our previous work in [
Accumulation of Trust Attributes (TAs) towards Trust Metrics (TMs) and formation of a trust value.
The knowledge TM covers all aspects of direct trust evaluations, which provide a perception about a trustee before and during an interaction. To make this possible, it must provide relevant data to the trustor for its assessment. If a data feature can be represented using a quantitative measurement, then the result is a numerical value in a certain range. As an example, social relationships like colocation and cowork, credibility factors like cooperativeness, time-dependent features like the frequency and duration of interactions, and spatial distribution of relevant trustees compared to the trustor can be used as direct trust measurements. The main purposes of trust assessments are to facilitate more intelligent decision-making and task delegation. In this regard, we further elaborate two further metrics, which come under the knowledge TM as nonsocial TMs and social TMs. In nonsocial trust, the idea is to find whether the trustor can rely on physical or cyber objects, and social trust determines whether a trustor can depend on other social objects.
After acquiring enough evidence about trustees through the knowledge TM, the trustor can initiate collaborations with selected trustees based on the perception that the trustor has already obtained. However, the result of these interactions might differ from the perception and hence it is critical to keep a record of each individual experience to be used in future interactions. For instance, the experience might be feedback from consumers after each transaction (as used in many e-commerce systems), just a Boolean value (0/1) indicating whether a service transaction successfully operates (as in some reputation-based trust systems), etc. Then, by accumulating these experiences over time in relation to the corresponding contexts, tasks, and times, the trustor can build up additional intelligence compared to the knowledge TM. To further enhance the perception of the trustor, other objects can share their experience in using the trustee, upon a request by the trustor, which we identify as reputation or the global opinion of the trustee. As an example, we have created a nonbias PageRank based model to calculate the reputation values of trustees in a distributed network as in [
According to the model in Figure
In this section, we present the underlying mechanisms involved with the TrustChain platform which is, an alternative initiation of traditional blockchain in terms of preserving privacy, distributed nature, and the computational resources. In contrast to many issues associated with traditional blockchains as discussed in Section efficient mining scheme that does not depend on computing resources but mutual agreements and trust among them; significantly small mining delay compared to PoW; enhanced scalability due to associated distributed storage mechanism; improved privacy due to intelligent encryption algorithm running inside the TrustChain to hide/minimize the personal data exposure; compatibility with IoT business models due to permissioned nature of TrustChain, while maintaining the distributed and autonomous decision-making capability without relying on a central validator who has control over each node; interoperability among several TrustChains as well as with external traditional blockchain due to the application of smart contracts inside TrustChains.
In order to provide such competency over traditional rivalries like Bitcoin, Ethereum, and Hyperledger, TrustChain is equipped with unique services which provide the aforementioned properties. Hence, we propose several services that must be combined with traditional blockchain service as shown in Figure
Core services of TrustChain platform.
Furthermore, to tackle the issues related to privacy in traditional blockchain networks, our proposed TrustChain service should be designed in compliance with data and privacy regulation standards like GDPR [
Formally, we define trust as in Section
TrustChain Services in the global distributed TrustChain and local TrustChain Networks.
Essentially, the trust service is a result of various trust evaluation models and management functionalities. It is important to note that the equations in (
Trust evaluation based on object trust model, data trust model, and privacy trust model.
However, having an appropriate trust model is not enough in evaluating trust and hence a Trust Management and Evaluation (TME) module addresses the whole process from data collection to trust evaluation as shown in Figure
Trust management and evaluation module.
TAG basically collects appropriate trust data from all the sources, including DC, DP, and DS objects that provide designated services, a trust broker who coordinates with external reputation systems, and TME API that provides an interface to extract data from external objects, environment, and other repositories in order to determine relevant TAs for trust evaluation. Generally, TAG works similarly to the client-server application, in which objects and the TME module change their role depending on the direction of data flow. The data could be either information obtained directly from relevant parties, experience, or opinions of objects as reputation or feedbacks from/to other objects, applications, or services. Once the TAG inside the TME module acquires the data, it will be stored in the local repository to be used by other submodules inside the TME module. To facilitate easy access to data in a distrusted setting, an Inter-Planetary File System (IPFS) based data repository is used in addition to local storage at each node.
Having obtained the necessary information by TAG, the next step is to assess the TA with help from TAE and AIE. Once TAs are assessed, they will be processed by TIA in combination with TMA to aggregate all the TAs based on the techniques like numerical, statistical, ML, or ensemble approaches as discussed in [
The blockchain service enables prosumers to interact with each other without a centralized authority but with a community of peers in the form of a peer-to-peer (p2p) network, in which trust is not placed in an individual, but rather distributed across the entire population. Hence, no one can unilaterally take actions on behalf of the community and change the interactions. Moreover, the distributed nature of blockchains enables both horizontal and vertical service provision depending on the application requirement. As shown in Figure
Composition of services via TrustChains in a smart city.
At the area level, a collection of distributed servers at the Fog layer can establish a permissioned blockchain based on the data coming from ROOF nodes, as well as data stored in the DTCENs to facilitate near real-time services. Further, depending on the computational power available to Fog nodes, it is possible to deploy artificial intelligence and data mining techniques to obtain extra knowledge about a situation to respond to it correctly. Global TrustChain at Fog layer will act as a control layer in such cases to orchestrate the services required by area level applications in a smart city. In order to improve the interoperability among several TrustChains, decentralized exchange (DEX) will act as a broker as shown in Figure
With respect to data management, it is not required to send all the data through the blockchain and depending on the user consent some of the data can be directly transmitted towards the upper layer for immediate processing as denoted with “Direct Communication” in Figure
Categorization of Node Types in TrustChain Networks.
Node Type | Storage | Validation |
---|---|---|
Full Node (e.g. Cloud nodes) | Full TrustChain | Yes |
Heavy Node (e.g. Fog Nodes) | TrustChain below Fog | Possible |
Light Node (e.g. ROOF Nodes) | Mostly store block headers only | Rarely |
Data Issuers (e.g. Sensors, IoT nodes) | None | No |
Further, to limit the usage of TrustChain for data storage, it is possible to integrate TrustChain with parallel distributed architecture [
As we highlighted in Section
In the TrustChain or even in other blockchain versions, miners’ task is to verify individual data blocks and connect them with the genesis chain. However, to be a miner in conventional mining schemes, miners must have either computational power, wealth, authority, or similar type of advantage over others. Similarly, in the PoT method, a group of nodes who have maintained higher-level trustworthiness are chosen as the governing property to be selected as miners or “
Motivated by the BFT based methods, a voting system relying on the trust service is used in the TrustChain network for the consensus mining process. However, the selection of TBs in the TrustChain network is not controlled by a central authority and allows any node who has enough trustworthiness to be selected as a blogger. In TrustChain, each TB decides which other TB they trust using the trust management services given under the Trust Service Component as disuse in Section
Consortium of Trust Bloggers (TBs) and Trust Blogger Pools (TBPs) in the TrustChain network.
However, when pools are not overlapping with each other, there is a possibility that different pools may maintain a different copy of the TrustChains and it will put the overall consensus mechanism in jeopardy. In such cases, a smart contract between the disjoint TBPs can be created to continue the voting process while preserving their pool sizes as they are. On the other hand, a limited number of trustworthy authorities like government control bodies can be selected as the TBs to overcome any disjoints, assuming their inherited trustworthiness. Yet, the later solution might reduce the power of the decentralized architecture of the TrustChain to some extent. Therefore, it is important to consider a minimum level of trustworthiness when it comes to the selection of TBs to avoid disjoint TBPs.
In contrast to BFT based methods, we propose to use the REK model, discussed in Section
After a leader is elected, he chooses a list of deputy
Trust-based consensus management protocol.
Once the
Smart contracts are simply self-executing and immutable codes that reside in a blockchain. They essentially remove the need for a central broker due to their self-executing nature and can be triggered upon receiving a request from IoT nodes, other TrustChains, or by the smart contract itself based on the self-triggering rules inside the contract. In the TrustChain service, smart contracts are stored in a separate chain to improve the efficiency associated process like creating, storing, executing, and terminating. The registry component in the smart contract service basically register newly deployed contracts by issuing an address, name, and version and help to track the outcome of the contract once it is initiated by storing the hash of the result. A secure container includes a secure operating system, smart contract language, runtime environment, and a software development kit to create and run the smart contracts within the TrustChain service.
Even though smart contracts work in a trustless manner after signing the contract, it is beneficial to have a trust evaluation mechanism in place before the contract is signed to implement proactive measures to avoid contract violations. Hence, smart contract service discussion is coupled with the trust service to identify accountabilities and enforce them autonomously. For example, let us consider a distributed market place in a smart city use case in which stakeholder exchange goods for cryptocurrencies. In a normal condition, the seller must ship the items as soon as he received the transaction from the customer. On the other hand, in case of the seller deliberately delaying the shipment, the smart contract will be triggered, and money will be refunded to the customer’s account. However, this process might involve some transaction fees and a waste of effort in the perspective of the customer. Hence, to avoid such outcome, the trust service is used to evaluate the trustworthiness of the prospective sellers based on the REK model, discussed in [
Let us assume Alice (a) the IoT user needs to find a good banker, say Bob (b), and they need to establish a smart contract for their mutual interactions. For the generality, let us take the trust level between any IoT nodes “
Experience and Reputation flow among IoT nodes.
Let us take TA evaluation of the
TrustChain distributed and interoperable ledgers.
TrustChain must ensure the privacy of the stakeholders in both internal and external interactions whenever possible as per the GDPR. Hence, we propose to use the concept of Zero Knowledge Proof (ZKP) to hide the user information when interacting with service providers through smart contracts [
1: 256<p,g and communicate to both Alice and Bob. 2: Alice generates hash of her information and store in x=SHA256(Name, DoB, SSN). 3: Alice calculates 4: Bob takes the hash of his request and store in y, s.t. 0<y<p. 5: Bob calculates 6: Alice calculates the shared secret key, 7: Bob calculates the shared secret key, 8: Alice generates another random oracle v, s.t. 0<v<p. 9: Alice calculates her commitment, 10: Alice calculates the challenge, 11: Alice sends the response, 12: Bob calculate the commitment, 13: If
Note that Bob and Alice share only g, p, and their public keys (
By design, TrustChain platform is developed as a permissioned type of blockchain to control the privacy matters associated with a public blockchain and support business requirements demands by the service providers. Therefore, all nodes who need a TrustChain service are required to register with the membership services in order to obtain an identity to access the distributed services in TrustChain such as carrying out transactions, obtaining services offered by service providers, interacting with smart contracts, etc. However, as there are no centralized authorities in a TrustChain network to manage such credentials, the responsibility relies on the TB with the support from the trust service discussed in Section
Policy services mainly manage areas such as preserving the privacy of the prosumers, monitoring consents, meeting consensus rules and ensuring accountability in case of policy violations. In this regard, the trust service can support to track such rules to detect violations beforehand and take necessary countermeasures in case of an incident already occurring. A more detailed version of implementing such a system is discussed in our previous work [
The initial versions of blockchains like Bitcoin [
In contrast, TrustChain is designed in such a way that it only stores the information allowed by the users. Techniques like ZKP, encryption, and anonymization are used to hide the sensitive data while communicating amongst relevant stakeholders and evaluate trust accordingly without affecting the privacy. The ZKP algorithm suggested in the text is one of the promising techniques used in the TrustChain to communicate amongst parties without revealing their personal information. This property satisfies the GDPR requirements under the
Typically, an IoT ecosystem represents nodes ranging from small sensors (which only emit) data to massive complex data centers (which process billions of interactions per time). In the edge computing setup, these small sensors can be found at the bottom of the hierarchy. Nodes that have a comparatively higher processing power and storage lie in the middle of the network, and large data centers represent nodes at the cloud layer. It is challenging to implement conventional blockchain technologies towards the end of hierarchy due to associated resource restrictions to perform consensus algorithms and limited storage to store the massive public ledger. In contrast, the consensus protocol in TrustChain is simply a combination of trust and BFT and so computation power that can broadcast a set of messages is more than enough to implement the consensus algorithm. Therefore, TrustChain can be easily deployed towards the end of edge computing hierarchy. Furthermore, a lightweight protocol enables efficient processing of blocks while saving more energy compared to traditional blockchain technologies in which a rig of miners must coordinate with each other to solve a highly complex cryptographic puzzle. This, in fact, improves the performance of the overall system and prevents divergence of the ledger as nodes do not need to wait for much longer to identify the correct copy of the ledger in contrast to a traditional blockchain in which it can take at least ten minutes to add a new block to the genesis chain.
Moreover, TrustChain uses a permissioned identity management protocol when selecting suitable validators like in Hyperledger. Application of TBP in TrustChain enables us to expand the TrustChain network just like in Bitcoin blockchain networks, in contrast to Hyperledger in which centralized authority is used to select the validators. Further, the trust service in the TrustChain works collaboratively with membership and policy services to identify trustworthy TB and discourage malicious nodes entering the TrustChain network, contributing to the mining process. This makes the consensus protocol described in Section
According to TrustChain architecture Trust Broker Pool (TBP) is a small portion of the global pool which consists of millions of overlapping TBPs. One TBP contains 51% of trust nodes means; more than half of the global IoT nodes trust each other. This scenario is practically impossible to occur as it is impossible to create such a large trust network by an individual or even by multiple organizations as trust depends on many factors as discussed in the paper. Further, let us assume 51% computing power is control by one organization. In such a situation, this organization can create a TBP consisting of all of their computers. However, it is highly unlikely that all other nodes external to this specific TBP would trust all nodes inside one TBP in any circumstance. Therefore, this specific TBP cannot interfere with the decision-making process as TrustChain consensus protocol is not based on the computer power but only on trustworthiness. Thus, having 51% computing power is also useless in TrustChain network to interfere with the consensus process.
In addition, the trust service is useful to check the integrity of the data generated by IoT nodes as described in Section
TrustChain vs. traditional Blockchain technologies.
Property | Bitcoin | Ethereum | Hyperledger | TrustChain | ||
---|---|---|---|---|---|---|
Permission Restrictions | Permissionless | Permissionless | Permissioned | Permissioned | ||
| ||||||
Consensus | PoW | PoW | PBFT | Trust+BFT | ||
| ||||||
Energy Saving | No | Partial | Yes | Yes | ||
| ||||||
Decentralized Regulation | Yes | Yes | Partial | Yes | ||
| ||||||
Smart Contracts | No | Yes | Yes | Yes | ||
| ||||||
Scalability | Node | High | High | Low | High | |
Performance | Low | Low | High | High | ||
| ||||||
Immunity | 25% of the Computing power | 51% of Stake | 33.3% of faulty replicas | Nearly Immutable | ||
| ||||||
Native Currency | Yes | Yes | No | Possible | ||
| ||||||
Incentive | Mining Fee | Mining Fee | No | Trust | ||
| ||||||
Blockchain as a control chain | No | No | No | Yes | ||
| ||||||
Privacy | No | No | Partial | Yes (e.g. with ZKP) | ||
| ||||||
GDPR Privacy Compliance | Right to | be informed | No support | No support | No support | Support |
access | Support | Support | Support | Support | ||
| No support | No support | No support | Support | ||
| No support | No support | No support | Support | ||
| No support | No support | Support | Support | ||
| No support | No support | Support | Support | ||
| No support | No support | Partial | Support | ||
| No support | No support | Partial | Support |
TrustChain is a permissioned blockchain network designed to enhance the privacy of its prosumers while improving the efficacy of TrustChain service compared to traditional blockchain technologies specifically in a distributed environment like the IoT. The major difference of TrustChain compared to traditional alternatives is the application of computational trust on realizing various functions inside the TrustChain service. Among them, evaluation of trust allowed (i) developing a novel lightweight consensus management protocol by combining with the BFT protocol; (ii) measuring the trustworthiness of participating prosumers before creating smart contracts and before initiating interactions among them; (iii) the membership and policy services to take intelligent decisions when adding new nodes to the network, selecting TBs, and realizing the accountability in case of consensus, privacy, or consent violation; and (iv) checking the integrity of each interaction before adding them to the genesis chain.
Moreover, TrustChain empowers the edge computing architecture of IoT due to its survivability with low computing and storage resources which is not the case with traditional approaches. Nevertheless, this prevents the need for centralized processing such as at the cloud allowing implementing innovative privacy preserving solutions at the Fog and the ROOF via TrustChain membership and policy services. However, it is important to allow vertical services in parallel with horizontal services to facilitate many intelligent solutions. To enable such services, a decentralized exchange is introduced based on the smart contract concept to negotiate among vertical layers to combine data and services in a vertical manner via TrustChain and beyond that. Nevertheless, TrustChain acts in a control layer in such cases to minimize the ledger size and enable an efficient orchestration among different services. Further, TrustChain is embedded with unique techniques to improve privacy when dealing with delicate personal information and to comply with GDPR legislation, for example, using concepts like ZKP, encryption, and anonymization.
No data were used to support this study.
The authors declare that there is no conflict of interest regarding the publication of this paper.
This work was supported by the Institute for Information & Communications Technology Promotion (IITP) grant funded by the Korea government (MSIT) [2018-0-00261, GDPR Compliant Personally Identifiable Information Management Technology for IoT Environment] and this study was financially supported by Hanbat National University financial accounting research fund, 2018 year.