Personal and Ubiquitous Computinghttps://doi.org/10.1007/s00779-020-01417-z

ORIGINAL ARTICLE

A secure and extensible blockchain-based data provenanceframework for the Internet of Things

Marten Sigwart1 ·Michael Borkowski2 ·Marco Peise3 · Stefan Schulte1 · Stefan Tai3

Received: 4 November 2019 / Accepted: 18 May 2020© The Author(s) 2020

AbstractAs data collected and provided by Internet of Things (IoT) devices power an ever-growing number of applications andservices, it is crucial that this data can be trusted. Data provenance solutions combined with blockchain technology are oneway to make data more trustworthy by providing tamper-proof information about the origin and history of data records.However, current blockchain-based solutions for data provenance fail to take the heterogeneous nature of IoT applicationsand their data into account. In this work, we identify functional and non-functional requirements for a secure and extensibleIoT data provenance framework, and conceptualise the framework as a layered architecture. Evaluating the framework usinga proof-of-concept implementation based on Ethereum smart contracts, we conclude that our framework can be used torealise data provenance concepts for a wide range of IoT use cases. While blockchain technology generally poses constraintson scalability and privacy, we discuss multiple solutions aiming to overcome these issues.

Keywords Internet of things · IoT · Data provenance · Blockchains · Smart contracts

1 Introduction

The Internet of Things (IoT) is transforming many areas ofour everyday lives. IoT technologies such as GPS, RFID-based identification, sensors, and low-resource computingplatforms like the Raspberry Pi already play important rolesin various domains, e.g. mobility, logistics, healthcare, andretail [1]. Since data collected by these technologies find

� Marten Sigwartm.sigwart@dsg.tuwien.ac.at

Michael Borkowskimichael.borkowski@dlr.de

Marco Peisemp@ise.tu-berlin.de

Stefan Schultes.schulte@dsg.tuwien.ac.at

Stefan Taist@ise.tu-berlin.de

1 TU Wien, Vienna, Austria

2 Institute of Flight Guidance, German Aerospace Center(DLR), Braunschweig, Germany

3 TU Berlin, Berlin, Germany

application in an increasing number of use cases, ensuringthe trustworthiness of such data is of high importance [2].

Data provenance systems are one way to ensure trustwor-thiness in the IoT [3]. These systems can provide informa-tion about the origin and evolution of data such as the vari-ous stages of data creation and data modifications, who ini-tiated them, and when and how they took place [4]. In short,a data provenance system tracks who has created, updated,deleted, and in some cases read particular data points [4].In order to trust the information provided by a provenancesystem, it is essential that the provenance system storesinformation in a tamper-proof and replicable way [5].

Traditionally, in distributed settings, participants musteither trust each other or an independent third party to storedata in a tamper-proof way. With the advent of blockchaintechnologies, the requirement of such trust in a centralauthority is eliminated. Instead, a decentralised networkcan be established, acting as a distributed, tamper-proofledger [6]. Thus, leveraging blockchain technology in a dataprovenance solution for the IoT is a promising choice [6].

Since the IoT is characterised by a multitude of use casesand potential application areas [1], an IoT data provenancesolution should account for this diversity [7]. However,approaches aiming at scenario-agnostic blockchain-baseddata provenance solutions for the IoT offer so far noconcrete software solutions [8, 9], while more concrete

Pers Ubiquit Comput

solutions to data provenance in the IoT focus on specificapplication areas, for instance, supply chains [10–12],health monitoring systems [13], or digital forensics [14].

Hence, we propose a generic blockchain-based dataprovenance framework for the IoT. Hereby, “generic” refersto the fact that the framework should not be limited tobe applicable within one particular use case scenario, butrather should facilitate the recording of provenance datain a tamper-proof way in arbitrary IoT scenarios. Theadvantages of a generic framework are the easier adoptionand faster implementation of provenance concepts by newuse cases as well as the interoperability of applications thatuse the framework.

This paper extends our previous work [15] (i) byproviding an additional motivational use case scenariofrom digital forensics, (ii) by extending the evaluation bytaking the additional use case into account as well asby conducting a more rigorous evaluation of transactionthroughput and latency of the solution, and (iii) by providinga discussion about possible solutions to the scalability andprivacy constraints of a blockchain-based data provenancesolution. Furthermore, the related work has been updatedand extended. The contributions of this work are as follows:

– We define functional and non-functional requirementsfor a generic IoT data provenance framework.

– We conceptualise and implement an IoT data prove-nance framework consisting of smart contracts using ageneric data model to provide provenance functionalityfor a wide range of IoT use cases.

– We present an evaluation of the framework with regardto the defined requirements using a proof-of-conceptimplementation with Ethereum smart contracts.

– We discuss possible solutions to the scalability andprivacy limitations of blockchain-based applications forthe IoT.

In the following, we briefly introduce the underlying con-cepts of data provenance and further motivate our work bydiscussing exemplary use case scenarios (Section 2), definethe requirements for a generic blockchain-based data prove-nance framework (Section 3), and explain the concepts,architecture, and proof-of-concept implementation of oursolution (Section 4). In Section 5, we evaluate the frame-work with regard to the defined requirements. The resultsof the evaluation are discussed in Section 6. Section 7 pro-vides an overview of the related work. Finally, Section 8concludes the paper.

2 Background andmotivation

Data provenance, sometimes also known as lineage orpedigree [16], identifies the derivation history of data [4].

While originally used for works of art, data provenanceis now relevant in a wide range of use cases, since dataprovenance mechanisms help establish a certain level oftrust in data by providing information about its creation,access, and transfer [4]. Provided provenance data issecured, forgery, alteration, or repudiation of data can beprevented [5].

Accordingly, data provenance solutions can help estab-lish trust in data in the IoT [2]. In the following, we describethree exemplary use cases for data provenance in the IoT.

2.1 Vaccine supply chains

Immunisation programmes depend on functional, end-to-end supply chains [17]. In all phases of the supplychain—from procurement to last-mile distribution—it is ofsignificant importance that vaccines remain in a temperaturerange of around 2–8 ◦C. Otherwise, vaccines lose theireffectiveness. An unbroken, temperature-controlled linkfrom producer to consumer is also referred to as the coldchain [17]. Figure 1 shows a simplified model of sucha cold chain enhanced with IoT-technologies, e.g., RFID,GPS, and sensors [1]. These technologies continuouslytrack temperature, location, and other conditions of thevaccines. This provenance data helps establish confidencein the quality of vaccines and exposes any weak linksalong the cold chain. As mentioned in Section 1, animportant requirement for provenance systems is thatrecorded provenance information is replicable and tamper-proof. Recent scandals of vaccine counterfeiting (e.g.,[18]) have confirmed the urgency of these requirementsin vaccine supply chain systems. Hence, an IoT-powereddata provenance system based on blockchain technologycould provide benefits in vaccine supply chain scenarios.In particular, it enables the backtracking of errors in caseof breakage of the cold chain, and it helps build and keeptrust in immunisation programmes by preventing counterfeitvaccines from entering the supply chain.

2.2 Healthmonitoring systems

Health monitoring scenarios are another application areawhere secure data provenance records can provide addi-tional trust in data [13]. In such scenarios, sensors monitorhealth conditions of patients such as the patient’s heart rateand blood pressure. Combined with a real-time analyticsservice, the sensor readings can be used to notify relativesand health professionals in case of medical emergencies,such as a heart attack. Ideally, the root cause of such anotification is verifiable, i.e. it is possible to trace back anotification to the individual sensor readings which causedit. Otherwise, if the circumstances that led to the emergencynotification are unclear, the possibility that the notification

Pers Ubiquit Comput

Sourcing/vaccine

manufacturer

Primaryvaccine store:

cold room

Procurement

Intermediatevaccine store:cold rooms/refrigerator

Health post:cold boxes/

vaccinecarriers

Administrationto

beneficiaries

Pre-positioning Transportation in country Last mile distribution

Fig. 1 IoT-enhanced vaccine supply chain

was caused by a malicious attack tampering with the sys-tem cannot be excluded. Having secure provenance data fora notification, such as information about the individual sen-sor readings and analytics involved, ensures the reliabilityand accuracy of the system.

2.3 Digital forensics

A further use case where data provenance records securedvia blockchain technology can provide benefits is digitalforensics, for instance in scenarios involving accidentsof autonomous vehicles [14]. Ideally, in such cases,provenance data is available that uncovers the true causeof the accident. At the same time, it should be impossiblefor anyone to illegally alter the provenance data afteran accident occurred. Consider the example in Fig. 2.The provenance data may consist of data provided bythe manufacturer from when the car was manufactured,maintenance data provided by garages and workshops, anddata collected while driving by various sensors within andaround the car such as speed, road conditions, and outsidetemperature. This data is submitted via transactions tothe provenance framework on the blockchain. When anaccident occurs, the car owner submits a liability claim tothe insurance company. The insurance company can query

the provenance framework and depending on the evidenceforward the liability claim to manufacturers or garages. Theblockchain ensures the integrity of the data and that thesource of the data can be trusted. As such, it can helpinvestigators resolve any disputes of liability claims.

3 Requirements

This section defines the functional and non-functionalrequirements of a generic data provenance framework forthe IoT. Such a framework needs to record provenancedata for addressable data points, i.e. data that has aunique ID [7]. In accordance with [4] and [7], wederive the functional requirements (Reqs. (1)–(7)) ofour framework. Furthermore, in accordance with Hasanet al. [5], we define non-functional requirements that needto be fulfilled by a tamper-proof data provenance system forthe IoT (Reqs. (8)–(11)).

1. Provenance abstraction: The framework needs toprovide generic data provenance capturing, storing,and querying functionality which can be adoptedby provenance use cases to map their specificrequirements.

Fig. 2 An IoT data provenanceframework secured viablockchain technology couldresolve disputes of liabilityclaims

Blockchain-basedData Provenance

Vehicle ownerVehicle

Garage

Manufacturer Insurancecompany

Query provenance

Maintenancedata Submit liability claim

Manufacturingdata

Drivingdata

Forward liability claims

Transaction

Query

Off-chain operation

Pers Ubiquit Comput

2. High-level and low-level provenance: Provenancerecords represent high-level as well as low-level datapoints. Low-level data points stem from low-leveldevices such as sensors. High-level data points donot have a single physical origin (such as a sensorreading) but represent more abstract concepts, e.g.some physical object in a supply chain or an analyticsresult based on multiple inputs.

3. Completeness: The provenance records of a datapoint can be regarded complete if every relevantaction which has ever been performed on a data pointis gathered [5]. Here, relevance implies that someactions can be neglected if they do not contribute tothe provenance data of a particular data point.

4. Creation of lineage: Provenance records for a datapoint can be created based on the last provenancerecord for that same data point. This enables thecreation of lineage. For instance, the lineage of adata point representing a physical good travellingalong a supply chain can be tracked by creating anew provenance record based on the old one at eachcritical step of the supply chain.

5. Derivation: A provenance record entails referencesto the provenance records of the data points thatled to its creation. For instance, a provenance recordfor an analytics result based on value readings frommultiple sensors must not only contain informationabout the sensor values but must also be able toaccess provenance data of those same values, such aslocation and time of recording.

6. Provenance for modifications of data points: Theframework enables the tracking of the modificationhistory of a specific data point. For instance, if ananalytics result runs through multiple stages of differ-ent calculations, the history of these calculations canbe tracked.

7. Parallel provenance: Multiple provenance recordsfor the same data point can exist in parallel, e.g.one provenance trace might track the ownership ofa data point (e.g. the current owner of a physicalgood), while another provenance record is trackingthe location of that same data point.

8. Integrity: Integrity mandates that provenance recordscannot be manipulated or modified by an adversaryin any way. This is crucial for establishing trust inthe data. Without guaranteed integrity, clients canpotentially repudiate provenance records.

9. Availability and fault tolerance: The provenanceframework needs to enable clients to reliablyreconstruct the creation and modification history ofdata. For that, the provenance data needs to beavailable when requested by clients even in the casethat some parts of the system fail.

10. Privacy: In general, privacy requires that the unau-thorised collection, storage, and access of sensitivedata is prevented. Privacy encompasses confidential-ity and anonymity. On the one hand, provenancerecords of IoT devices may contain sensitive data,e.g. in a health monitoring system. It is thereforevital to keep this data confidential, i.e. access to thisdata from unauthorised entities needs to be prevented.On the other hand, even when the data itself is keptconfidential, malicious actors might still be able tocreate user profiles by identifying user-specific pat-terns. As such, traceability of provenance data needsto be prevented to ensure the anonymity of users.In the following, we refer to both notions simply asprivacy.

11. Scalability: A provenance system is required tohave a reasonable expenditure. Storing and accessingprovenance data must have a low overhead. Espe-cially, even though some IoT devices are resource-constrained, they must not be excluded from partic-ipating in the provenance framework. Furthermore,applications in the IoT potentially deal with massiveamounts of data and very frequent data updates whicha provenance solution needs to account for.

4 IoT data provenance framework

This section presents the proposed generic blockchain-based data provenance framework for the IoT. As mentionedin Section 1, major benefits of a generic framework areinteroperability between applications using the frameworkand the facilitated implementation of provenance conceptsfor new IoT use cases. Figure 3 displays the corearchitecture of the framework. It consists of three layersall embedded within a blockchain smart contract platform.Each layer represents a different level of abstraction witha diverse set of responsibilities within the framework:The storage layer is primarily concerned with low-level representation and storage of provenance data, andthe generic provenance layer provides general-purposeprovenance functionality, while the specific provenancelayer can be modified by use cases to fine-tune theframework to their specific requirements. To this end,Section 4.1 describes the data model used for therepresentation of provenance data within the framework,and Section 4.2 explains the storage layer, whereasSection 4.3 and Section 4.4 describe the generic and specificprovenance layers, respectively.

We provide a proof-of-concept implementation ofthe framework consisting of smart contracts written inSolidity—a smart contract language for the EthereumVirtual Machine (EVM). As such, the prototype can

Pers Ubiquit Comput

Fig. 3 Data provenanceframework architecture

Smart Contract Platform

Provenance Storage Layer

Generic Provenance Layer

Specific Provenance Layer

Supply ChainProvenance

Health MonitoringProvenance

...Digital Forensics

Provenance

be deployed on any EVM-compatible blockchain, e.g.public permissionless blockchains such as Ethereum andEthereum Classic, or private permissioned blockchains suchas Hyperledger Burrow [19]. However, the framework isnot restricted to EVM-based blockchains. The describedconcepts could also be implemented on any blockchainplatform that provides sufficient scripting capabilities. Theprototype is available as open-source software on Github.1

4.1 Datamodel

Provenance data varies depending on the specific domainor application [7]. Since the IoT domain is characterisedby heterogeneous applications and a wide range of possibleuse cases [1], there is a need for a generalised provenancedata model suitable for IoT applications. As the underlyingdata model, our framework utilises a data provenancemodel specifically designed for the IoT by Olufowobiet al. [7]. Instead of taking a document-centric view onprovenance data such as models like the Open ProvenanceModel (OPM) [20] or the PROV data model [21] whichtrack agents performing actions on documents, the model byOlufowobi et al. focuses on the infrastructure of agents likesensors, devices, analytics services, and the exchanged data.The authors argue that in IoT environments provenance canbe recorded in terms of creations or modifications of databy agents. No distinction between agents and actions isnecessary since a fine-grained definition of agents alreadyexplains the action performed on the data. The model cantherefore account for fine-grained provenance data whilekeeping a low overhead.

The model defines a data point as a uniquely identifiableand addressable piece of data. In the context of IoT systems,these can be sensor readings, complex analytics resultsderived from sensor readings, actuator commands, etc. Thefunction addr(dp) denotes the address/ID of a data point dp.The function inputs(dp) refers to the set of input data points

1https://github.com/msigwart/iotprovenance

that have contributed to the creation or modification of adata point.

The model defines a provenance event as the momentan IoT system reaches a specific state which requires thecollection of provenance data for a particular data point.When a provenance event occurs, information of interestfor provenance about the state of the IoT system needto be recorded. The function context(dp) denotes suchinformation. The context varies depending on the IoTapplication. An example of how the context parametermight be structured is displayed in Fig. 4. Agents (e.g.sensors, devices, persons, organisations, etc.) create and/ormodify data points. Here, agents are defined recursively,i.e. agents can contain other agents (such as devicescontaining several sensors). Information related to thespecific provenance event, such as events that triggeredthe creation/modification of the data point are definedin the execution context. Furthermore, time and locationinformation may be added to the context as well.

Finally, the model defines a provenance record as atuple associating the address of a data point with the setof provenance records of its input data points and thespecific context of the corresponding provenance event. Theprovenance function prov(dp), providing the provenancerecord for some data point dp, is defined as follows:

prov : dp �→ 〈addr (dp), {prov (idp)| ∀idp ∈ inputs (dp)}, context (dp)〉

Note that this definition of provenance allows for thedescription of both creation and modification of data points.In the former case, the set of input provenance recordscontains an empty set. In the latter case, the set ofinput provenance records contains the provenance recordof the data point before modification, i.e. prov(dp′) =〈addr(dp′), {prov(dp), ...}, context(dp′)〉.

The described data provenance model combined withblockchain technology builds the basis for our IoT dataprovenance framework. This way, the framework can notonly represent provenance data for various IoT use cases,but also provides integrity guarantees for the stored records.

Pers Ubiquit Comput

Fig. 4 UML diagram of anexemplary provenance record’scontext [7]

Context

Agent ExecutionContext

TimeInfo

LocationInfo

Sensor Device SoftwareAgent Actuator ...

**

has

4.2 Storage layer

This layer is responsible for the low-level storage ofprovenance records. It contains the generic representationfor provenance records as defined by the data provenancemodel, as well as basic functionality to create, retrieve,update, and delete provenance records. Delete refers tothe invalidation of provenance records, since truly deletingdata from a blockchain is not possible. An invalidatedprovenance record cannot be used as input for subsequentprovenance records.

Listing 1 displays an excerpt of the smart contractimplementing this layer. The internal representation ofprovenance records (Lines 2–7) closely resembles the modeldiscussed above with the field tokenId representing theID of a data point. However, not only are data pointsaddressable, but also the provenance records themselves.Addressable provenance records allow the storage layer tomanage provenance records as a mapping from provenanceIDs to provenance records: addr (prov) �→ prov wherethe function addr(prov) represents the ID of a provenancerecord prov. The mapping is implemented via the mappingkeyword (Line 8).

The contract exposes an API for creating, retriev-ing, updating, and deleting (i.e. invalidating) provenance

Listing 1 Storage contract (excerpt)

records. Note that, while functionality for retrieving prove-nance records is exposed publicly via the public key-word (Lines 10ff), functionality for creating, updating,and deleting records is protected via the internal keyword(Lines 13ff). These functions cannot be accessed publicly,but are accessible from inheriting contracts such as thecontract representing the generic provenance layer. Readfunctions are publicly accessible since these functions donot alter the state of the contract.

4.3 Generic provenance layer

The generic provenance layer’s main purpose is to providegeneral-purpose provenance functionality on top of thestorage layer; i.e. it provides features that are universallyapplicable for a wide range of provenance use cases. Forthis, it defines the ownership of data points (Section 4.3.1)and how to associate provenance records with data points(Section 4.3.2).

4.3.1 Ownership of data points

While blockchain technology can guarantee the integrity ofdata provenance records once those records have enteredthe system, mechanisms need to be in place to ensure thatthe records that enter the system are correct. As a first step,we aim to prevent the creation of provenance records byarbitrary clients, i.e. if client A generates some data pointdp0, we want to make sure that only client A (or any clientauthorised by client A) is able to create provenance recordsfor dp0. Thus, we introduce the notion of ownership ofdata points: Each data point belongs to a specific clientof the system, and only the owner or a client authorisedby the owner can create provenance records for it. If anunauthorised client tries to create a provenance record for adata point, the system raises an error.

The notion of ownership is closely related to so-calledtokens, i.e. smart contracts deployed on a blockchain thatrepresent a kind of digital asset [22]. Our frameworkleverages tokens to introduce ownership of data points. Eachdata point is represented by a single token and a single token

Pers Ubiquit Comput

identifies exactly one data point. This one-to-one mappingallows us to identify the owner of a data point by identifyingthe owner of a particular token.

Each token acts as an entry ticket to the provenanceframework. To create provenance records for a particulardata point, a client first has to become the token owneror be approved by the owner of the corresponding token.The prototype uses the Ethereum token standard ERC7212

which defines a common interface for non-fungible assets,for instance functions for transferring ownership. This hasthe advantage that our tokens (i.e. the data points) canbe traded by any client implementing this standard, suchas wallets or exchanges. By transferring ownership, datapoints can pass from owner to owner, leaving a trail ofprovenance records created by each owner along the way.This is useful for implementing provenance applicationswhich aim at creating a lineage (see Section 3), e.g. insupply chain scenarios and business processes [23, 24].The generic provenance contract complies to the standardby inheriting from an existing ERC721 implementationprovided by OpenZeppelin.3

4.3.2 Associating provenance records with data points

The generic provenance layer further links data pointsand their respective provenance records. The frameworkprovides information about associated provenance recordsof specific data points. Within the generic provenance layer,this is achieved by using a mapping from a data point ID toa set of associated provenance IDs:

addr (dp) �→ {addr (prov1 (dp)), addr (prov2 (dp)), ...}

All associated provenance records (prov1, prov2, etc.)represent parallel provenance traces for the same datapoint. Of those records, each one represents a completelyindependent trace of provenance data. For instance, onetrace of provenance records might store the temperaturehistory of a physical good, while another one stores itslocation.

Listing 2 displays an excerpt of the smart contract imple-menting this layer and demonstrates the general workflowfor creating new provenance records. First, the contract ver-ifies that a given token (i.e. data point) exists (Line 7)and that the token belongs to the sender of the mes-sage (Line 8). After validating the input provenancerecords (Line 9), the contract creates a new provenance

2https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md3https://openzeppelin.org/

Listing 2 Generic provenance contract (excerpt)

ID (Line 10), adds it to the list of associated prove-nance (Line 11), and calls the storage contract’s cre-ateProvenance function (Line 12). Note that the cre-ateProvenance function of the generic contract is againinternal, and thus not accessible publicly. This enables spe-cific provenance contracts which implement concrete usecases to further adapt the functionality according to theirneeds.4.4 Specific provenance layer

Smart contracts within this layer utilise the functionalityprovided by the generic provenance layer, but control asubset of parameters by themselves. This way, use cases cancustomise the provenance model according to their needs,and control access to the functionality provided by thestorage and generic provenance layers. Listing 3 displays anexcerpt of an exemplary smart contract implementing thislayer.

The provenance model can be customised by defining thecontext parameter, so that it presents the provenance dataneeded for a specific use case scenario. For instance, in thecase of vaccine supply chains, the context should containtemperature and location information about individualvaccines. Hence, a specific contract could define itsown createProvenance function that requires parameterslike temperature, and location (Lines 7ff) which are

Listing 3 Specific provenance contract (example)

Pers Ubiquit Comput

then combined to form the context to be passed on tothe createProvenance function of the generic provenancecontract (Lines 10ff).

Access control happens on two levels. First, a specificcontract defines which parts of the generic provenancelayer’s API are exposed. For instance, even thoughthe generic provenance layer could permit updating ordeleting (i.e. invalidating) provenance records, this could beunwanted behaviour in the specific use case at hand. In thiscase, the contract in the specific provenance layer simply“hides” the functionality, i.e. does not expose it publicly.

Second, access control is relevant for controlling theownership of data points. Since data point ownershipis the decisive factor with regard to who can createprovenance records for which particular data points,contracts in the specific provenance layer are responsiblefor actually assigning ownership, i.e. which tokens getassigned to which clients. For simplicity, the example shownin Listing 3 automatically assigns new tokens to requestingclients (Lines 2ff). However, ultimately, the most suitableapproach is dictated by the specific use case at hand.Some further possibilities for assigning ownership are listedbelow:

– One possibility is for clients to purchase tokens. Thishas the advantage that the framework is publiclyavailable without the risk of spamming attacks since theacquisition of tokens incurs financial cost. Essentially,the token acquisition cost needs to be low enoughfor honest users to be willing and able to participate,but high enough to discourage spammers. Of course,such an approach cannot prevent malicious actors withsufficient purchasing power.

– In another approach, the layer manages a white list ofauthorised clients allowed to request new tokens. Thisway, the list controls exactly who participates in theprovenance system. However, the question arises whois responsible for managing the white list of authorisedclients. As discussed above, the proposed frameworkcould also be implemented for private blockchains. Inthis case, the white list approach is surely the mostpromising one, since simply all participants in theprivate blockchain could be white-listed.

– Yet another approach is a list of pending requests.A client sends a transaction requesting tokens. Anadministrator gets notified about the new requestand decides whether to accept or deny the requestby assigning or not assigning corresponding tokens.While this approach allows a more fine-grained controlover whose requests get accepted and whose requestsget denied, it bears the risk of a high degree ofcentralisation due to the administrator having fullcontrol over distributing tokens.

5 Evaluation

We evaluate the framework with regard to the functional andnon-functional requirements defined in Section 3. The usecases defined in Section 2 act as basis for the evaluation ofReqs. (1)–(3). In addition, we reason about the fulfilment ofReqs. (4)–(7) in an exemplary fashion applying the use caseof vaccine supply chains. However, the scenario of vaccinesupply chains is merely used to provide a more descriptiveanalysis. The information specific to the vaccine supplychain can be substituted with data reflecting any otheruse case. While the presented framework is blockchain-agnostic, the non-functional requirements (Reqs. (8)–(11))are evaluated using the proof-of-concept implementation.Experiments were performed on the public Ethereum testnetworks Rinkeby4 and Ropsten5 between 27 Novemberand 13 December 2018. Rinkeby and Ropsten are chosenas test networks since their average block times mostclosely resemble the block times of the main Ethereumnetwork [25]. Rinkeby and Ropsten use the Proof ofAuthority (PoA) and Proof of Work (PoW) consensusmechanisms, respectively.

1. Provenance abstraction The presented frameworkconsists of multiple abstraction layers. The storagelayer is responsible for low-level storage of prove-nance records while the generic provenance layerextends the storage layer’s functionality with genericprovenance features and enhanced access control.The generic provenance layer can be extended byuse case-specific smart contracts controlling certainparameters of the application, e.g. by assigning own-ership of tokens, and/or by exposing or hiding partsof the generic layer’s API. For instance, in the sce-nario of vaccine supply chains, a specific provenancesmart contract might give an entity such as the WorldHealth Organisation complete control over who isable to acquire tokens, e.g. only trusted vaccine man-ufacturers. In the use case of health monitoring sys-tems, multiple approved manufacturers might havecontrol over assigning ownership of data point IDs.In the use case of digital forensics, each newly pur-chased vehicle might automatically get assigned anew token representing that vehicle. Besides creat-ing provenance records itself, the vehicle could givetemporary permission to garages or other entities tocreate provenance records on its behalf, e.g. to regis-ter the date and specifics of an inspection. Hence, weconclude that the framework acts as a base abstrac-tion which can be extended to fulfil the needs of

4https://rinkeby.etherscan.io/5https://ropsten.etherscan.io/

Pers Ubiquit Comput

specific provenance use cases. Thus, we regard Req.(1) as fulfilled.

2. High-level and low-level provenance The frameworkidentifies each data point by its corresponding token.As long as a unique token (i.e. ID) gets assignedto a data point, provenance data for that data pointcan be recorded. Hence, the framework does notpose any restrictions on the nature of the data point.It is possible to record provenance data for high-level as well as low-level data points. The contextparameter of a provenance record can be used toadd any kind of information the user desires. Inthe use case of vaccine supply chains, provenancedata could not only be collected for the vaccinesthemselves, but also for sensor readings alongthe supply chain, e.g. temperature readings whichdocument an uninterrupted cold chain. Within healthmonitoring systems, the patients themselves might berepresented by data points. The patients’ provenancetraces are then augmented by provenance data fromlow-level data points deriving from medical devices.Similarly, in the use case of autonomous vehicles, thevehicles themselves are represented by data pointsand their provenance records get augmented by datapoints deriving from low-level devices, such as aspeedometer or outside temperature sensors. Hence,we regard Req. (2) as fulfilled.

3. Completeness The definition of completeness islargely dependent on the specific provenance use caseat hand. In the example of vaccine supply chains, allinformation needed to prove that the cold chain hasnot been interrupted and that vaccines come from atrusted source need to be recorded. Regarding healthmonitoring systems, we need to be able to record allinformation necessary to provide reliable root causeinformation for medical emergencies. With regard toautonomous vehicles, the system needs to be ableto record all information necessary to resolve anydisputes between parties involved in an accident.The flexibility of the context parameter definedby the provenance model allows the collection ofall provenance data relevant for each data point.Therefore, as each individual provenance record canbe regarded as complete, the framework providesthe necessary foundation for complete provenancetracking (Req. (3)). However, to truly reconstruct thecreation and modification history of a data point, notonly must the individual provenance records of thedata point be complete, but also the complete trace ofprovenance records regarding the data point shouldbe available. Therefore, in error-prone environmentslike the IoT where frequent network or device errorsmay occur, individual use cases need to make sure

that sufficient amounts of provenance records reachthe provenance framework in order to enable trulycomplete provenance tracking.

4. Creation of lineage As an example, we assumethat the manufacturer SaferVaccines Inc. producesa new vaccine vacc1. The freshly produced vac-cine is packaged with an RFID tag and assignedwith a unique ID. A completely new prove-nance record for the vaccine is created, suchas prov(vacc1) = 〈addr(vacc1), ∅, 〈agent =operator1@Saf erV accinesInc, time =5am, ...〉〉. Vaccine vacc1 is loaded onto anaircraft air1. An RFID reader at the fac-tory gate scans the vaccine and registers anew provenance record of the vaccine leav-ing the factory, such as prov (vacc1)′ =〈addr(vacc1), {prov(vacc1)}, 〈agent =rf id1@Saf erV accinesInc, time = 5am, ...〉〉.Shortly after, an RFID reader at the aircraft’sentrance registers the vaccine entering the air-craft, e.g. prov(vacc1)

′′ = 〈addr(vacc1),

{prov(vacc1)′}, 〈agent = rf id1@air1, time =

5am, ...〉〉. The provenance records prov(vacc1),

prov(vacc1)′, andprov(vacc1)

′′ represent the lin-eage of the vaccine. This shows exemplarily how theframework fulfils Req. (4).

(5) Derivation Continuing the example from Req.(4), inside the aircraft, sensors constantly monitorthe temperature. There are three readings from atemperature sensor: dp1 = 38◦F, dp2 = 45◦F, dp3 =40◦F. The provenance records are given as follows:

prov(dp1) = 〈addr(dp1),∅, 〈agent =sensor, time = 7am, ...〉〉prov(dp2) = 〈addr(dp2),∅, 〈agent =sensor, time = 8am, ...〉〉prov(dp3) = 〈addr(dp3),∅, 〈agent =sensor, time = 9am, ...〉〉

A fourth data point dp4 is created by a softwareagent calculating the average temperature: i.e.dp4 = (dp1 + dp2 + dp3)/3 = 41◦F. This datapoint’s provenance record is defined as prov(dp4) =〈addr(dp4), {prov(dp1), prov(dp2), prov(dp3)},〈agent = averager@air1 t ime = 10am, ...〉〉.Hence, the framework allows for the creation ofprovenance records for data points deriving frommultiple other data points (Req. (5)).

6. Provenance for modifications of data points Ina further step, the calculated average temper-ature dp4 is converted into a different unit:dp′

4 = 5 ◦C (i.e. from Fahrenheit to Cel-sius). The resulting provenance record looks likeprov(dp′

4) = 〈addr(dp′4), {prov(dp4)}, 〈agent =

converter@air1, time = 11am, ...〉〉. Thus, the

Pers Ubiquit Comput

framework is also able to support the modification ofdata points (Req. (6)).

7. Parallel provenance Besides measuring the temper-ature inside the aircraft (air1), we might also wantto track the location of the aircraft at the sametime. The framework enables the creation of parallelprovenance records since each data point is mappedto a list of associated provenance records (seeSection 4.3). We can create one provenance recordprovtemperature(air1) representing the latest temper-ature inside the aircraft, and one provenance recordprovlocation(air1) representing the latest location ofthe aircraft. Hence, we regard (Req. (7)) as fulfilled.

8. Integrity The presented framework uses blockchaintechnology to provide trustless and tamper-proofstorage of provenance records for IoT data. Thus,once records have entered the system, the integrityof records depends on the underlying blockchaintechnology. Ethereum is a public blockchain witharound 7075 fully validating nodes securing thenetwork at the time of writing.6 Because of itsPoW consensus mechanism and the high number offully validating nodes, we consider the Ethereumnetwork as secure. Hence, we consider the integrityrequirement for data and computations on Ethereumas fulfilled. However, the framework also needsto provide mechanisms to ensure that only correctrecords enter the system in the first place. As afirst step, we implement the concept of ownershipof data points using tokens to prevent arbitraryclients from creating provenance records. In futurework, this concept could be further extended bymechanisms that guarantee the correctness of therecords themselves, e.g. via physical unclonablefunctions (PUFs) [2].

9. Availability and fault tolerance In public blockchainnetworks like Ethereum, potentially any client canrun a full node giving the client access to thecomplete state of the blockchain. Furthermore,blockchains are designed from the ground up to pro-vide Byzantine fault tolerance. That is, blockchainscontinue to operate even if some nodes fail or actmaliciously with imperfect information about thesefailures or bad actors. Hence, we consider (Req. (9))as fulfilled.

10. Privacy While the privacy requirements of a prove-nance system largely depend on the concrete usecase at hand, in scenarios with sensitive data, suchas a health monitoring system, privacy is cru-cial [13]. However, privacy remains an ongoing

622 October 2019 (https://ethernodes.org/)

challenge in the realm of (public) blockchains, since ablockchain’s security relies on data being transparentand verifiable by every participant. A blockchain-based data provenance framework suffers from thesame problem. While some propose to use privateblockchains in scenarios where privacy is impor-tant [13], this is not sufficient in scenarios which alsodepend on the system being publicly available, suchas global vaccine supply chains. Possible solutions toovercome the privacy limitations of blockchain-basedapplications in the context of the IoT are discussed inSection 6.

11. ScalabilityRegarding scalability, we evaluate two aspects.

First, we examine the gas consumption of the system.Second, we measure transaction throughput andlatency.

Gas consumption Creating a new provenance record shouldhave the same gas consumption whether there are thousandalready existing provenance records in the system orthere are none. Since our framework stores provenancerecords as a mapping addr(prov) �→ prov, we canaccess records directly via their ID. Hence, creating,updating, or accessing provenance records is a constant gasoperation. Furthermore, we analyse how the size of the inputparameters influences the gas consumption for creatingprovenance records. We examine the creation rather thanthe updating or deletion of provenance records since theseoperations are generally less expensive than the creationoperation. Evaluating the gas consumption for creation thusgives a good estimate on the upper limit of gas consumptionof the framework. Figures 5 and 6 show the gas consumptionwith regard to the size of the context parameter and thenumber of input provenance records, respectively. Whenincreasing the size of the context parameter, a stepwiseascent in gas consumption is visible in Fig. 5. As expected,passing a longer context string when creating a provenancerecord causes greater gas consumption, since more storage

Fig. 5 Gas consumption for provenance creation with respect to anincreasing context parameter

Pers Ubiquit Comput

Fig. 6 Gas consumption for provenance creation with respect to anincreasing number of input provenance records

is needed. Similarly, when increasing the number of inputprovenance records, gas consumption rises linearly as canbe seen in Fig. 6, though more rapidly in comparisonto increasing the context size. This rapid ascent in gasconsumption stems from the fact that users are only allowedto add input provenance records that are actually existentand valid. Thus, when creating new records, the frameworkchecks, for every input provenance record, if that recordexists and if it is valid. This check can only happen ina for-loop which is an expensive operation in Ethereum.Because of the increases in gas consumption caused bythese two input parameters, it makes sense for concreteprovenance use cases to implement limits regarding bothparameters.

Latency The latency of creating provenance records isevaluated by averaging 100 measurements of the timepassing between the moment a transaction is submitted tothe network and its execution and inclusion in a block. Ingeneral, two factors influence transaction latency, namelythe overall network load and the gas price. With a highernumber of pending transactions (i.e. a higher networkload), not every transaction can be included within the nextimmediate block which means higher priced transactionsget prioritised. We repeat the experiment with gas prices of1, 2, 5, 10, 20 and 50 GWei (1 GWei = 0.000000001 ETH) tosee how the gas price influences transaction latency. While

Fig. 7 Avg. latency for creating provenance records

performing the experiments, we observe the test networksto make sure that overall network load remains relativelystable.

Figure 7 shows the average latency and standarddeviation for creating provenance records. Latency on theRopsten test network is the highest (average transactionlatency between 15–36 s), followed by Rinkeby (14–35 s).The standard deviation for Ropsten is also quite high withvalues of about 11–29. On average, transactions with gasprices of only 1 Gwei take longer to be confirmed thantransactions with gas prices of 2 Gwei and beyond. As thegas price is increased, the average latency converges to theaverage block times of the respective networks, since higherpriced transactions are almost certainly included within thenext immediate block. This also explains the higher standarddeviations of Ropsten in comparison with Rinkeby. Rinkebyuses PoA, that means a new block gets consistently minedevery 14–15 s, resulting in lower standard deviations. InRopsten, on the other hand, blocks get mined if a nodecan solve the cryptographic puzzle of the PoW. Sincethis happens at different intervals, Ropsten exhibits higherstandard deviations.

Transaction throughput To test throughput, we attempt tosubmit up to 150 transactions to the test network duringa 60-s time frame. Afterwards, we divide the number ofconfirmed transactions with the time frame of 60 s tocalculate the transactions per second (TPS). This is repeated20 times to calculate the mean and standard deviation. Theexperiment is repeated with different gas prices (1, 2, 5, 10,20 Gwei) on the two different test networks.

The results of the experiment are displayed in Fig. 8.Generally, throughput for the Rinkeby test network is thegreatest with about 1.6 TPS for gas prices of 1 Gwei andbeyond. On Ropsten, we see a throughput of about 1–1.2 TPS for gas prices of 2 Gwei and beyond. We explainthe smaller average throughput of the Ropsten test networkby the total load of each network during the experimentswhich was generally higher on Ropsten than on Rinkeby.Note that throughput was measured from a user perspective,i.e. transactions were submitted from a single account. The

Fig. 8 Avg. throughput for creating provenance records

Pers Ubiquit Comput

maximum global throughput of the Ethereum blockchain isroughly 20 TPS.

To sum up, the framework is able to fulfil allfunctional requirements defined in Section 3. Additionally,by leveraging blockchain technology, the non-functionalrequirements of integrity and availability can be fulfilled.Regarding scalability and privacy, the use of blockchaintechnology poses limitations. While the system scaleswith regard to the number of already existent provenancerecords, the throughput and latency of the frameworkare constrained. Depending on the number of provenancerecords that need to be recorded in a given time frame,the limited throughput and latency can pose problems.For instance, while in the use case of vaccine supplychains sensor readings might only occur every so often,the use case of autonomous vehicles might require multiplesensor readings per second, leading to high throughputrequirements for the provenance system. Furthermore, theinherent transparency of blockchain technology naturallyposes a challenge for privacy-sensitive applications such asin health monitoring solutions.

6 Discussion

As we have demonstrated in Section 5, the presentedframework is able to satisfy Reqs. (1)–(7) by buildingon top of the generic data provenance model for the IoTand by providing abstraction layers which specific usecases can adopt and extend to fit their own requirementssuch as the assignment of ownership of data point IDs.Furthermore, the framework relies on blockchain tech-nology to provide guarantees of integrity and availabil-ity (Req. (8) and Req. (9)). However, the fundamentaldesign of what makes the blockchain secure causes itslimited scalability and privacy [6]. While in some cases,permissioned blockchains like Hyperledger Fabric7 can beemployed to provide better privacy and scalability [13],in global IoT scenarios entailing massive amounts of dataand frequent data updates where public access to thesystem is necessary, permissioned blockchains might notbe a viable option [26]. Hence, a solution is needed toimprove the privacy and scalability properties of permis-sionless blockchain systems while keeping its integrity andavailability guarantees. Several recent blockchain devel-opments try to tackle these limitations, e.g. state chan-nels [27], zero-knowledge proofs [28], and sidechains[29].

7https://www.hyperledger.org/projects/fabric

6.1 State channels

State channels increase scalability by off-chaining statetransitions [27]. Two participants open a state channelby locking some state on the blockchain (e.g. in asmart contract). Once locked, they perform transactionson that state off-chain. The only requirement is that bothparticipants sign off these transactions, using signaturesverifiable on-chain, and that the transactions are ordered.This allows both participants to finalise the state on theblockchain at any time since they can prove via thesignatures that the counterpart agreed to the update. Theguarantee of settling a transaction at any point is as good ashaving the transaction executed directly on the blockchain.This way, state channels reduce the cost of transactionssince only the finalisation step occurs on-chain. As onlythe final state update becomes visible in the blockchain,state channels can further be used to hide any intermediatetransactions from outsiders [27]. These characteristics makestate channels a viable choice for increasing scalability andimproving privacy in blockchain-based IoT applications,e.g. in scenarios with micro-transactions occurring betweendevices. Note that implementations of state channels rangefrom application-specific (i.e. payment channels [30]) togeneric [31] and from unidirectional to bidirectional. Inthis discussion, we consider generic, bidirectional statechannels.

6.2 Zero-knowledge proofs

Zero-knowledge proofs are an off-chaining pattern, wherea prover tries to convince a verifier about the correct exe-cution of a computation without revealing the parametersof the computation to the verifier [27]. The aim is for theverifier to be able to verify that the prover correctly exe-cuted the computation without the verifier knowing anyof the inputs required for the computation, thus havingzero knowledge. To take advantage of zero-knowledgeproofs in blockchains, zkSNARKs (zero-knowledge Suc-cinct Non-interactive ARguments of Knowledge) canbe employed [28]. This serves two purposes: resource-intensive computations can be performed and verified off-chain and the input of computations can be kept private.

However, proof construction in zkSNARKs is computa-tionally expensive, leading to high hardware requirementsfor the prover. This can be a problem in IoT scenarios ifthe prover is hardware-constrained. Also, off-chaining statetransitions is only beneficial when the verification of thecomputation is less expensive than the computation itself.Thus, while zkSNARKs can improve scalability and pri-vacy, it needs to be evaluated whether the initial overhead isjustifiable in IoT applications.

Pers Ubiquit Comput

6.3 Sidechains

The main idea of sidechains is to take load off of anexisting blockchain (i.e. the parent chain) by outsourcingsome of its data and computation to a separate blockchain(i.e. the sidechain) [29]. Sidechains are “pegged” to theparent chain, i.e. the state of the sidechain is securedvia regular commits to the parent chain. Such commitsentail the root hash of a Merkle tree consisting of alltransactions that have occurred on the sidechain. This way,all transactions of the sidechain are secured via a singlehash on the parent chain. This link enables participantsto retreat back to the secure and reliable parent chainvia so-called exits in case malicious behaviour is detectedon the sidechain [29], e.g. when sidechain validatorsmine invalid blocks or withhold blocks completely. Whilesidechains can potentially employ different, more efficientconsensus mechanisms than the parent chain, scalabilitygains primarily derive from participants of a sidechain nothaving to validate all global transactions of the parentchain anymore, but only the transactions occurring on thesidechain. Thus, a validator’s hardware requirements canremain low, while transaction throughput is increased astransactions and data of the parent chain are split intomultiple different sidechains. As such, sidechains improvethroughput rather than latency [32]. Furthermore, sidechainscould be kept secret to improve privacy.

The three approaches discussed above are promising withregard to improving scalability and privacy of blockchainapplications. In future work, it needs to be evaluated if andhow these solutions can be employed to provide scalabilityand privacy improvements in global IoT scenarios.

7 Related work

As mentioned in Section 1, there are existing studieswhich focus on providing a generic blockchain-baseddata provenance solutions for the IoT [8, 9]. Theframework presented by Baracaldo et al. addresses thefollowing requirements [9]: tamper prevention (i.e. ensuringintegrity of provenance data), high availability, fine-grainedaccess control, and enabling resource-constrained devicesto participate in the framework. However, an actualimplementation is not provided. Similarly, while Polyzoset al. mention key security requirements of their blockchain-assisted information distribution system for the IoT [8],the approach is described only on a conceptual level andno implementation is given. In contrast, the frameworkpresented in the work at hand has been fully implementedand is available as open-source software.

Further solutions related to blockchain-based dataprovenance in the realm of the IoT go beyond conceptual

approaches [10–14]. The approaches presented in [10–12]focus on securing provenance data in supply chains. Theframework proposed in [11] uses a tokenised recipe modelto track the relationship between resources and products,the authors of [10] propose a blockchain-based system totrack ownership of products in the post supply chain, andWu et al. [12] discuss an architecture of permissioned andpublic ledgers to comply with the privacy requirementsof trading partners. Griggs et al. present a blockchain-based patient monitoring system to provide notifications incase of medical emergencies [13]. The approach utilisessmart health devices and a private blockchain to providesecure analysis of sensor data. Cebe et al. present adigital forensics framework based on blockchain technologythat tracks information about vehicles, which, in case ofaccidents, can be used for resolving disputes betweendrivers, insurance companies, and maintenance serviceproviders [14]. In general, the solutions presented in [10–14] all demonstrate how provenance concepts can bebrought onto the blockchain (e.g., via smart contracts).However, in contrast to our work, though IoT technologiesare addressed, these solutions are use case–specific and donot provide a generic provenance framework as is requiredbecause of the heterogeneous nature of the IoT [1, 7].

Provenance in the supply chain has also receivedattention in the industry. Startups like Provenance8 andEverledger9 focus on securely tracking goods travelingalong a supply chain via blockchain technology. However,in contrast to our work, their sole focus lies on trackingphysical items instead of any kind of data within the IoT.

Furthermore, works have also focused on blockchain-based data provenance solutions outside the IoTdomain [33–36]. Liang et al. present Provchain [33], asystem that provides the ability to record and verify theoperation history of data on the cloud. Whenever an oper-ation (read/write) happens on a file in the cloud, the cloudservice provider stores a provenance record locally andanchors the hash of the record to a public blockchain. Thisway, a timestamp proof of that particular operation existswhich is verifiable in the future. The information saved onthe blockchain is used for the verification of a provenancerecord; however, it does not provide any provenance dataitself. While users can verify that certain operations on afile have occurred, they still depend on a central entity toprovide them with a complete set of provenance data fora particular file. Tosh et. al propose BlockCloud [34], adata provenance solution in the cloud based on a Proof ofStake (PoS) blockchain to overcome scalability limitationsof blockchains based on PoW. While the architecture of

8https://www.provenance.org/9https://www.everledger.io/

Pers Ubiquit Comput

BlockCloud is outlined, in contrast to our work, no concreteimplementation details are provided.

Secure provenance for scientific data is in the focusof [35]. Here, the authors present DataProv, a system whichsecurely captures scientific provenance data. DataProv usesthe OPM data model [20] for recording provenance data.The system provides an access control mechanism built onsmart contracts on the Ethereum blockchain platform tocontrol changes of documents in the cloud while takingthe actual verification process of document changes off thechain. This privacy-focused solution looks promising alsofor IoT-related domains. However, while using the OPMdata model is fine for scientific contexts, in IoT contexts,the utilization of a simpler, more fine-grained provenancemodel could be useful [7].

A completely different solution is offered by Ruanet al. [36]. Here, the authors provide LineageChain,a solution that captures fine-grained provenance forblockchains. Smart contracts that depend on some old stateof the blockchain for execution can query LineageChainfor historical state information in a tamper-evident way.However, LineageChain requires a modification of theunderlying blockchain protocol itself and thus cannot beleveraged on existing blockchain platforms.

As can be seen by the discussion, to the best of ourknowledge, there is no other approach which providesa generic, blockchain-based framework for tracking dataprovenance in the IoT.

8 Conclusion

In this paper, we have presented a blockchain-based frame-work for providing generic data provenance functionalityin the IoT. The framework enables the adoption and imple-mentation of data provenance concepts for various IoT usecases. In a first step, we have identified several functionaland non-functional requirements which need to be fulfilledfor creating a secure data provenance solution appropri-ate for the heterogeneous nature of the IoT. Afterwards,we have demonstrated how a generic IoT data prove-nance model together with a layered architecture of smartcontracts can be utilised to satisfy the functional require-ments. Furthermore, by leveraging blockchain technology,the framework fulfils the non-functional requirements ofintegrity and availability but has some limitations regard-ing scalability and privacy. As we have seen in the dis-cussion, multiple current blockchain developments seekto overcome these issues without jeopardising blockchainsecurity, namely state channels, zero-knowledge proofs,and sidechains. Thus, in our future work, we will evaluatein detail to what extent these approaches provide solu-tions to the privacy and scalability issues in the context

of blockchain-enhanced IoT applications, such as our dataprovenance framework.

Funding Information Open access funding provided by TU Wien(TUW).

Compliance with ethical standards

Conflict of interest The authors declare that they have no conflict ofinterest.

Open Access This article is licensed under a Creative CommonsAttribution 4.0 International License, which permits use, sharing,adaptation, distribution and reproduction in any medium or format, aslong as you give appropriate credit to the original author(s) and thesource, provide a link to the Creative Commons licence, and indicateif changes were made. The images or other third party material inthis article are included in the article’s Creative Commons licence,unless indicated otherwise in a credit line to the material. If materialis not included in the article’s Creative Commons licence and yourintended use is not permitted by statutory regulation or exceedsthe permitted use, you will need to obtain permission directly fromthe copyright holder. To view a copy of this licence, visit http://creativecommonshorg/licenses/by/4.0/.

References

1. Li S., Da Xu L., Zhao S. (2015) The internet of things: a survey.In: Information systems frontiers, vol 17.2, pp 243–259

2. Aman M. N., Chua K. C., Sikdar B. (2017) Secure DataProvenance for the Internet of Things. In: 3rd ACM internationalworkshop on IoT privacy, trust, and security. ACM, pp 11–14

3. Bertino E. (2014) Data trustworthiness–approaches and researchchallenges. In: Data privacy management, autonomous sponta-neous security, and security assurance. Springer, pp 17–25

4. Freire J., et al. (2008) Provenance for computational tasks: asurvey. In: Computing in science & engineering, vol 10.3, pp 11–21

5. Hasan R., Sion R., Winslett M. (2009) Preventing history forgerywith secure provenance. In: ACM transactions on storage, vol 5.4.Article no. 12

6. Christidis K., Devetsikiotis M. (2016) Blockchains and smartcontracts for the internet of things. In: IEEE Access, vol 4,pp 2292–2303

7. Olufowobi H, et al. (2017) Data provenance model for Internetof Things (IoT) systems. In: Service-oriented computing-ICSOC2016 workshops: revised selected papers. Springer, Berlin, pp 85–91

8. Polyzos G. C., Fotiou N. (2017) Blockchain-assisted informationdistribution for the Internet of Things. In: 2017 IEEE internationalconference on information reuse and integration. IEEE, pp 75–78

9. Baracaldo N, et al. (2017) Securing data provenance in Internetof Things (IoT) systems. In: Service-oriented computing-ICSOC2016 workshops: revised selected papers. Springer, Berlin, pp 92–98

10. Toyoda K., et al. (2017) A novel blockchain-based productownership management system (POMS) for anti-counterfeits inthe post supply chain, vol 5, pp 17465–17477

11. Westerkamp M., Victor F., Kupper A. (2018) Blockchain-basedsupply chain traceability: token recipes model manufacturingprocesses. IEEE, pp 1595–1602

Pers Ubiquit Comput

12. Wu H., et al. (2017) A distributed ledger for supply chainphysical distribution visibility. In: Information, vol 8.4, pp 137:1–137:18

13. Griggs K. N., et al. (2018) Healthcare blockchain system usingsmart contracts for secure automated remote patient monitoring.In: Journal of medical systems, vol 42.7, pp 130:1–130:7

14. Cebe M., et al. (2018) Block4forensic: an integrated lightweightblockchain framework for forensics applications of connectedvehicles. In: IEEE communications magazine, vol 56.10,pp 50–57

15. Sigwart M., et al. (2019) Blockchain-based data provenance forthe Internet of Things. In: 9th international conference on theinternet of Things (IoT 2019). ACM, pp 15:1–15:8

16. Simmhan YL, Plale B, Gannon D (2005) A survey of dataprovenance tech- niques. Tech. rep. IUB-CS-TR618. ComputerScience Department, Indiana University, Bloomington, Indiana,USA

17. Comes T, Bergtora Sandvik K, Van de Walle B (2018) Coldchains, interrupted: the use of technology and information fordecisions that keep humanitarian vaccines cool, vol 8.1, pp 49–69

18. Megget K Massive fake vaccine racket busted in Indonesiahttps://www.securingindustry.com/pharmaceuticals/massive-fake-vaccine-racket-bustedin-indonesia/s40/a2849/#.WrylEtNuaL4.Accessed 30 March 2018

19. Cooper K (2020) Hyperledger Burrow. https://wiki.hyperledger.org/display/burrow/Burrow+-+The+Boring+Blockchain

20. Moreau L., et al. (2011) The open provenance model corespecification (v1.1). In: Future generation computer systems,vol 27.6, pp 743–756

21. Moreau L., et al. (2013) PROV-DM: the PROV data model. https://www.w3.org/TR/prov-dm/. Accessed 9 Jul 2018

22. Cryptographic Tokens. https://blockchainhub.net/tokens/.Accessed 29 May 2019. (2019)

23. Prybila C., et al. (2020) Runtime verification for businessprocesses utilizing the bitcoin blockchain. In: Future generationcomputer systems, vol 107, pp 816–831

24. Mendling J., Weber I., Aalst W. V. D., Brocke J. V., Cabanillas C.,Daniel F., Debois S., Ciccio C. D., Dumas M., Dustdar S., et al.(2018) Blockchains for business process management–challengesand opportunities. In: ACM Transactions on ManagementInformation Systems (TMIS), 9(1), pp 1–16. ACMNewYork, NY,USA

25. Ethereum StackExchange (2018) Comparison of the dif-ferent TestNets. https://ethereum.stackexchange.com/questions/27048/comparison-of-the-different-testnets

26. Fernandez-Carames T. M., Fraga-Lamas P. (2018) A review onthe use of blockchain for the Internet of Things. In: IEEE Access,vol 6, pp 32979–33001

27. Eberhardt J., Tai S. (2017) On or off the Blockchain? Insights onoff-chaining computation and data. In: 2017 European conferenceon service-oriented and cloud computing. Springer, pp 3–15

28. Eberhardt J, Tai S (2018) ZoKrates – scalable privacy-preservingoff-chain computations. In: IEEE international conference onblockchain. IEEE, pp 1084–1091

29. Back A et al (2014) Enabling blockchain innovations with peggedsidechains. https://blockstream.com/sidechains.pdf. Accessed 10April 2019

30. Lightning Network. https://lightning.network/. Accessed 30 Oct2019

31. Dziembowski S, Faust S, Hostakova K (2018) General statechannel networks. In: 2018 ACM SIGSAC conference oncomputer and communications security. ACM, pp 949–966

32. Konstantopoulos G (2018) Plasma cash: towards more efficientplasma constructions. https://github.com/loomnetwork/plasma-paper/blob/master/plasmacash.pdf. Accessed 6 Sept 2018

33. Liang X, et al. (2017) Provchain: a blockchain-based dataprovenance architecture in cloud environment with enhancedprivacy and availability. In: 17th IEEE/ACM internationalsymposium on cluster, cloud and grid computing. IEEE, pp 468–477

34. Tosh D, et al. (2019) Data provenance in the cloud: a blockchain-based approach. In: IEEE consumer electronics magazine, vol 8.4,pp 38–44

35. Ramachandran A, Kantarcioglu M (2018) SmartProvenance: adistributed, blockchain based dataprovenance system. In: 8thACM conference on data and application security and privacy.ACM, pp 35–42

36. Ruan P, et al. (2019) Fine-grained, secure and efficient dataprovenance on blockchain systems. In: Proceedings of the VLDBendowment, vol 12.9, pp 975–988

Publisher’s note Springer Nature remains neutral with regard tojurisdictional claims in published maps and institutional affiliations.