TrustChain: A Privacy Preserving Blockchain with Edge Computingdownloads.hindawi.com/journals/wcmc/2019/2014697.pdf · 2019. 7. 30. · blockchain technologies and trust evaluation

Research ArticleTrustChain A Privacy Preserving Blockchain withEdge Computing

Upul Jayasinghe 1 Gyu Myoung Lee 1 Aacuteine MacDermott1 and Woo Seop Rhee2

1Department of Computer Science Liverpool John Moores University Liverpool UK2Department of Information and Communication Eng Hanbat National University Daejeon Republic of Korea

Correspondence should be addressed to Gyu Myoung Lee gmleeljmuacuk

Received 15 March 2019 Accepted 16 June 2019 Published 8 July 2019

Guest Editor Khalid Elgazzar

Copyright copy 2019 Upul Jayasinghe et alThis is an open access article distributed under theCreative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Recent advancements in the Internet of Things (IoT) has enabled the collection processing and analysis of various forms ofdata including the personal data from billions of objects to generate valuable knowledge making more innovative services forits stakeholders Yet this paradigm continuously suffers from numerous security and privacy concerns mainly due to its massivescale distributed nature and scarcity of resources towards the edge of IoTnetworks Interestingly blockchain based techniques offerstrong countermeasures to protect data from tampering while supporting the distributed nature of the IoT However the enormousamount of energy consumption required to verify each block of data make it difficult to use with resource-constrained IoT devicesand with real-time IoT applications Nevertheless it can expose the privacy of the stakeholders due to its public ledger system eventhough it secures data fromalterations Edge computing approaches suggest a potential alternative to centralized processing in orderto populate real-time applications at the edge and to reduce privacy concerns associated with cloud computing Hence this papersuggests the novel privacy preserving blockchain called TrustChain which combines the power of blockchains with trust conceptsto eliminate issues associated with traditional blockchain architectures This work investigates how TrustChain can be deployedin the edge computing environment with different levels of absorptions to eliminate delays and privacy concerns associated withcentralized processing and to preserve the resources in IoT networks

1 Introduction

Internet of Things (IoT) data is becoming one of the mostvaluable assets in todayrsquos data-driven digital economy as itleads to developing many business models providing numer-ous ubiquitous and intelligent services [1] However thesedata contain sensitive personal information and can revealthe identity of the associated stakeholders if a proper privacypreserving mechanism is not in place [2] For examplea malicious actor who has access to someonersquos personalinformation (such as their address date of birth nationalitybank account number or private e-mail address) can use hisidentity to gain a financial advantage or obtain other benefitsin the other personrsquos name The person whose identity hasbeen assumed may suffer adverse consequences especiallyif they are responsible for the perpetratorrsquos actions Henceenforcing strong privacy preserving techniques and regula-tions is necessary From a regulatory point of view a new

data protection act calledGeneralData ProtectionRegulation(GDPR)was introduced by the European Union (EU) inMay2018 to control the unnecessary usage of data empoweringusersrsquo right on their data [3] It rigorously discusses theimportance of a ldquoprivacy by designrdquo concept which essentiallycalls for privacy to be considered throughout the wholeengineering process

Worryingly features of the IoT networks such as theirdistributed architectures massive scale and scarcity of theresources with respect to processing power storage capacitybandwidth etc do not provide a safe platform for privacypreserving applications Further traditional applications ofIoT networks are designed in such a way that data man-agement functions ie data collection data storage dataprocessing data sharing and data destruction are executedin a centralized fashion neglecting the distributed nature ofIoT devices This approach has proved to lead to significantdelays and traffic congestion when used for delay sensitive

HindawiWireless Communications and Mobile ComputingVolume 2019 Article ID 2014697 17 pageshttpsdoiorg10115520192014697

2 Wireless Communications and Mobile Computing

applications and thus cannot satisfy the requirements ofultra-low delay sensitive IoT applications such as a real-time computer vision for smart city security It not onlyheightens the issues associated with scalability and latencybut also makes IoT nodes more vulnerable for privacy andsecurity threats including lack of control over personaldata hence unauthorized user profiling and identity theftfake knowledge propagation network eavesdropping illegalinvasion and denial of service (DoS) attacks

On the other hand a hierarchical edge computing archi-tecture can resolve the issues associated with centralizedarchitectures by pushing data pipeline functions towardsthe edge of the IoT networks depending on the resourceavailability and application requirements [4 5] Deploymentof such an architecture is beneficial in building an ecosysteminvolving content providers application developers networkequipment vendors third-party partners and middlewareproviders and thereby improving the end-user experiencedramatically due to powerful and energy efficient computingpower at hand low latency mobility location and context-aware support for IoT applications [6ndash8] However edgecomputing alone cannot support the safeguarding of theprivacy of the stakeholders as it introduces a new set ofvulnerabilities due to multiple attack surfaces closenessto sensitive data generators heterogeneity of the deviceresources the scale of the network and difficulty of assessingthe trustworthiness of participating stakeholders [9]

The fundamental concept behind blockchain technologyprovides a promising approach to establish a healthy inter-action among untrustworthy and unknown entities whilesupporting the distributed nature of IoT eliminating the needof a central authority as in cloud computing architectures[10 11] The main technology of the blockchain lies behindthe use of an immutable public record of data called ldquopublicledgerrdquo shared among all participants The ledger consistsof blocks of data which are linked with each other by acryptographic hash key and the process of linking is termedldquoProof of Workrdquo (PoW) However adopting the blockchaintechnology as it is in the IoT environment is quite challengingdue to the exhaustive computation power required to solvePoW puzzles with resource-constrained IoT devices Thedelay associated with the mining process is not suitable forreal-time IoT applications in addition to scalability issuesassociated with blockchain and further overhead created byblockchain consensus algorithms

Motivated by the facts stated above we first proposea novel variation of blockchain called TrustChain whichremoves the need for PoW by utilizing trust evaluationconcepts discussed in our previous work [12ndash14] In generalthe concept of trust can be seen as a metric that is usedto evaluate stakeholders in consideration of mutual benefitscoordination and cooperation Perception of trust is oftenachieved with direct observations through experience andbased on the beliefs and opinions of others who are aroundit as we discussed in [14] This paper also discusses aprivacy perceiving edge computing architecture based on theconcepts of ROOF (ROOF Real-Time Onsite OperationsFacilitations) Fog andCloud computing concepts [15]Thenwe further extend the idea of TrustChain based on the

permissioned blockchain concepts tomatch with the require-ments at each layer of the proposed distributed architectureWe use a smart city use case to demonstrate the proposedideas in all three cases above

The structure of this paper is as follows Section 2presents the concepts and underlying principles of traditionalblockchain technologies and trust evaluation in general tosupport the proposed ideas in the following sections Sec-tion 3 focuses on the details of TrustChain and underlyingmechanisms compared to typical blockchains Section 4discusses the importance of the proposed TrustChain whenrealizing privacy preserving and trustworthy services in adistributed environment and Section 5 concludes the paper

2 Preliminaries

In this section we briefly introduce the concepts and under-lying technology associated with traditional blockchains andtrust evaluation In the context of TrustChain we utilize theseconcepts to develop a novel blockchain technology to removethe issues related to privacy and efficient use of resources in adecentralized setting like the IoT

21 Blockchain Overview Blockchain technology is one ofthe highly researched topics in the recent years due to itsdistributed and immutable data storage mechanism enablingapplications in almost any area including banking supplychain and other transaction networks like IoT The conceptof blockchain was first introduced by Satoshi Nakamoto[16] as the fundamental technology of the digital cryp-tocurrency called Bitcoin The use of blockchain in publicand distributed ledgers for Bitcoin transactions made it thefirst cryptocurrency not only to transact digital money in asecurely and inexpensive manner but also to resolve the long-standing problem of ldquodouble spendingrdquo without the need fora trusted and powerful third-party By nature blockchaintechnology is inherently resistant to data modification dueto its public ledger and the consensus mechanism calledPoW Once recorded data in any given block cannot bealtered retroactively as this would invalidate all hashes inthe previous blocks in a blockchain and break the consensusagreed among nodes voiding the blockchain

211 Blockchain Architecture Blockchain can be basicallyconsidered as a chain shaped data structure in which achain of blocks are connected with each other through anaddress pointer based on a hash value ie blockchain isa shared decentralized and distributed state machine Thismeans that all nodes independently hold their own copy ofthe blockchain and the current known ldquostaterdquo is calculatedby processing each transaction in order as it appears in theblockchain Each block of a blockchain typically containssix parts hash of the previous block nonce (ldquonumber usedoncerdquo) the hash of the current block Merkle root (hash ofmultiple transactions) timestamp and transaction data asshown in Figure 1

In the context of Bitcoin transactions generally consistof the senderrsquos address recipients address and the valueHowever depending on the application this can vary The

Wireless Communications and Mobile Computing 3

Block n-1Header

Tx

Tx Transactions

Block n

Header

Tx

Block n+1Header

Tx

lowastPointer to previous Blocks

HeaderMetadata

Previous Block HashTimestamp Nonce

Merkle Root

lowast lowast

Figure 1 A typical structure of a blockchain

header of each block contains a set of metadata that helpsto validate each block and link to previous blocks in thepublic ledger Having a public ledger means that the data andaccess to the system is available to anyone who is willing toparticipate (eg Bitcoin Ethereum and Litecoin blockchainsystems)

However depending on the application requirementsthe structure of the blockchain can be designed in either amore centralized or a more decentralized manner In thisregard private blockchain architectures are more centralizedas they are controlled by a centralized authority that controlsthe access to the blockchain network Similar to privateblockchains consortium blockchains are controlled by a setof selected nodes rather than one specific organization hencea suitable candidate for IoT applications

212 Consensus and Mining Mining is the process thatvalidates the blocks created by the blockchain nodes andattaches them to the genesis blockchainHowever the processis a computationally intensive procedure due to the crypto-graphic puzzle that needs to be solved in order to validatethe block In Bitcoin networks this process is called PoWin which miners need to find a suitable nonce that givesa unique hash key for each block Usually this key is 256bits long hence breaking the key is extremely hard withoutcontrolling 51of the total computing power available amongminers Miners receive a reward when they solve the complexmathematical problem There are two types of rewards newbitcoins or transaction fees The overall process of bitcoinmining is shown in Figure 2

The consensus is the process that allows every node inthe blockchain network to agree upon connecting the newblock to the chainThis involves the mining process as well asother rules including the maximum allowable mining timehow to treat blockchain divergence signing transactions intoblockchain block rewarding miners and choosing minersOther than famous PoW consensus protocols there areother alternatives including the Byzantine Fault Tolerancealgorithm (BFT) [17] the Proof-of-Stake algorithm (PoS)[18] and Delegated Proof-of-Stake algorithm (DPoS [19])[20] Each of these algorithms is designed to achieve certainagreement among nodes depending on the application areaof use while enabling unique features like minimum resourcerequirements immunity of the protocol easiness of access

New BlockPrevious Block

HashNumber

isHash lt Target

+

New Nonce

Target Value

MiningDifficulty

Solved and Publish

block

Mining Reward

++

No

Yes

Block n-1

Header

Tx

Block n

Header

Tx

Algorithm

Hash of the Previous

Block

Figure 2 Bitcoin mining process

control and privacy A comparison of typical consensusalgorithms is shown in Table 1

213 Smart Contracts One of the significant parts of ablockchain is the smart contract entity as it bridges the gapbetween prosumers in terms of executing their preagreedrules and conditions without a centralized authority ie itconnects service providers with respectable consumers orconnects blockchain service applications The smart con-tract codes are otherwise known as executing contractsblockchain contracts or digital contracts that are stored inthe ledger Transactions can invoke smart contract functionsThey not only define the rules and penalties around anagreement in the same way that a traditional contract doesbut also automatically enforce those obligations The concept


Table 1 A comparison of typical consensus algorithms [21]

Property PoW PoS BFT DPoSIdentityManagement Open Open Permissioned Open

Energy Saving No Partial Yes Partial

Immunity 25 of theComputing power 51 of Stake 333 of faulty

replicas 51 of Validators

Example Bitcoin [16] Peercoin [22] Hyperledger Fabric[23] Bitshares [24]

of smart contract was first introduced byNick Szabo [25] andis widely used in many popular blockchain versions like inEthereum [26]

22 Trust Evaluation Overview In general trust representsa measure of confidence that indicates how much an actoror entity will behave in an expected manner in a situationand how much an actor is willing to rely on the actions ofanother actor or party in the future The concept of trustis an abstract notion with different meanings dependingon both participants and scenarios and influenced by bothmeasurable and nonmeasurable factorsHence inconsistencyin trust definitions might lead to difficulty in establishing acommon general notation that holds regardless of personaldispositions or differing situations To avoid such ambiguitywe define trust as ldquoa qualitative or quantitative property ofa trustee measured by a trustor for a given task in a specificcontext and in a specific time periodrdquo as in [14] In the contextof IoT trust can be identified as a feature that affects theappetite of an object to consume a particular service orproduct offered by another This can be observed in everydaylife where trust decisions are made When purchasing aspecific product wemay favor certain brands due to our trustthat these brands will provide excellent quality comparedto unknown brands Trust in these brands may come fromour knowledge experience of using their products or theirreputations which are perceived by other people who boughtitems and left their opinions about those products

Although the significance of trust in our physical worldis as important as it is in the digital environment buildingtrust and confidence in the latter is much more difficultThis is due to our inability to have a physical view of anobject unlike in our physical world where we can view thebuilding of the bank observe its safe deposits meet the bankpersonnel etc Another issue with trust is that it is difficultto quantify the exact trustworthiness value of an object Thisis even harder when each object has different interpretationsand perceptions of the term ldquotrustworthyrdquo Therefore theymay assign different trustworthiness values to the sameprovider or the service For example a service consumerassigns ldquovery trustworthyrdquo to the provider for a transactionthat he has performed However another consumer assignsldquountrustworthyrdquo for a similar transaction from the sameprovider These differences further increase the difficulty indetermining the exact trustworthiness of an object

Despite difficulties in trust evaluation it shows quite a sig-nificant potential towards eliminating risks related to privacy

and preserving the integrity of the interactions Hence weborrow a definition for trust and the trust model from ourprevious work in [12ndash14] to formulate the foundation in thiswork We identify three Trust Metrics (TMs) to identifyevaluate and create trust relationships among objects in theIoT endowment namely knowledge experience and reputa-tion Each TM is a collective representation of several TrustAttributes (TAs) and each TA represents the trustworthinessfeature of a trustee as shown in Figure 3

The knowledge TM covers all aspects of direct trustevaluations which provide a perception about a trusteebefore and during an interaction To make this possible itmust provide relevant data to the trustor for its assessmentIf a data feature can be represented using a quantitativemeasurement then the result is a numerical value in a certainrange As an example social relationships like colocationand cowork credibility factors like cooperativeness time-dependent features like the frequency and duration of inter-actions and spatial distribution of relevant trustees comparedto the trustor can be used as direct trust measurementsThe main purposes of trust assessments are to facilitatemore intelligent decision-making and task delegation In thisregard we further elaborate two further metrics which comeunder the knowledge TM as nonsocial TMs and social TMsIn nonsocial trust the idea is to find whether the trustor canrely on physical or cyber objects and social trust determineswhether a trustor can depend on other social objects

After acquiring enough evidence about trustees throughthe knowledge TM the trustor can initiate collaborationswith selected trustees based on the perception that the trustorhas already obtainedHowever the result of these interactionsmight differ from the perception and hence it is critical tokeep a record of each individual experience to be used infuture interactions For instance the experience might befeedback from consumers after each transaction (as usedin many e-commerce systems) just a Boolean value (01)indicating whether a service transaction successfully operates(as in some reputation-based trust systems) etc Then byaccumulating these experiences over time in relation to thecorresponding contexts tasks and times the trustor canbuild up additional intelligence compared to the knowledgeTM To further enhance the perception of the trustor otherobjects can share their experience in using the trustee upona request by the trustor which we identify as reputationor the global opinion of the trustee As an example wehave created a nonbias PageRank based model to calculatethe reputation values of trustees in a distributed network


TRUST

KNOWLEDGE EXPERIENCE REPUTATION

K1 Kn E1 En R1 Rn

Trust Attributes

Trust Attributes

Trust Metrics

sum

Figure 3 Accumulation of Trust Attributes (TAs) towards Trust Metrics (TMs) and formation of a trust value

as in [27] In summary the experience TM is a personalobservation considering only interactions from a trustor to atrustee whereas the reputationTMreflects the global opinionof the trustee

According to the model in Figure 3 the first step of thetrust evaluation is to estimate relevant TMs depending on theapplication However this information is not readily availableand therefore attributes which define these TMs must beobtained There are numerous methods available to estimatethese TAs ranging from numerical methods probabilisticmethods belief theory to machine learning (ML) methodsIn simple terms the mathematical approach to find the trustvalue trustor ldquoirdquo and trustee ldquojrdquo can be represented as in

119870119894119895 = 12057211198701 + 12057221198702 + + 120572119899119870119899119864119894119895 = 12057311198641 + 12057321198642 + + 120573119899119864119899119877119894119895 = 12057411198771 + 12057421198772 + + 120574119899119877119899

119879119903119906119904119905119894119895 = 1205791119870119894119895 + 1205792119864119894119895 + 120579119899119877119894119895

(1)

where 120572 120573 120574 and 120579 are weighting factors that normalize eachmetric in between 0 and 1 Kx Ex and Rx represent the TMsknowledge experience and reputation respectively

3 TrustChain Platform

In this section we present the underlying mechanismsinvolved with the TrustChain platform which is an alter-native initiation of traditional blockchain in terms of pre-serving privacy distributed nature and the computationalresources In contrast to many issues associated with tradi-tional blockchains as discussed in Section 21 the TrustChainis powered with several advantages including

(i) efficient mining scheme that does not depend oncomputing resources but mutual agreements andtrust among them

(ii) significantly small mining delay compared to PoW(iii) enhanced scalability due to associated distributed

storage mechanism

(iv) improved privacy due to intelligent encryption algo-rithm running inside the TrustChain to hidemini-mize the personal data exposure

(v) compatibility with IoT business models due to per-missioned nature of TrustChain while maintainingthe distributed and autonomous decision-makingcapability without relying on a central validator whohas control over each node

(vi) interoperability among several TrustChains as wellas with external traditional blockchain due to theapplication of smart contracts inside TrustChains

In order to provide such competency over traditional rival-ries like Bitcoin Ethereum and Hyperledger TrustChain isequipped with unique services which provide the aforemen-tioned properties Hence we propose several services thatmust be combined with traditional blockchain service asshown in Figure 4

Furthermore to tackle the issues related to privacy in tra-ditional blockchain networks our proposed TrustChain ser-vice should be designed in compliance with data and privacyregulation standards like GDPR [3] While the principles ofdata accountability and transparency have previously implicitrequirements of data protection law GDPR further extendsthe requirements of authorities by introducing explicit pro-visions that promote data accountability and governance toprotect the privacy of personal data GDPR defines threeparticipant roles namely Data Subject (DS) Data Controller(DC) and Data Processor (DP) and specifies their associatedobligations under EU data protection law In this regard weadopt the permissioned blockchain concept in order to designthe TrustChain platform as it allows the prosumers to controlthe data visibility through access control and consensusmechanisms Also the use of smart contracts enables DSsDCs and DPs to impose and to negotiate consent rules forfinalizing an agreement on data usage as legal grounds bymeans of a usage control language We believe our proposedTrustChain platform is a promising approach for developinga secure and trusted data management in Smart Cities thatfully comply with GDPR


Trustchain APIs

Trust Blockchain Transactions Smart Contracts Membership Policy

Trust Services Blockchain Services Smart Contract Services

Membership Services

Policy Services

Ledger IdentitiesResource Identities

Registration

Auditing amp Accountability

Validator Management

Access ControlConsent

Management

Privacy

Secure Container

Life Cycle

RegistryConsensus

ManagementDistributed

Ledger

P2P Protocol Ledger Storage

IPFS StorageCryptographic Services

Trust Management

Trust Data Repository

Trustchain Services

Figure 4 Core services of TrustChain platform

DTCEN(Distributed Trust Chain

Edge Node)

Global Distributed TrustChain

Trust Service Chain 1

Home IoT

DTCEN

IoT Trust Agent


Prove Server

LocalTrustChain

Factory IoT

IoT Trust Agent

Prove Server

Fog Layer

ROOF Layer

DTCEN

DTCEN

LocalTrustChain

Figure 5 TrustChain Services in the global distributed TrustChain and local TrustChain Networks

31 Trust Service Formally we define trust as in Section 22and use it as a service in this section to empower each aspectof TrustChain to design a lightweight consensus algorithmas investigated in Section 32 administer smart contracts asdescribed in Section 33 manage membership and policiesas in Section 34 and importantly protect the privacy of theusers in compliance with GDPR legislation as described inthis section The trust service in a Distributed TrustChainEdge Node (DTCEN) network is implemented as a logicalTrust Service Chain (TSC) as shown in Figure 5 Then basedon the requirements of TrustChain platform trust serviceis provided on demand to both local TrustChain stored inROOF nodeIoT Trust agents (such as a home router) andglobal distributed TrustChain stored in the DTCEN networkAdditionally the DTCEN network is allowed to keep apublic ledger alongside private ledger depending on the

application scenarios user consents and privacy policies ofparticipating nodes When there is a requirement to validatea block engage with smart contract service or manage themembership of the stakeholders TSCwill be triggered amongthe relevant actors to evaluate trust based on the methodsdiscussed below and thereby assist the obligation in place

Essentially the trust service is a result of various trustevaluation models and management functionalities It isimportant to note that the equations in (1) represent theoverall processes of TMTA segmentation evaluation andaggregation which is needed to establish trust service irre-spective of the area of application and only the TAs whichrepresent the features of a given situation are different toeach other For example the trust evaluation model based onfeatures of an entity integrity of data and associate privacyrequirements are shown in Figure 6


Data Trust

Privacy Trust

Trust

Entity Trust

Non-SocialAttributes

SocialAttributes

Relationship

Temporal

Spatial

Competence

Disposition

Dependence

Fulfillment

Willingness

Persistence

Confidence

Validity

Completeness

Uniqueness

Accuracy

Timeliness

Consistency

Right to be informed (RI)

Right of access (RA)

Right to rectification(RR)

Right to erasure (RE)

Right to restrict processing (RRP)

Right to data portability (RP)

Right to object (RO)

Rights decision-making (RDP)

R E K

R E K

R E K

R E K

Reputation Experience and Knowledge

Figure 6 Trust evaluation based on object trust model data trust model and privacy trust model

However having an appropriate trust model is notenough in evaluating trust and hence a Trust Managementand Evaluation (TME) module addresses the whole processfrom data collection to trust evaluation as shown in Figure 7To support such processes the TMEmodule is equipped withseveral important submodules Trust Agent (TAG) TrustData Access Object (TDAO) IPFS enabled Data Repository(DR) TA Extractor (TAE) Trust Information Analysis (TIA)AI Engine (AIE) Trust Modelling Algorithm (TMA) andTrust Lifecycle Management module (TLM) These mod-ules will perform one or more tasks at a time to evaluatetrust

TAG basically collects appropriate trust data from allthe sources including DC DP and DS objects that providedesignated services a trust broker who coordinates withexternal reputation systems and TME API that provides aninterface to extract data from external objects environmentand other repositories in order to determine relevant TAsfor trust evaluation Generally TAG works similarly to theclient-server application in which objects and the TMEmodule change their role depending on the direction of dataflow The data could be either information obtained directlyfrom relevant parties experience or opinions of objects asreputation or feedbacks fromto other objects applicationsor services Once the TAG inside the TME module acquiresthe data it will be stored in the local repository to be usedby other submodules inside the TME module To facilitateeasy access to data in a distrusted setting an Inter-Planetary

File System (IPFS) based data repository is used in additionto local storage at each node

Having obtained the necessary information by TAG thenext step is to assess the TA with help from TAE and AIEOnce TAs are assessed they will be processed by TIA incombination with TMA to aggregate all the TAs based onthe techniques like numerical statistical ML or ensembleapproaches as discussed in [12ndash14] The TMA should worktogether with the TAE and TIA to find the best possiblemetrics for each model Some models will combine themetrics according to pre-defined rules or policies whileothers will generate these rules and policies dynamically tosuit the situation in the best possible way Finally estimatedtrust information is transmitted towards the relevant party forappropriate decision-making processes

32 Blockchain Service The blockchain service enables pro-sumers to interact with each other without a centralizedauthority but with a community of peers in the form ofa peer-to-peer (p2p) network in which trust is not placedin an individual but rather distributed across the entirepopulation Hence no one can unilaterally take actionson behalf of the community and change the interactionsMoreover the distributed nature of blockchains enables bothhorizontal and vertical service provision depending on theapplication requirement As shown in Figure 8 differentlayers of TrustChains are established by their responsiblecomputing authority A permissioned TrustChain at the Fog


Service n

TrustIdM

TrustLinking

Trust BrokerReputation System

Interaction

Trust Management and Evaluation Module

Other Objects

Trust Agent

TrustData

Collection

TrustData

Filtering

TrustData Pre-Processing

Trust Attribute

Extraction

Trust InformationAnalysis

Statistical

Machine Learning

Numerical

Trust DAO Data

RepositoryTMEAPI

Trust Agent

Trust Service Enabler

AI and Big Data Engine

Trust Modelling Algorithms

Rule Policy

Ontology REK

Trust Lifecycle Managem

entTrust Revocation Trust Update Trust Establishment

AgentIPFS

DP

DS

Trust

Service i


Environment amp Context Data Sources

DC

Figure 7 Trust management and evaluation module

and ROOF layers are implemented as service providersat the Fog and ROOF layers have better control over thenetwork However there are no TrustChains occupied in thecloud layer due to the p2p nature of the TrustChains andprivacy issues related to centralized processing To explain theapplicability of TrustChain in a real-world scenario a smartcity use case has been utilised In this scenario the bottomlayers represent IoT nodes like sensors smartphones andtablets and ROOF agents such as hubs routers and homeservers To facilitate localized services which demand real-time decision-making capabilities like in emergency servicesand energy management services TrustChains in ROOF willwork together through smart contracts among them Due tothe lightweight attribute of the consensus protocol suggestedbelow even a ROOF node has the ability to validate newblocks and add them to the genesis TrustChain improving theoverall performance of the IoT local network

At the area level a collection of distributed servers atthe Fog layer can establish a permissioned blockchain basedon the data coming from ROOF nodes as well as datastored in the DTCENs to facilitate near real-time servicesFurther depending on the computational power available toFog nodes it is possible to deploy artificial intelligence anddata mining techniques to obtain extra knowledge about asituation to respond to it correctly Global TrustChain at Foglayer will act as a control layer in such cases to orchestratethe services required by area level applications in a smartcity In order to improve the interoperability among severalTrustChains decentralized exchange (DEX) will act as abroker as shown in Figure 8 A detailed implementation ofDEX based on the smart contract service is discussed inSection 33

With respect to data management it is not required tosend all the data through the blockchain and depending onthe user consent some of the data can be directly transmittedtowards the upper layer for immediate processing as denotedwith ldquoDirect Communicationrdquo in Figure 8 Furthermore

smart contracts can be used to negotiate between actors totrigger certain services stored in the TrustChain or to findthe services stored in a separate database and generate a com-bined result The scenario applies to Fog and cloud level in asimilar manner and the concept of smart contract can also beused as aDEX to communicate in between layers when takinghigher level decisions such as at the cloud layer Additionallyit is beneficial to identify different types of nodes dependingon their capabilities on forming a TrustChain in terms ofstorage and verification as shown in Table 2 Full nodesare capable of storing both the full TrustChain and theverification by triggering the consensus protocol discussedlater in this section Heavy nodes are mostly confined withlimited storage and hence only stores TrustChain below theFog layer and if further processing is required it will initiatea smart contract with cloud-based nodes to establish fullTrustChain depending on the application Light nodes areonly capable of storing TrustChain headers and often notable to add any blocks to the chain as their resources arelimited for performing verification Data issuers are simplythe IoT devices and sensors They can choose to store datain TrustChains which are handled by upper layers or directlysend the data towards upper layers without depositing thedata on TrustChain for fast processing after evaluating theprivacy requirements and consents from users via the trustservice It is important to establish smart contracts betweendifferent types of TrustChains to ensure privacy by designconcept Hence different types of distributed ledgers areproposed to store data smart contracts and cryptocurrencyseparately and connected by DEXs

Further to limit the usage of TrustChain for data storageit is possible to integrate TrustChain with parallel distributedarchitecture [28] that separates the data layer from the controllayer using TrustChainThen the data generated by each nodeat each layer is stored in a local database and TrustChain onlyholds the reference to data that serve as the identifier to verifythe correctness and integrity of dataThis enables TrustChain


ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n

Trusted Applications

Smart livingBlockchain Healthcare

Distributed Banking

DEX

Distributed Services

Figure 8 Composition of services via TrustChains in a smart city

Table 2 Categorization of Node Types in TrustChain Networks

Node Type Storage ValidationFull Node (eg Cloud nodes) Full TrustChain YesHeavy Node (eg Fog Nodes) TrustChain below Fog PossibleLight Node (eg ROOF Nodes) Mostly store block headers only RarelyData Issuers (eg Sensors IoT nodes) None No

to act as a control channel to record the overall state of the IoTsystem including resources and service availability Hencethe removal of redundant data storage will enable storingmore information into a single blockwith the sameblock sizewhich can significantly improve the transaction processingspeed Moreover cooperation between nodes can effectivelyimprove the efficiency of the entire IoT system

321 Trust-Based Consensus Management Protocol As wehighlighted in Section 21 many consensus managementprotocols have been developed in both permissioned andpermissionless blockchain networks to minimize the com-puting resources required for mining minimize miningdelay and improve robustness against a large number ofdistributed nodes However all these techniques were inthe assumption of the trustless nature of blockchain eventhough the trust factor places a major role in the blockchainecosystem ranging from choosing the right business partnerfor trustworthy service provisioning to creating a trust-worthy mining process Therefore we identify trust as animportant property on validating the blocks in the proposedTrustChain and provide comprehensive details on how to

achieve it in this section In contrast towell-known consensusmining techniques like PoW PoS and PoA the algorithmproposed here is uniquely identified as Proof-of-Trust (PoT)throughout this paper

In the TrustChain or even in other blockchain versionsminersrsquo task is to verify individual data blocks and con-nect them with the genesis chain However to be a minerin conventional mining schemes miners must have eithercomputational power wealth authority or similar type ofadvantage over others Similarly in the PoT method a groupof nodes who have maintained higher-level trustworthinessare chosen as the governing property to be selected asminers or ldquoTrust Bloggersrdquo (TB) in the TrustChain networkFurthermore in the consensus process in PoW anyone witha mining rig can participate in consensus and miners canjoin and leave the network without impacting consensus Onthe other hand Byzantine Fault Tolerance (BFT) mining-based methods use the centralized validator list chosen bya central authority Even though BFT based methods showgood performance against the use of efficient resources as theunderlying mechanism is based on a voting system it stilllacks the decentralized nature of mining as the selection of


TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk

Figure 9 Consortium of Trust Bloggers (TBs) and Trust Blogger Pools (TBPs) in the TrustChain network

validators is controlled by the centralized manner in permis-sioned blockchain networks [29] In such cases anyone canspin up a validator but it can only participate in consensusif the authority adds the new node to the validator list Thisrequirement for a recommended validator list means thatBFT follows a closed membership system

Motivated by the BFT based methods a voting systemrelying on the trust service is used in the TrustChain networkfor the consensus mining process However the selectionof TBs in the TrustChain network is not controlled by acentral authority and allows any node who has enoughtrustworthiness to be selected as a blogger In TrustChaineach TB decides which other TB they trust using the trustmanagement services given under the Trust Service Compo-nent as disuse in Section 31 The list of TBs is called the TrustBlogger Pool (TBP) in the context of TrustChain Dependingon the network size service distribution type of TrustChainand availability of Trust Attributes to calculate trust multiplesegments of TBPs with various pool sizes and overlappingsections create the global TBP which covers the whole IoTnetwork strengthening the distributed nature of IoT furtheras shown in Figure 9 Due to the open membership natureof TBP anyone can spin up a validator and participatein consensus because there is no single master authoritydeciding which nodes get to participate in the consensusprocess Inherently it allows for growing decentralizationunlike BFT as more and more nodes are added to thenetwork and form new pools around themmaking it difficultfor a malicious miner to interfere with the voting processFor example unlike PoW or BFT based systems no singleparty can own 51 of a global trust network in TrustChaintechnology as the selection of TBs based on trustworthinessin contrast to factors like computing power authority andwealth which can be controlled to gain unfair advantages

However whenpools are not overlappingwith each otherthere is a possibility that different pools may maintain adifferent copy of the TrustChains and it will put the overallconsensus mechanism in jeopardy In such cases a smartcontract between the disjoint TBPs can be created to continue

the voting process while preserving their pool sizes as theyare On the other hand a limited number of trustworthyauthorities like government control bodies can be selected asthe TBs to overcome any disjoints assuming their inheritedtrustworthiness Yet the later solution might reduce thepower of the decentralized architecture of the TrustChainto some extent Therefore it is important to consider aminimum level of trustworthiness when it comes to theselection of TBs to avoid disjoint TBPs

In contrast to BFT based methods we propose to use theREK model discussed in Section 22 based on our previouswork [14] to assist the TB selection process We follow thesame procedurementioned in (11) to calculate the ExperienceTM and Reputation TM However TAs which represent theKnowledge TM must be redefined to grasp the true featuresof TBs including its social properties and dependable prop-erties TAs which define social properties like ColocationCowork Cooperativeness Frequency Length of InteractionsMutuality Centrality and Community of Interest assist tocatch howwell the TBs have behaved in the past to uphold themoral standards of the TrustChain networkwhile dependableTAs like reliability availability safety integrity maintainabil-ity and confidentially [30]There aremanymodels that can beseen in the literature to quantify dependable properties like in[30ndash32] Therefore this paper formulates numerical modelsto analyze social TAs as described in Section 31 based on ourprevious work in [14] Once both social and dependable TAsare calculated a cumulative score for Knowledge TM can beobtained as in (2) Further combining it with (11) the trustvalue of each candidate TB can be modeled as in (3)

119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)

Where TrustTB represents the trustworthiness of TB andKTB ETB and RTB denote the TMs based on knowledgeexperience and reputation Based on the trust value of TBsone who has the highest trustworthiness is chosen as the


NodesCandidate TBsLeader Trust Service

Send Data for Trust Assessment

Trust Assessment

TrustAssessment

Broadcast Votes for Validation

Broadcast Leader Selection

Prospective Candidate ListVoting on Prospective Candidate List

Candidate TB Selection Broadcast Candidate TB

Selection

Send Message + Signature for validation

Message Verification TF

Leader Selection

Add or remove the message based on votes

Broadcast the decision

Extract Trust Feature for Trust Assessment




TBP SelectionTransaction Validation

Figure 10 Trust-based consensus management protocol

leader for a specific TBP and broadcast it to other nodes inthe pool with the leaderrsquos digital signature Upon receivingthe signature from the leader other nodes can verify it andthen acknowledge it with their own signatures The leader ismainly responsible for managing the consensus process untilits term period has expired Once the term of a leader hasexpired a new leader must be chosen based on the highesttrustworthiness value of a node

After a leader is elected he chooses a list of deputycandidates for the blogging or in other words the validatingprocess In order to select such TB candidate list the leaderTB evaluates his trust relationships with other prospectivecandidates for TBs and chooses the ones that have the highesttrust relationships with him To determine the satisfactorymargin of trustworthiness a threshold value or machinelearning approach is used as described in [14] Then theleader TB sends the list to other nodes to cross-check theirrelationship with the selected TB list If the other nodes arehappywith the trust level they can respond back to the leaderwith their approval or simply ignore it to show the disprovalThen based on the votes from nodes the ones who havehigher votes will be selected as the final candidate list for theblogging process and will be broadcast back again to informthe other nodes in the poolThe overall process of selecting aleader and candidate TB list is shown in Figure 10

Once the leader and candidate TB list are decided nodescan initiate transactions and broadcast messages to the TBPwith their signatures which can be generated by taking thehash of both the message and their Secret Key (SK) as in (4)

Furthermore freedom is given to the message generator toencrypt messages using a suitable encryption mechanism orto anonymize the data depending on the privacy requirementin contrast to conventional blockchains Upon receiving theseblocks by TBs they can first validate the message usingverification function denoted in (5) and the senders PublicKey (PK)

119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)

Then based on the result of the verification function eachTB can vote for adding this specific message to a block in thegenesis chain If the leader receives votes to include the blockin the genesis chain it generates a header for the message andthe resulting block is added to the existing chain If he receivescontradictory votes or votes do not have a majority then themessage is ignored as it can tamper withmalicious intentionsThe process of adding each new block to a genesis chain isshown in Figure 10

33 Smart Contract Service Smart contracts are simply self-executing and immutable codes that reside in a blockchainThey essentially remove the need for a central broker dueto their self-executing nature and can be triggered uponreceiving a request from IoT nodes other TrustChains orby the smart contract itself based on the self-triggering rulesinside the contract In theTrustChain service smart contractsare stored in a separate chain to improve the efficiency


associated process like creating storing executing andterminating The registry component in the smart contractservice basically register newly deployed contracts by issuingan address name and version and help to track the outcomeof the contract once it is initiated by storing the hash ofthe result A secure container includes a secure operatingsystem smart contract language runtime environment anda software development kit to create and run the smartcontracts within the TrustChain service

Even though smart contracts work in a trustless mannerafter signing the contract it is beneficial to have a trustevaluation mechanism in place before the contract is signedto implement proactivemeasures to avoid contract violationsHence smart contract service discussion is coupled with thetrust service to identify accountabilities and enforce themautonomously For example let us consider a distributedmarket place in a smart city use case in which stakeholderexchange goods for cryptocurrencies In a normal conditionthe seller must ship the items as soon as he received thetransaction from the customer On the other hand in caseof the seller deliberately delaying the shipment the smartcontract will be triggered and money will be refundedto the customerrsquos account However this process mightinvolve some transaction fees and a waste of effort in theperspective of the customer Hence to avoid such outcomethe trust service is used to evaluate the trustworthiness of theprospective sellers based on the REKmodel discussed in [14]and recommend appropriate stakeholders before establishingthe smart contract

Let us assume Alice (a) the IoT user needs to find agood banker say Bob (b) and they need to establish a smartcontract for their mutual interactions For the generality letus take the trust level between any IoT nodes ldquoardquo and ldquobrdquo withrespect to arsquos preference being denoted by Trustab similar toconcepts discussed in Section 32 and our previous work [12ndash14] Then the trust level between ldquoardquo and ldquobrdquo is calculated asin

119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)

where Eab denotes the experience between ldquoardquo and ldquobrdquo Rabcalculates the reputation of ldquobrdquo and 120572 and 120573 are normalizingcoefficients to bring the final scores in between 0 and 1Note thatwe have deliberately omitted calculatingKnowledgeTM as it needed personal information to evaluate the trustbased on knowledge To calculate the Experience TM andReputation TM we recall the concept of directed graphtheory from Section IV of [27] as in Figure 11 Note thatFigure 11 only shows the relative interaction distance amongeach other and it does not represent the actual physicaldistance between them

Let us take TA evaluation of the 119895th transaction with nodex as vx(j) successfulness of the 119895th transaction with nodex as ax(j) and time attenuation function between currenttime and transaction time wrt node x as tx(i t) Then theexperience between ldquoardquo and ldquobrdquo can be calculated as in

119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)

where H denotes the hop distance to the trustee ldquobrdquo 119879119867119886119887represents the transition matrix between ldquoardquo and ldquobrdquo andunique value at (ab) of the 119879119867119886119887 represents the connectionbetween ldquoardquo and ldquobrdquo and tx(i t) with respect to arbitrarynode x can be calculated as in (8) However the evaluation ofvx(j) is context and content dependent and TAs that governsthe particular transaction must be intelligently selected inorder to evaluate the vx(j) For example TAs like responsetime timely delivery quality of the productservice and feesassociated can be taken into consideration in this exampleMoreover successfulness of the 119895th transaction denoted byax(j) can be defined based on the criticalness of the applica-tion For example it can be either 0 or 1 for strict applicationswhile it can be varied in between for other cases

119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)

where 120572 and 120573 represent the threshold values that adjustthe importance of the transaction in consideration relativeto the current time If the application demands more recenttransaction in order to evaluate the trust then 120573 must beset very close to the origin Following the same procedureas above and the model discussed in Section IV of [27] thereputation of ldquobrdquo can be calculated as in

119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)

where vn(j) an(j) and tn(i t) take their useful meaning asdiscussed above but with respect to node ldquonrdquo or else theyrepresent the reputation value of ldquobrdquo with respect to nodeldquonrdquo Note that the hop count from node ldquobrdquo is limited to sixhere based on the ldquosmall world problemrdquo discussed in [33]in which authors argue that any node is reachable withinthe range of six hopes Further based on the 119899th value thereputation is attenuated by a factor of d(n) as in (10) to reducethe effect of reputation that far away nodes hold on to nodeldquobrdquo

119889 (119899) = 7 minus 1198996 (10)

After that the final trust score of the node ldquobrdquo with respectto ldquoardquo can be obtained by substituting (7) and (9) into (6) asshown in

119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb

Figure 11 Experience and Reputation flow among IoT nodes

Further TrustChain is designed with the requirementof interoperability in mind to enable DEX Due to theautonomous nature of executing prearranged rules and alsoits ability to become embedded inside TrustChain networkssmart contracts provide a promising approach to implementDEX in the TrustChain network Having DEX capability notonly assists in maintaining a different ledger in TrustChainfor different services like Data Transactions Trust Pol-icyMembership and Smart Contracts itself but also allowscommunication with external blockchains whenever neces-sary minimizing content exposure preserving privacy of theusers as well as their data Nevertheless this type of smartcontract based DEX enables the deployment of complex usecase scenarios like a smart city with millions of IoT nodespossessing different resources and service subscriptions Forexample Figure 12 illustrates a scenario where several dis-tributed ledgers interact together through the smart contractledger In such a framework a node can deposit its datain ldquoData Ledgerrdquo transactions based on cryptocurrencies inldquoTransactions Ledgerrdquo and create execute or terminate smartcontracts via the ldquoSmart Contract Ledgerrdquo Consequentlyassociated managing functions related to the above examplewill be triggered through the smart contract ledger by theldquoTrust Service Ledgerrdquo and ldquoPolicy andMembership Ledgerrdquo

TrustChainmust ensure the privacy of the stakeholders inboth internal and external interactions whenever possible asper the GDPR Hence we propose to use the concept of ZeroKnowledge Proof (ZKP) to hide the user information wheninteracting with service providers through smart contracts[34] Let us assume an IoT node belonging to Alice (Prover)needs to retrieve confidential documents fromBob (Verifier)For that Alice needs to prove her identity to Bob by providingher Name Date of Birth and Social Security Number (SSN)However if she provided this information Bob can use thisdata for other purposes like user profiling or share it withthird parties for monetary gain To avoid that ZKP canbe used to prove the identity of Alice without sending theactual information her In order to improve the robustnessof the algorithm against hiding identity information this

paper proposes to combine the ZKP with DiffiendashHellmankey exchange algorithm [35] to create a novel consensusprotocol for smart contracts on hiding personal data as in theAlgorithm 1

Note that Bob and Alice share only g p and theirpublic keys (k1 k2)There is no way that an eavesdropper caninterfere with the identification process without knowing thesecret keys of Alice and BobMoreover what is inside the twohash functions C and Crsquo must be similar in order to satisfythe condition C= Crsquo Hence essentially Alicesrsquo commitment tmust be equal to trsquo as shown in

1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)

34 Membership and Policy Service By design TrustChainplatform is developed as a permissioned type of blockchainto control the privacy matters associated with a publicblockchain and support business requirements demandsby the service providers Therefore all nodes who need aTrustChain service are required to register with the mem-bership services in order to obtain an identity to accessthe distributed services in TrustChain such as carrying outtransactions obtaining services offered by service providersinteracting with smart contracts etc However as there are nocentralized authorities in a TrustChain network to managesuch credentials the responsibility relies on the TB withthe support from the trust service discussed in Section 31The selection of TBs is discussed in Section 32 underthe consensus management protocol Fundamentally whenassigning an identity by TB to a prospective node it willfirst evaluate the trustworthiness of the node with respect tothe services he is demanding The trust evaluation processfollows a similar approach as discussed in previous sectionsand if the trust level is at the expectation level the nodeis granted to enter the TrustChain network with restricted


StoreHash(Data)

Trust Service Ledger

IoT Node

Smart Contract Ledger

Transactions Ledger

Policy amp Membership

Ledger

Data Ledger

StoreHash(Transactions)Update

Update

ManageMembershipManagePolicy

EvaluateTrust

CreateSmart_Contracts

1

23

1

3

44

Figure 12 TrustChain distributed and interoperable ledgers

1 Trust Service selects two large random prime numbers p (Prime) and g (Generator) st256ltpg 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 k1=g

x mod p and sends it to Bob4 Bob takes the hash of his request and store in y st 0ltyltp5 Bob calculates k2=g

y mod p and sends it to Alice6 Alice calculates the shared secret key sk= (k2)

xmod p7 Bob calculates the shared secret key sk= (k1)

ymod p8 Alice generates another random oracle v st 0ltvltp9 Alice calculates her commitment t=(1198961)v +(119904119896)v10 Alice calculates the challenge C=SHA256(g sk t)11 Alice sends the response r=(vx ndash Cx) mode p and challenge C to Bob12 Bob calculate the commitment 1199051015840= gr (k1)

C +(k2)r (sk)

119862 and challenge 1198621015840=SHA256(g sk 1199051015840)13 If C=1198621015840 Bob can satisfy that Alice has provided the requested information

Algorithm 1 ZKP with DH to Suppress Personal Information Exposure

permission based on his trust level It is up to the node tobehave and collaborate in a good manner to improve hisreputation over the time if he needs to access more advancedservices including becoming a TB

Policy services mainly manage areas such as preservingthe privacy of the prosumers monitoring consents meetingconsensus rules and ensuring accountability in case of policyviolations In this regard the trust service can support totrack such rules to detect violations beforehand and takenecessary countermeasures in case of an incident alreadyoccurring A more detailed version of implementing such asystem is discussed in our previous work [13] in compliancewith GDPR legislation when it comes to privacy matters

4 Discussion

41 TrustChain vs Privacy Compliance The initial versionsof blockchains like Bitcoin [16] and Ethereum [26] weredesigned and developed to facilitate trustless data man-agement transparency and promote the decentralizationaspects However they lack the fundamental requirement ofprivacy when it comes to managing personal and propri-etary information in an IoT ecosystem Several blockchain

technologies were invested later to rectify these privacy issuesbased on the permissioned and private blockchain conceptslike Hyperledger Fabric [23] However due to interferencefrom centralized authorities in managing membership andconsensus protocols they also had to compromise the initialproperties of blockchains like decentralization capabilitiesand scalability in a setting like the IoT

In contrast TrustChain is designed in such a way that itonly stores the information allowed by the users Techniqueslike ZKP encryption and anonymization are used to hidethe sensitive data while communicating amongst relevantstakeholders and evaluate trust accordingly without affectingthe privacy The ZKP algorithm suggested in the text is oneof the promising techniques used in the TrustChain to com-municate amongst parties without revealing their personalinformation This property satisfies the GDPR requirementsunder the right to object processing and right to control profilingusing personal information Further it allows encryptionand other anonymization techniques within TrustChain tohide delicate information as it is not required to maintaina public ledger system like in a Bitcoin blockchain Hencethe user is given the right to restrict processing as per theGDPR legislation On other hand an application of parallel


distributed architectures enables the storing of sensitive datain a local database and linking the data toTrustChain througha cryptographic link which in fact allows the user to removedata from the TrustChain whenever necessary thus satisfyingGDPR conditions under the right to erasure in addition to theright to data portabilityMoreover the underlying technologyof the TrustChain service is built upon a trust managementsystem and hence every interaction is monitored and trust isevaluated accordingly to support future interactionsThis factessentially enables the accountability principle and allows theuser to inform how its data is being used as demanded by theright to be informed condition in GDPR

42 TrustChain vs EdgeComputing Typically an IoT ecosys-tem represents nodes ranging from small sensors (which onlyemit) data to massive complex data centers (which processbillions of interactions per time) In the edge computingsetup these small sensors can be found at the bottom of thehierarchy Nodes that have a comparatively higher processingpower and storage lie in the middle of the network andlarge data centers represent nodes at the cloud layer It ischallenging to implement conventional blockchain technolo-gies towards the end of hierarchy due to associated resourcerestrictions to perform consensus algorithms and limitedstorage to store the massive public ledger In contrast theconsensus protocol in TrustChain is simply a combination oftrust and BFT and so computation power that can broadcasta set of messages is more than enough to implement theconsensus algorithm Therefore TrustChain can be easilydeployed towards the end of edge computing hierarchyFurthermore a lightweight protocol enables efficient pro-cessing of blocks while saving more energy compared totraditional blockchain technologies in which a rig of minersmust coordinate with each other to solve a highly complexcryptographic puzzleThis in fact improves the performanceof the overall system and prevents divergence of the ledgeras nodes do not need to wait for much longer to identifythe correct copy of the ledger in contrast to a traditionalblockchain in which it can take at least ten minutes to adda new block to the genesis chain

Moreover TrustChain uses a permissioned identity man-agement protocol when selecting suitable validators likein Hyperledger Application of TBP in TrustChain enablesus to expand the TrustChain network just like in Bitcoinblockchain networks in contrast to Hyperledger in whichcentralized authority is used to select the validators Furtherthe trust service in the TrustChain works collaborativelywith membership and policy services to identify trustworthyTB and discourage malicious nodes entering the TrustChainnetwork contributing to the mining process This makes theconsensus protocol described in Section 32 nearly immutableas only trustworthy nodes are given permission to performthe mining process

According to TrustChain architecture Trust Broker Pool(TBP) is a small portion of the global pool which consistsof millions of overlapping TBPs One TBP contains 51of trust nodes means more than half of the global IoTnodes trust each other This scenario is practically impossibleto occur as it is impossible to create such a large trust

network by an individual or even by multiple organizationsas trust depends on many factors as discussed in the paperFurther let us assume 51 computing power is control byone organization In such a situation this organization cancreate a TBP consisting of all of their computers Howeverit is highly unlikely that all other nodes external to thisspecific TBP would trust all nodes inside one TBP in anycircumstance Therefore this specific TBP cannot interferewith the decision-making process as TrustChain consensusprotocol is not based on the computer power but only ontrustworthiness Thus having 51 computing power is alsouseless in TrustChain network to interfere with the consensusprocess

In addition the trust service is useful to check theintegrity of the data generated by IoT nodes as describedin Section 31 This feature not only improves the overallexperience of the prosumers but also guarantees accountabil-ity in case of a policy or privacy violation In comparisonto traditional versions of blockchain it is only availablewith the TrustChain platform as we discussed previouslyFurther most of the numerical results based on the trustare carefully analyzed in our previous work [12ndash14 36]and thus not repeated here However Table 3 summarizesthe effectiveness of the proposed TrustChain architecturerationally over existing blockchain technologies as discussedin this work

5 Conclusions

TrustChain is a permissioned blockchain network designedto enhance the privacy of its prosumers while improvingthe efficacy of TrustChain service compared to traditionalblockchain technologies specifically in a distributed envi-ronment like the IoT The major difference of TrustChaincompared to traditional alternatives is the application ofcomputational trust on realizing various functions inside theTrustChain service Among them evaluation of trust allowed(i) developing a novel lightweight consensus managementprotocol by combining with the BFT protocol (ii) measur-ing the trustworthiness of participating prosumers beforecreating smart contracts and before initiating interactionsamong them (iii) the membership and policy services to takeintelligent decisions when adding new nodes to the networkselecting TBs and realizing the accountability in case ofconsensus privacy or consent violation and (iv) checking theintegrity of each interaction before adding them to the genesischain

Moreover TrustChain empowers the edge computingarchitecture of IoT due to its survivability with low com-puting and storage resources which is not the case withtraditional approaches Nevertheless this prevents the needfor centralized processing such as at the cloud allowingimplementing innovative privacy preserving solutions at theFog and the ROOF via TrustChain membership and policyservices However it is important to allow vertical services inparallel with horizontal services to facilitate many intelligentsolutions To enable such services a decentralized exchange isintroduced based on the smart contract concept to negotiateamong vertical layers to combine data and services in a


Table 3 TrustChain vs traditional Blockchain technologies

Property Bitcoin Ethereum Hyperledger TrustChainPermission Restrictions Permissionless Permissionless Permissioned PermissionedConsensus PoW PoW PBFT Trust+BFTEnergy Saving No Partial Yes YesDecentralized Regulation Yes Yes Partial YesSmart Contracts No Yes Yes Yes

Scalability Node High High Low HighPerformance Low Low High High

Immunity25 of theComputing

power51 of Stake 333 of faulty

replicasNearly

Immutable

Native Currency Yes Yes No PossibleIncentive Mining Fee Mining Fee No TrustBlockchain as a control chain No No No Yes

Privacy No No Partial Yes (eg withZKP)

GDPRPrivacyCompliance

Right to

be informed No support No support No support Supportaccess Support Support Support Support

rectification No support No support No support Supporterasure No support No support No support Supportrestrict

processing No support No support Support Support

dataportability No support No support Support Support

objectprocessing No support No support Partial Support

controlprofiling No support No support Partial Support

vertical manner via TrustChain and beyond that Never-theless TrustChain acts in a control layer in such cases tominimize the ledger size and enable an efficient orchestrationamong different services Further TrustChain is embeddedwith unique techniques to improve privacy when dealingwith delicate personal information and to comply with GDPRlegislation for example using concepts like ZKP encryptionand anonymization

Data Availability

No data were used to support this study

Conflicts of Interest

The authors declare that there is no conflict of interestregarding the publication of this paper

Acknowledgments

This work was supported by the Institute for Informationamp Communications Technology Promotion (IITP) grantfunded by the Korea government (MSIT) [2018-0-00261GDPR Compliant Personally Identifiable Information Man-agement Technology for IoT Environment] and this study

was financially supported by Hanbat National Universityfinancial accounting research fund 2018 year

References

[1] A Opher A Onda A Chou and K Sounderrajan The Riseof the Data Economy Driving Value through Internet of ThingsData Monetization IBM Corporation Somers NY USA 2016

[2] M SeliemK Elgazzar andKKhalil ldquoTowards privacy preserv-ing iot environments a surveyrdquo Wireless Communications andMobile Computing vol 2018 Article ID 1032761 15 pages 2018

[3] EuropeanUnion ldquoGeneral data protection regulation (GDPR)rdquoOfficial Journal of the European Union vol L119 pp 1ndash88 2016

[4] H Tianfield ldquoTowards edge-cloud computingrdquo in Proceedingsof the 2018 IEEE International Conference on Big Data (BigData) pp 4883ndash4885 Seattle WA USA December 2018

[5] W Yu F Liang X He et al ldquoA survey on the edge computingfor the internet of thingsrdquo IEEE Access vol 6 pp 6900ndash69192018

[6] V Moysiadis P Sarigiannidis and I Moscholios ldquoTowardsdistributed data management in fog computingrdquo WirelessCommunications and Mobile Computing vol 2018 Article ID7597686 14 pages 2018

[7] M T Beck M Werner S Feld and S Schimper ldquoMobile edgecomputing A taxonomyrdquo in Proceedings of the in Proceedings


of the Sixth International Conference on Advances in FutureInternet pp 48ndash55 2014

[8] S Yi C Li and Q Li ldquoA survey of fog computing conceptsapplications and issuesrdquo in Proceedings of the in Proceedings ofthe 2015 workshop on mobile big data pp 37ndash42 2015

[9] W Shi and S Dustdar ldquoThe promise of edge computingrdquoComputer vol 49 no 5 pp 78ndash81 2016

[10] T T Dinh R Liu M Zhang G Chen B C Ooi and JWang ldquoUntangling blockchain a data processing view of block-chain systemsrdquo IEEE Transactions on Knowledge and DataEngineering vol 30 no 7 pp 1366ndash1385 2018

[11] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoBlockchain technology is it a good candidate for securing iotsensitive medical datardquo Wireless Communications and MobileComputing vol 2018 pp 1ndash11 2018

[12] U Jayasinghe A Otebolaku T-W Um and G M Lee ldquoDatacentric trust evaluation and prediction framework for IOTrdquo inProceedings of the 9th ITU Kaleidoscope Academic ConferenceChallenges for a Data-Driven Society ITU K 2017 pp 1ndash7Nanjing China November 2017

[13] U Jayasinghe G M Lee and A MacDermott ldquoTrust-baseddata controller for personal information managementrdquo inProceedings of the 2018 International Conference on Innovationsin Information Technology (IIT) pp 123ndash128 Al Ain UAENovember 2018

[14] U Jayasinghe G M Lee T W Um and Q Shi ldquoMachinelearning based trust computational model for IoT servicesrdquoIEEE Transactions on Sustainable Computing pp 1-1 2018

[15] AMeloni SMadanapalli S KDivakaran et al ldquoExploiting theIoTpotential of blockchain in the IEEEP19311 ROOF standardrdquoIEEE Communications StandardsMagazine vol 2 no 3 pp 38ndash44 2018

[16] S Nakamoto Bitcoin A Peer-To-Peer Electronic Cash System2008

[17] J Sousa A Bessani andMVukolic ldquoAbyzantine Fault-Tolerantordering service for the hyperledger fabric blockchain plat-formrdquo inProceedings of the 48thAnnual IEEEIFIP InternationalConference on Dependable Systems and Networks DSN 2018 pp51ndash58 June 2018

[18] J Kang Z Xiong D Niyato P Wang D Ye and D I KimldquoIncentivizing consensus propagation in proof-of-stake basedconsortium blockchain networksrdquo IEEE Wireless Communica-tions Letters vol 8 no 1 pp 157ndash160 2019

[19] X Fan and Q Chai ldquoRoll-DPoS a randomized delegatedproof of stake scheme for scalable blockchain-based internet ofthings systemsrdquo in Proceedings of the the 15th EAI InternationalConference on Mobile and Ubiquitous Systems ComputingNetworking and Services pp 482ndash484 New York NY USANovember 2018

[20] L M Bach B Mihaljevic and M Zagar ldquoComparative analysisof blockchain consensus algorithmsrdquo in Proceedings of the 41stInternational Convention on Information and CommunicationTechnology Electronics and Microelectronics MIPRO 2018 pp1545ndash1550 May 2018

[21] Z Zheng S Xie H Dai X Chen and H Wang ldquoAn overviewof blockchain technology architecture consensus and futuretrendsrdquo in Proceedings of the 6th IEEE International Congress onBig Data BigData Congress 2017 pp 557ndash564 June 2017

[22] S King and SNadalPpcoin Peer-To-Peer Crypto-CurrencywithProof-Of-Stake vol 19 self-published paper 2012

[23] C Cachin ldquoArchitecture of the hyperledger blockchain fabricrdquoin Proceedings of the Workshop on distributed cryptocurrenciesand consensus ledgers 2016

[24] F Schuh and D Larimer ldquoBitshares 20 general overviewrdquo2019 httpscryptoratingeuwhitepapersBitSharesbitshares-generalpdf

[25] N Szabo ldquoFormalizing and securing relationships on publicnetworksrdquo First Monday vol 2 no 9 1997

[26] GWood ldquoEthereum A secure decentralised generalised trans-action ledgerrdquo Ethereum Project Yellow Paper vol 151 pp 1ndash322014

[27] U Jayasinghe N B Truong G M Lee and T-W Um ldquoRpRa trust computation model for social internet of thingsrdquo inProceedings of the Ubiquitous Intelligence ampamp ComputingAdvanced and Trusted Computing Scalable Computing andCommunications Cloud and Big Data Computing Internetof People and Smart World Congress (UICATCScalComCBDComIoPSmartWorld) Intl IEEE Conferences pp 930ndash9372016

[28] S Liu J Wu and C Long ldquoIoT meets blockchain paralleldistributedarchitecture for data storage and sharingrdquo in Pro-ceedings of the IEEE International Conference on Blockchain p1 Halifax Canada 2018

[29] J Kwon ldquoTendermint Consensus without miningrdquo RetrievedMay p 2017 2014

[30] M Al-Kuwaiti N Kyriakopoulos and S Hussein ldquoA compara-tive analysis of network dependability fault-tolerance reliabil-ity security and survivabilityrdquo IEEECommunications Surveys ampTutorials vol 11 no 2 pp 106ndash124 2009

[31] A Avizienis J Laprie B Randell and C Landwehr ldquoBasicconcepts and taxonomy of dependable and secure computingrdquoIEEE Transactions on Dependable and Secure Computing vol 1no 1 pp 11ndash33 2004

[32] G Hatzivasilis I Papaefstathiou and C Manifavas ldquoSoftwaresecurity privacy and dependability Metrics and measure-mentrdquo IEEE Software vol 33 no 4 pp 46ndash54 2016

[33] J Travers and S Milgram ldquoThe small world problemrdquo Phychol-ogy Today vol 1 no 1 pp 61ndash67 1967

[34] M Blum P Feldman and S Micali ldquoNon-interactive zero-knowledge and its applicationsrdquo in Proceedings of the 20thAnnual ACM Symposium on Theory of Computing STOC 1988pp 103ndash112 May 1988

[35] W Diffie andM E Hellman ldquoNew directions in cryptographyrdquoIEEE Transactions on Information Theory vol 22 no 6 pp644ndash654 1976

[36] U Jayasinghe H W Lee and G M Lee ldquoA ComputationalModel to Evaluate Honesty in Social Internet of Thingsrdquo inProceedings of the 32nd ACM SIGAPP Symposium On AppliedComputing pp 1830ndash1835 Marrakesh Morocco 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018


Active and Passive Electronic Components

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of



Journal ofEngineeringVolume 2018

SensorsJournal of



RotatingMachinery


Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation


Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom


applications and thus cannot satisfy the requirements ofultra-low delay sensitive IoT applications such as a real-time computer vision for smart city security It not onlyheightens the issues associated with scalability and latencybut also makes IoT nodes more vulnerable for privacy andsecurity threats including lack of control over personaldata hence unauthorized user profiling and identity theftfake knowledge propagation network eavesdropping illegalinvasion and denial of service (DoS) attacks

On the other hand a hierarchical edge computing archi-tecture can resolve the issues associated with centralizedarchitectures by pushing data pipeline functions towardsthe edge of the IoT networks depending on the resourceavailability and application requirements [4 5] Deploymentof such an architecture is beneficial in building an ecosysteminvolving content providers application developers networkequipment vendors third-party partners and middlewareproviders and thereby improving the end-user experiencedramatically due to powerful and energy efficient computingpower at hand low latency mobility location and context-aware support for IoT applications [6ndash8] However edgecomputing alone cannot support the safeguarding of theprivacy of the stakeholders as it introduces a new set ofvulnerabilities due to multiple attack surfaces closenessto sensitive data generators heterogeneity of the deviceresources the scale of the network and difficulty of assessingthe trustworthiness of participating stakeholders [9]

The fundamental concept behind blockchain technologyprovides a promising approach to establish a healthy inter-action among untrustworthy and unknown entities whilesupporting the distributed nature of IoT eliminating the needof a central authority as in cloud computing architectures[10 11] The main technology of the blockchain lies behindthe use of an immutable public record of data called ldquopublicledgerrdquo shared among all participants The ledger consistsof blocks of data which are linked with each other by acryptographic hash key and the process of linking is termedldquoProof of Workrdquo (PoW) However adopting the blockchaintechnology as it is in the IoT environment is quite challengingdue to the exhaustive computation power required to solvePoW puzzles with resource-constrained IoT devices Thedelay associated with the mining process is not suitable forreal-time IoT applications in addition to scalability issuesassociated with blockchain and further overhead created byblockchain consensus algorithms

Motivated by the facts stated above we first proposea novel variation of blockchain called TrustChain whichremoves the need for PoW by utilizing trust evaluationconcepts discussed in our previous work [12ndash14] In generalthe concept of trust can be seen as a metric that is usedto evaluate stakeholders in consideration of mutual benefitscoordination and cooperation Perception of trust is oftenachieved with direct observations through experience andbased on the beliefs and opinions of others who are aroundit as we discussed in [14] This paper also discusses aprivacy perceiving edge computing architecture based on theconcepts of ROOF (ROOF Real-Time Onsite OperationsFacilitations) Fog andCloud computing concepts [15]Thenwe further extend the idea of TrustChain based on the

permissioned blockchain concepts tomatch with the require-ments at each layer of the proposed distributed architectureWe use a smart city use case to demonstrate the proposedideas in all three cases above

The structure of this paper is as follows Section 2presents the concepts and underlying principles of traditionalblockchain technologies and trust evaluation in general tosupport the proposed ideas in the following sections Sec-tion 3 focuses on the details of TrustChain and underlyingmechanisms compared to typical blockchains Section 4discusses the importance of the proposed TrustChain whenrealizing privacy preserving and trustworthy services in adistributed environment and Section 5 concludes the paper

2 Preliminaries

In this section we briefly introduce the concepts and under-lying technology associated with traditional blockchains andtrust evaluation In the context of TrustChain we utilize theseconcepts to develop a novel blockchain technology to removethe issues related to privacy and efficient use of resources in adecentralized setting like the IoT

21 Blockchain Overview Blockchain technology is one ofthe highly researched topics in the recent years due to itsdistributed and immutable data storage mechanism enablingapplications in almost any area including banking supplychain and other transaction networks like IoT The conceptof blockchain was first introduced by Satoshi Nakamoto[16] as the fundamental technology of the digital cryp-tocurrency called Bitcoin The use of blockchain in publicand distributed ledgers for Bitcoin transactions made it thefirst cryptocurrency not only to transact digital money in asecurely and inexpensive manner but also to resolve the long-standing problem of ldquodouble spendingrdquo without the need fora trusted and powerful third-party By nature blockchaintechnology is inherently resistant to data modification dueto its public ledger and the consensus mechanism calledPoW Once recorded data in any given block cannot bealtered retroactively as this would invalidate all hashes inthe previous blocks in a blockchain and break the consensusagreed among nodes voiding the blockchain

211 Blockchain Architecture Blockchain can be basicallyconsidered as a chain shaped data structure in which achain of blocks are connected with each other through anaddress pointer based on a hash value ie blockchain isa shared decentralized and distributed state machine Thismeans that all nodes independently hold their own copy ofthe blockchain and the current known ldquostaterdquo is calculatedby processing each transaction in order as it appears in theblockchain Each block of a blockchain typically containssix parts hash of the previous block nonce (ldquonumber usedoncerdquo) the hash of the current block Merkle root (hash ofmultiple transactions) timestamp and transaction data asshown in Figure 1

In the context of Bitcoin transactions generally consistof the senderrsquos address recipients address and the valueHowever depending on the application this can vary The


Block n-1Header

Tx

Tx Transactions

Block n

Header

Tx

Block n+1Header

Tx


HeaderMetadata


Merkle Root

lowast lowast







HashNumber

isHash lt Target

+

New Nonce

Target Value

MiningDifficulty

Solved and Publish

block

Mining Reward

++

No

Yes

Block n-1

Header

Tx

Block n

Header

Tx

Algorithm


Block



















TRUST


K1 Kn E1 En R1 Rn

Trust Attributes

Trust Attributes

Trust Metrics

sum




119870119894119895 = 12057211198701 + 12057221198702 + + 120572119899119870119899119864119894119895 = 12057311198641 + 12057321198642 + + 120573119899119864119899119877119894119895 = 12057411198771 + 12057421198772 + + 120574119899119877119899

119879119903119906119904119905119894119895 = 1205791119870119894119895 + 1205792119864119894119895 + 120579119899119877119894119895

(1)






storage mechanism







Trustchain APIs



Membership Services

Policy Services


Registration




Management

Privacy

Secure Container

Life Cycle

RegistryConsensus


Ledger



Trust Management


Trustchain Services



Edge Node)



Home IoT

DTCEN

IoT Trust Agent


Prove Server

LocalTrustChain

Factory IoT

IoT Trust Agent

Prove Server

Fog Layer

ROOF Layer

DTCEN

DTCEN

LocalTrustChain






Data Trust

Privacy Trust

Trust

Entity Trust


SocialAttributes

Relationship

Temporal

Spatial

Competence

Disposition

Dependence

Fulfillment

Willingness

Persistence

Confidence

Validity

Completeness

Uniqueness

Accuracy

Timeliness

Consistency









R E K

R E K

R E K

R E K









Service n

TrustIdM

TrustLinking


Interaction


Other Objects

Trust Agent

TrustData

Collection

TrustData

Filtering


Trust Attribute

Extraction


Statistical

Machine Learning

Numerical

Trust DAO Data

RepositoryTMEAPI

Trust Agent




Rule Policy

Ontology REK



AgentIPFS

DP

DS

Trust

Service i



DC








ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n



Distributed Banking

DEX










TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Block n-1Header

Tx

Tx Transactions

Block n

Header

Tx

Block n+1Header

Tx


HeaderMetadata


Merkle Root

lowast lowast







HashNumber

isHash lt Target

+

New Nonce

Target Value

MiningDifficulty

Solved and Publish

block

Mining Reward

++

No

Yes

Block n-1

Header

Tx

Block n

Header

Tx

Algorithm


Block



















TRUST


K1 Kn E1 En R1 Rn

Trust Attributes

Trust Attributes

Trust Metrics

sum




119870119894119895 = 12057211198701 + 12057221198702 + + 120572119899119870119899119864119894119895 = 12057311198641 + 12057321198642 + + 120573119899119864119899119877119894119895 = 12057411198771 + 12057421198772 + + 120574119899119877119899

119879119903119906119904119905119894119895 = 1205791119870119894119895 + 1205792119864119894119895 + 120579119899119877119894119895

(1)






storage mechanism







Trustchain APIs



Membership Services

Policy Services


Registration




Management

Privacy

Secure Container

Life Cycle

RegistryConsensus


Ledger



Trust Management


Trustchain Services



Edge Node)



Home IoT

DTCEN

IoT Trust Agent


Prove Server

LocalTrustChain

Factory IoT

IoT Trust Agent

Prove Server

Fog Layer

ROOF Layer

DTCEN

DTCEN

LocalTrustChain






Data Trust

Privacy Trust

Trust

Entity Trust


SocialAttributes

Relationship

Temporal

Spatial

Competence

Disposition

Dependence

Fulfillment

Willingness

Persistence

Confidence

Validity

Completeness

Uniqueness

Accuracy

Timeliness

Consistency









R E K

R E K

R E K

R E K









Service n

TrustIdM

TrustLinking


Interaction


Other Objects

Trust Agent

TrustData

Collection

TrustData

Filtering


Trust Attribute

Extraction


Statistical

Machine Learning

Numerical

Trust DAO Data

RepositoryTMEAPI

Trust Agent




Rule Policy

Ontology REK



AgentIPFS

DP

DS

Trust

Service i



DC








ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n



Distributed Banking

DEX










TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia

















TRUST


K1 Kn E1 En R1 Rn

Trust Attributes

Trust Attributes

Trust Metrics

sum




119870119894119895 = 12057211198701 + 12057221198702 + + 120572119899119870119899119864119894119895 = 12057311198641 + 12057321198642 + + 120573119899119864119899119877119894119895 = 12057411198771 + 12057421198772 + + 120574119899119877119899

119879119903119906119904119905119894119895 = 1205791119870119894119895 + 1205792119864119894119895 + 120579119899119877119894119895

(1)






storage mechanism







Trustchain APIs



Membership Services

Policy Services


Registration




Management

Privacy

Secure Container

Life Cycle

RegistryConsensus


Ledger



Trust Management


Trustchain Services



Edge Node)



Home IoT

DTCEN

IoT Trust Agent


Prove Server

LocalTrustChain

Factory IoT

IoT Trust Agent

Prove Server

Fog Layer

ROOF Layer

DTCEN

DTCEN

LocalTrustChain






Data Trust

Privacy Trust

Trust

Entity Trust


SocialAttributes

Relationship

Temporal

Spatial

Competence

Disposition

Dependence

Fulfillment

Willingness

Persistence

Confidence

Validity

Completeness

Uniqueness

Accuracy

Timeliness

Consistency









R E K

R E K

R E K

R E K









Service n

TrustIdM

TrustLinking


Interaction


Other Objects

Trust Agent

TrustData

Collection

TrustData

Filtering


Trust Attribute

Extraction


Statistical

Machine Learning

Numerical

Trust DAO Data

RepositoryTMEAPI

Trust Agent




Rule Policy

Ontology REK



AgentIPFS

DP

DS

Trust

Service i



DC








ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n



Distributed Banking

DEX










TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



TRUST


K1 Kn E1 En R1 Rn

Trust Attributes

Trust Attributes

Trust Metrics

sum




119870119894119895 = 12057211198701 + 12057221198702 + + 120572119899119870119899119864119894119895 = 12057311198641 + 12057321198642 + + 120573119899119864119899119877119894119895 = 12057411198771 + 12057421198772 + + 120574119899119877119899

119879119903119906119904119905119894119895 = 1205791119870119894119895 + 1205792119864119894119895 + 120579119899119877119894119895

(1)






storage mechanism







Trustchain APIs



Membership Services

Policy Services


Registration




Management

Privacy

Secure Container

Life Cycle

RegistryConsensus


Ledger



Trust Management


Trustchain Services



Edge Node)



Home IoT

DTCEN

IoT Trust Agent


Prove Server

LocalTrustChain

Factory IoT

IoT Trust Agent

Prove Server

Fog Layer

ROOF Layer

DTCEN

DTCEN

LocalTrustChain






Data Trust

Privacy Trust

Trust

Entity Trust


SocialAttributes

Relationship

Temporal

Spatial

Competence

Disposition

Dependence

Fulfillment

Willingness

Persistence

Confidence

Validity

Completeness

Uniqueness

Accuracy

Timeliness

Consistency









R E K

R E K

R E K

R E K









Service n

TrustIdM

TrustLinking


Interaction


Other Objects

Trust Agent

TrustData

Collection

TrustData

Filtering


Trust Attribute

Extraction


Statistical

Machine Learning

Numerical

Trust DAO Data

RepositoryTMEAPI

Trust Agent




Rule Policy

Ontology REK



AgentIPFS

DP

DS

Trust

Service i



DC








ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n



Distributed Banking

DEX










TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Trustchain APIs



Membership Services

Policy Services


Registration




Management

Privacy

Secure Container

Life Cycle

RegistryConsensus


Ledger



Trust Management


Trustchain Services



Edge Node)



Home IoT

DTCEN

IoT Trust Agent


Prove Server

LocalTrustChain

Factory IoT

IoT Trust Agent

Prove Server

Fog Layer

ROOF Layer

DTCEN

DTCEN

LocalTrustChain






Data Trust

Privacy Trust

Trust

Entity Trust


SocialAttributes

Relationship

Temporal

Spatial

Competence

Disposition

Dependence

Fulfillment

Willingness

Persistence

Confidence

Validity

Completeness

Uniqueness

Accuracy

Timeliness

Consistency









R E K

R E K

R E K

R E K









Service n

TrustIdM

TrustLinking


Interaction


Other Objects

Trust Agent

TrustData

Collection

TrustData

Filtering


Trust Attribute

Extraction


Statistical

Machine Learning

Numerical

Trust DAO Data

RepositoryTMEAPI

Trust Agent




Rule Policy

Ontology REK



AgentIPFS

DP

DS

Trust

Service i



DC








ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n



Distributed Banking

DEX










TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Data Trust

Privacy Trust

Trust

Entity Trust


SocialAttributes

Relationship

Temporal

Spatial

Competence

Disposition

Dependence

Fulfillment

Willingness

Persistence

Confidence

Validity

Completeness

Uniqueness

Accuracy

Timeliness

Consistency









R E K

R E K

R E K

R E K









Service n

TrustIdM

TrustLinking


Interaction


Other Objects

Trust Agent

TrustData

Collection

TrustData

Filtering


Trust Attribute

Extraction


Statistical

Machine Learning

Numerical

Trust DAO Data

RepositoryTMEAPI

Trust Agent




Rule Policy

Ontology REK



AgentIPFS

DP

DS

Trust

Service i



DC








ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n



Distributed Banking

DEX










TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Service n

TrustIdM

TrustLinking


Interaction


Other Objects

Trust Agent

TrustData

Collection

TrustData

Filtering


Trust Attribute

Extraction


Statistical

Machine Learning

Numerical

Trust DAO Data

RepositoryTMEAPI

Trust Agent




Rule Policy

Ontology REK



AgentIPFS

DP

DS

Trust

Service i



DC








ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n



Distributed Banking

DEX










TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



ROOF

FOG

Things

TC TC TC

TC TC TC TC

Localized Services

Area Level Services

City Level Services

CLOUD

Smart City Use Case

TC

Dire

ct C

omm

unic

atio

n



Distributed Banking

DEX










TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TCTB

TBPi

TBPj

TBPk







119870119894119895 (119905) = 120588119870119878119900119888119894119886119897119894119895 + 120590119870119863119890119901119890119899119889119886119887119897119890119894119895 (2)

119879119903119906119904119905119879119861 = 120572119864119879119861 + 120573119877119879119861 + 120574119870119879119861 (3)





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





Trust Assessment

TrustAssessment





Selection



Leader Selection













119878119894119892119899 (119872119890119904119904119886119892119890 119878119870) = 119878119894119892119899119886119905119906119903119890 (4)

119881119890119903119894119891119910 (119872119890119904119904119886119892119890 119878119894119892119899119886119905119906119903119890 119875119870) = 119879119903119906119890119865119886119897119904119890 (5)







119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia






119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887 (6)



119864119886119887 = 119879119867119886119887119864119887 = 119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

(7)


119905119909 (119895119905) =

1 119905 lt 120572119890minus119905 120572 lt 119905 lt 1205730 120573 lt 119905

(8)


119877119886119887 =119873=6

sum119899=1

119879119899119899119887d (n) 119877119887

=119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(9)


119889 (119899) = 7 minus 1198996 (10)


119879119903119906119904119905119886119887 = 120572119864119886119887 + 120573119877119886119887

= 120572119879119867119886119887sum119898119895=1 V119887 (119895) 119886119887 (119895) 119905119887 (119895119905)sum119898119895=1 119886119887 (119895) 119905119887 (119895119905)

+ 120573119873=6

sum119899=1

119879119899119899119887d (n) sum119898119895=1 V119899 (119895) 119886119899 (119895) 119905119899 (119895119905)sum119898119895=1 119886119899 (119895) 119905119899 (119895119905)

(11)


IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



IoT Node

a

IoT Node

b

IoT Node

c

IoT Node

d

IoT Node

e

IoT Node

p

IoT Node

q

IoT Node

r

Eab

Rb

Rb

Rb






1199051015840 = 1198921199031198961198621 + 1198961199032119904119862119896= 119892(V119909ndash119862119909) (119892119909)119862 + (119892119910)(V119909ndash119862119909) (119892119909119910)119862

= 119892(V119909) + 119892(V119909119910) = 119896V1 + 119904V119896 = 119905

(12)



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



StoreHash(Data)


IoT Node


Transactions Ledger


Ledger

Data Ledger


Update


EvaluateTrust


1

23

1

3

44








C +(k2)r (sk)





4 Discussion











5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia









5 Conclusions









replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia








replicasNearly

Immutable




Right to








Data Availability




Acknowledgments



References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


Documents

TrustChain: A Privacy Preserving Blockchain with Edge Computingdownloads.hindawi.com/journals/wcmc/2019/2014697.pdf · 2019. 7. 30. · blockchain technologies and trust evaluation