text:
\section{Background \& Motivation}
\label{sec:background}

Data provenance, sometimes also known as lineage or pedigree~\cite{simmhan2005survey}, identifies the derivation history of data~\cite{freire2008provenance}. While originally used for works of art, data provenance is now relevant in a wide range of use cases, since data provenance mechanisms help to establish a certain level of trust in data by providing information about its creation, access, and transfer~\cite{freire2008provenance}. Provided provenance data is secured, forgery, alteration or repudiation of data can be prevented~\cite{hasan2009preventing}. Accordingly, data provenance solutions can help to establish trust in data in the IoT~\cite{aman2017secure}. In the following, we describe two exemplary use cases for data provenance in the IoT.

\paragraph{Vaccine Supply Chains}
\label{sec:usecase1}
Immunisation programmes depend on functional, end-to-end supply chains~\cite{comes2018cold}. In all phases of the supply chain---from procurement to last-mile distribution---it is of significant importance that vaccines remain in a temperature range of \mbox{around 2--8 °C}. Otherwise, vaccines lose their effectiveness. An unbroken, temperature-controlled link from producer to consumer is also referred to as the cold chain~\cite{comes2018cold}. In IoT-enabled cold chains, technologies such as RFID, GPS and sensing technologies~\cite{li2015internet} track temperatures, locations and other conditions of the vaccines. This provenance data helps to establish confidence in the quality of vaccines and exposes any weak links along the supply chain. As mentioned in \cref{sec:intro}, an important requirement for provenance systems is that recorded provenance information is replicable and tamper-proof. Recent scandals\footnote{\url{https://www.securingindustry.com/pharmaceuticals/massive-fake-vaccine-racket-busted-in-indonesia/s40/a2849/\#.WrylEtNuaL4}} of vaccine counterfeiting have confirmed the urgency of these requirements in vaccine supply chain systems. Hence, an IoT-powered data provenance system based on blockchain technology could provide benefits in vaccine supply chain scenarios. In particular, it enables the backtracking of errors in case of breakage of the cold chain, and it helps to build and to keep trust in immunisation programmes by preventing counterfeit vaccines from entering the supply chain.

\textit{Health Monitoring Systems.} Health monitoring scenarios are another application area where tamper-proof data provenance records can provide additional trust in data~\cite{griggs2018healthcare}. In such scenarios, sensors monitor health conditions of patients such as a patient's heart rate, blood pressure, etc. Combined with a real-time analytics service, the sensor readings can be used to notify relatives and health professionals in case of medical emergencies, such as a heart attack. Ideally, the root cause of such a notification is verifiable, i.e., it is possible to trace back a notification to the individual sensor readings which caused it. Otherwise, if the circumstances that led to the emergency notification are unclear, the possibility that the notification was caused by a malicious attack tampering with the system cannot be excluded. Having tamper-proof provenance data for a notification, such as information about the individual sensor readings and analytics involved, ensures the reliability and accuracy of the system.

\section{Evaluation}
\label{sec:eval}
We evaluate the framework with regard to the functional and non-functional requirements defined in~\cref{sec:requirements}. The use cases defined in \cref{sec:background} act as basis for the evaluation of \Crefrange{req:abstraction}{req:complete}. In addition, we reason about the fulfilment of \Crefrange{req:lineage}{req:parallel} in an exemplary fashion applying the use case of vaccine supply chains. However, the scenario of vaccine supply chains is merely used to provide a more descriptive analysis. The information specific to the vaccine supply chain can be substituted with data reflecting any other use case. While the presented framework is blockchain-agnostic, the non-functional requirements~(\Crefrange{req:integrity}{req:scalability}) are evaluated using the proof-of-concept implementation. Experiments are performed on the public Ethereum test networks Rinkeby\footnote{\url{https://rinkeby.etherscan.io/}} and Ropsten\footnote{\url{https://ropsten.etherscan.io/}}. Rinkeby and Ropsten are chosen as test networks since their average block times most closely resemble the block times of the main Ethereum network

\paragraph{Provenance Abstraction~(\Cref{req:abstraction})} The presented framework consists of multiple abstraction layers. The storage layer is responsible for low-level storage of provenance records while the generic provenance layer extends the storage layer's functionality with generic provenance features and enhanced access control. The generic provenance layer can be extended by use case-specific smart contracts controlling certain parameters of the application, e.g., by assigning ownership of tokens, and/or by exposing or hiding parts of the generic layer's API. For instance, in the scenario of vaccine supply chains, a specific provenance smart contract might give an entity such as the World Health Organisation complete control over who is able to acquire tokens, e.g., only trusted vaccine manufacturers. In the use case of health monitoring systems, multiple approved manufacturers might have control over assigning ownership of data point IDs. Hence, we conclude that the framework acts as a base abstraction which can be extended to fulfil the needs of specific provenance use cases. Thus, we regard \Cref{req:abstraction} as fulfilled.

\textit{High-level and Low-level Provenance~(\Cref{req:high-level}).} The framework identifies each data point by its corresponding token. As long as a unique token (i.e., ID) gets assigned to a data point, provenance information for that data point can be recorded. Hence, the framework does not pose any restrictions on the nature of the data point. It is possible to record provenance information for high-level as well as low-level data points. The \emph{context} parameter of a provenance record can be used to add any kind of information the user desires. In the use case of vaccine supply chains, provenance information could not only be collected for the vaccines themselves, but also for sensor readings along the supply chain, e.g., temperature readings which document an uninterrupted cold chain. Within health monitoring systems, the patients themselves might be represented by data points. The patients' provenance traces are then augmented by provenance information from low-level data points deriving from medical devices. Hence, we regard \Cref{req:high-level} as fulfilled.

\textit{Completeness~(\Cref{req:complete}).} The broad definition of the \emph{context} parameter allows the collection of all information necessary for complete provenance tracking. The definition of completeness is largely dependent on the specific provenance use case. In the example of vaccine supply chains, information required to prove the origin of vaccines and an uninterrupted cold chain can be recorded. Regarding health monitoring systems, we are able to record all information necessary to provide reliable root cause information for medical emergencies. Therefore, \Cref{req:complete} can also be regarded as fulfilled.

\textit{Creation of Lineage~(\Cref{req:lineage}).}
As an example, we assume that the manufacturer \textit{SaferVaccines Inc.} produces a new vaccine \textit{vacc$_{1}$}. The freshly produced vaccine is packaged with an RFID tag and assigned with a unique ID. A completely new provenance record for the vaccine is created, such as $\textit{prov}(\textit{vacc}_{1})$$=$\allowbreak\tuple{addr$($vacc$_{1})$}{$\emptyset$}{\tuple{agent$=$operator$_{1}$@Safer\-Vaccines\-Inc}{time$=$\allowbreak5am}{...}}~~. Vaccine~\textit{vacc$_{1}$} is loaded onto an aircraft~\textit{air$_{1}$}. An RFID reader at the factory gate scans the vaccine and registers a new provenance record of the vaccine leaving the factory, such as \textit{prov$($vacc${1}$}$)'$$=$\tuple{addr$($vacc$_{1})$}{$\{$prov$($vacc$_{1})\}$}{\tuple{agent$=$\allowbreak rfid$_{1}$\-@Safer\-Vac\-cines\-Inc}{time$=$5am}{...}}~~. Shortly after, an RFID reader at the aircraft's entrance registers the vaccine entering the aircraft, e.g., \textit{prov$($vacc$_{1})''$$=$}\allowbreak\tuple{addr$($vacc$_{1})$}{$\{$prov$($vacc$_{1})'\}$}{\tuple{agent$=$rfid$_{1}$\-@air$_{1}$}{time$=$5am}{...}}~~. The provenance records \textit{prov$($vacc$_{1})$}, \textit{prov$($vacc$_{1})'$}, and \allowbreak\textit{prov$($vacc$_{1})''$} represent the lineage of the vaccine. This shows exemplarily how the framework fulfils \Cref{req:lineage}.

\textit{Derivation~(\Cref{req:derivation}).}
Continuing the example from \Cref{req:lineage}, inside the aircraft, sensors constantly monitor the temperature. There are three readings from a temperature sensor: \textit{dp}$_{1}=38^\circ$F, \textit{dp}$_{2}=45^\circ$F, \textit{dp}$_{3}=40^\circ$F. The provenance records are given as follows:\par

$\textit{prov}(\textit{dp}_{1})$$=$\tuple{addr$(\textit{dp}_{1})$}{$\emptyset$}{\tuple{agent$=$sensor}{time$=$7am}{...}}~~\par

$\textit{prov}(\textit{dp}_{2})$$=$\tuple{addr$(\textit{dp}_{2})$}{$\emptyset$}{\tuple{agent$=$sensor}{time$=$8am}{...}}~~\par

$\textit{prov}(\textit{dp}_{3})$$=$\tuple{addr$(\textit{dp}_{3})$}{$\emptyset$}{\tuple{agent$=$sensor}{time$=$9am}{...}}~~\par

\noindent A fourth data point $\textit{dp}_{4}$ is created by a software agent calculating the average temperature, i.e., $\textit{dp}_{4}=(\textit{dp}_{1}+\textit{dp}_{2}+\textit{dp}_{3})/3 = 41^\circ$F. This data point's provenance record is defined as $\textit{prov}(\textit{dp}_{4})$$=$\tuple{addr$(\textit{dp}_{4})$}{$\{\textit{prov}(\textit{dp}_{1}),\textit{prov}(\textit{dp}_{2}),\textit{prov}(\textit{dp}_{3})\}$}{\allowbreak\tuple{agent$=$ave\-rager\-@air$_{1}$}{time$=$10am}{...}}~~. Hence, the framework allows for the creation of provenance records for data points deriving from multiple other data points~(\Cref{req:derivation}).

\textit{Provenance for Modifications of Data Points~(\Cref{req:modification}).}
In a further step, the calculated average temperature $\textit{dp}_{4}$ is converted into a different unit: $\textit{dp}_{4}' = 5^\circ$C~(i.e., from Fahrenheit to Celsius). The resulting provenance record looks like $\textit{prov}(\textit{dp}_{4}')$$=$\tuple{addr$(\textit{dp}_{4}')$}{$\{\textit{prov}(\textit{dp}_{4})\}$}{\tuple{agent$=$con\-ver\-ter@air$_{1}$}{time$=$11am}{...}}~~. Thus, the framework is also able to support the modification of data points~(\Cref{req:modification}).

\textit{Parallel Provenance~(\Cref{req:parallel}).}
Besides measuring the temperature inside the aircraft (\textit{air$_{1}$}), we might also want to track the location of the aircraft at the same time. The framework enables the creation of parallel provenance records since each data point is mapped to a list of associated provenance records~(see \cref{sec:generic-provenance-layer}). We can create one provenance record $\textit{prov}_{\textit{temperature}}(\textit{air}_{1})$ representing the latest temperature inside the aircraft, and one provenance record $\textit{prov}_{\textit{location}}(\textit{air}_{1})$ representing the latest location of the aircraft. Hence, we regard \Cref{req:parallel} as fulfilled.

\textit{Integrity~(\Cref{req:integrity}).}
The presented framework uses blockchain technology to provide trustless and tamper-proof storage of provenance records for IoT data. Thus, once records have entered the system, the integrity of records depends on the underlying blockchain technology. Ethereum is a public blockchain with around 8250 fully validating nodes securing the network at the time of writing\footnote{26 July 2019 (\url{https://ethernodes.org/network/1})}. Hence, we consider the integrity requirement for data and computations on Ethereum as fulfilled. However, the framework also needs to provide mechanisms to ensure only correct records enter the system in the first place. As a first step, we implement the concept of ownership of data points using tokens to prevent arbitrary clients from creating provenance records. In future work, this concept could be further extended by mechanisms that guarantee the correctness of the records themselves.

\textit{Availability~(\Cref{req:availability}).}
In public blockchain networks like Ethereum potentially anyone can run a full node. Hence, we consider the availability requirement as fulfilled.

\textit{Privacy~(\Cref{req:privacy}).}
While the privacy requirements of a provenance system largely depend on the concrete use case at hand, in scenarios with sensitive data, such as a health monitoring system, privacy is crucial~\cite{griggs2018healthcare}. However, privacy remains an ongoing challenge in the realm of (public) blockchains, since a blockchain's security relies on data being transparent and verifiable by every participant. A blockchain-based data provenance framework suffers from the same problem. While some propose to use private blockchains in scenarios where privacy is important~\cite{griggs2018healthcare}, this is not sufficient in scenarios which also depend on the system being publicly available, such as global vaccine supply chains.

\textit{Scalability~(\Cref{req:scalability}).}
Since IoT scenarios potentially deal with massive amounts of data and frequent data updates, we evaluate the framework's scalability with regard to latency and transaction throughput. Latency and throughput are mostly influenced by two factors, network load~(how many transactions are submitted to the blockchain) and gas price~(how much are the senders of the individual transactions paying as fee). With a higher number of pending transactions (i.e., higher network load), not every transaction can be included within the next block of the blockchain which means higher priced transactions get prioritised since block validators earn more per each included transaction. As the gas price is increased, the average latency converges to the average block time~($\sim$14-30 seconds) of the blockchain, since higher-priced transactions are almost certainly included within the next block. To evaluate throughput, we submit up to 150 transactions to the test network during a 60 second time frame. Afterwards, we divide the number of confirmed transactions with the time frame of 60 seconds to calculate the transactions per second~(TPS). \cref{fig:throughput} shows the average transaction throughput of our experiments. The tradeoff that blockchain-based systems make in terms of scalability and security becomes clear with an average throughput of only 1-1.6~TPS. Increasing the gas cost does not seem to improve throughput beyond a certain point. Notably, throughput was measured from a user perspective, i.e., transactions were submitted from a single account. The maximum global throughput of the Ethereum blockchain is roughly 20~TPS.

To sum up, the framework fulfils all functional requirements defined in \cref{sec:requirements}. By leveraging block\-chain technology, the non-functional requirements of integrity and availability can be fulfilled. Regarding scalability and privacy, the use of blockchain technology poses limitations. Throughput and latency of the framework are constrained, and the inherent transparency of blockchain technology naturally presents a challenge for privacy-sensitive applications.

\begin{figure}\centering
\begin{tikzpicture}[baseline]
\begin{axis}[
ybar,
height=4cm,
width=8cm,
bar width = 5,
enlargelimits=0.15,
legend style={font=\footnotesize,at={(0.5,1)}, anchor=north, legend columns=-1}
ylabel={Throughput (TPS)},
xlabel={Gas price (Gwei)},
domain=1:10,
samples=3,
symbolic x coords={0.5,1,2,5,10,20},
ymin=0.2, ymax=2,
ymajorgrids=true,
grid style=dashed,
xtick={0.5,1,2,5,10,20},
]
\addplot[
	green,
	fill=green!20!white,
	error bars/.cd,
	y dir=both, y explicit,
] coordinates {
	(1,0.572509178) +- (0,0.4784040076)
	(2,1.298646475) +- (0,0.3797103555)
	(5,1.04018638) +- (0,0.385890031)
	(10,1.126490439) +- (0,0.3331919714)
	(20,1.225819142) +- (0,0.3868106149)
};
\addplot[
	blue,
	fill=blue!20!white,
	error bars/.cd,
	y dir=both, y explicit,
] coordinates {
	(1,1.608066017) +- (0,0.04224049755)
	(2,1.551054492) +- (0,0.03810158513)
	(5,1.497250152) +- (0,0.09152118733)
	(10,1.681352858) +- (0,0.04618427386)
	(20,1.544044728) +- (0,0.03367507604)
};
\legend{Ropsten,Rinkeby}
\end{axis}
\end{tikzpicture}
\caption{Avg. Throughput for Creating Provenance Records}
\label{fig:throughput}
\end{figure}

\section{Discussion}
\label{sec:discussion}
As we have demonstrated, the presented framework is able to satisfy~\Crefrange{req:abstraction}{req:parallel} by building on top of the generic data provenance model for the IoT and by providing abstraction layers which specific use cases can adopt to their own requirements such as the assignment of ownership of data point IDs. Further, the framework relies on blockchain technology to provide guarantees of integrity and availability~(\Cref{req:integrity} and \Cref{req:availability}). However, the fundamental design of what makes the blockchain secure causes its limited scalability and privacy~\cite{christidis2016blockchains}. While in some cases a private blockchain can be employed to provide better privacy and scalability~\cite{griggs2018healthcare}, in global IoT scenarios entailing massive amounts of data and frequent data updates where public access to the system is necessary, a private blockchain might not be a viable option~\cite{fernandez2018review}. Hence, a solution is needed to improve the privacy and scalability properties of a public blockchain system while keeping its integrity and availability guarantees. Several recent blockchain developments try to tackle these limitations, e.g., state channels~\cite{eberhardt2017or}, zero-knowledge proofs~\cite{eberhardt2018zokrates}, and sidechains~\cite{back2014enabling}.

\subsubsection{State Channels}
State channels increase scalability by off-chaining state transitions~\cite{eberhardt2017or}. Two participants open a state channel by locking some state on the blockchain~(e.g., in a smart contract). Once locked, they perform transactions on that state off-chain. The only requirement is that both participants sign off these transactions, using signatures verifiable on-chain, and that the transactions are ordered. This allows both participants to finalise the state on the blockchain at any time, since they can prove via the signatures that the counterpart agreed to the update. A state channel reduces the cost of transactions or hides them from outsiders since the guarantee of settling a transaction at any point is as good as having the transaction executed directly on the blockchain and only the final state update becomes visible in the blockchain~\cite{eberhardt2017or}. These characteristics make state channels a viable choice for increasing scalability and improving privacy in blockchain-based IoT applications, e.g., in scenarios with micro-transactions occurring between devices

\subsubsection{Zero-knowledge proofs}
Zero-knowledge proofs are an off-chaining pattern, where a prover tries to convince a verifier about the correct execution of a computation without revealing the parameters of the computation to the verifier~\cite{eberhardt2017or}. The aim is for the verifier to be able to verify that the prover correctly executed the computation without the verifier knowing any of the inputs required for the computation, thus having zero knowledge. To take advantage of zero-knowledge proofs in blockchains, zkSNARKs (zero-knowledge Succinct Non-interactive ARguments of Knowledge) can be employed~\cite{eberhardt2018zokrates}. 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 computationally expensive, leading to high hardware requirements for the prover. This can be a problem in IoT scenarios when the prover is hardware-constrained. Also, off-chaining state transitions is only beneficial when the verification of the computation is less expensive than the computation itself. Thus, while zkSNARKs can improve scalability and privacy, it needs to be evaluated whether the initial overhead is justifiable in IoT applications.

\subsubsection{Sidechains}
The main idea of sidechains is to take load off of an existing blockchain (i.e., the parent chain) by outsourcing some of its data and computation to a separate blockchain (i.e., the sidechain)~\cite{back2014enabling}. Sidechains are ``pegged'' to the parent chain, i.e., the state of the sidechain is secured via regular commits to the parent chain. Such commits entail the root hash of a Merkle tree consisting of all transactions that have occurred on the sidechain. This way, all transactions of the sidechain are secured via a single hash on the parent chain. This link enables participants to retreat back to the secure and reliable parent chain via so-called exits in case malicious behaviour is detected on the sidechain~\cite{back2014enabling}, e.g., when sidechain validators mine invalid blocks or withhold blocks completely. While sidechains can potentially employ different, more efficient consensus mechanisms than the parent chain, scalability gains primarily derive from participants of a sidechain not having to validate all global transactions of the parent chain anymore, but only the transactions occurring on the sidechain. Thus, a validator's hardware requirements can remain low, while transaction throughput is increased as transactions and data of the parent chain are split up into multiple different sidechains. As such, sidechains improve throughput rather than latency~\cite{konstantopoulos2018plasma}. Further, sidechains could be kept secret to improve privacy.

While the above approaches are promising with regard to improving scalability and privacy of blockchain applications, in future work, it needs to be evaluated if and how these solutions can be employed to provide scalability and privacy improvements in global IoT scenarios which require a certain degree of integrity but are characterised by computationally restrained devices combined with frequent but relatively small data updates.

\section{Requirements}
\label{sec:requirements}
This section defines the functional and non-functional requirements of a generic data provenance framework for the IoT. Such a framework needs to record provenance information for addressable data points, i.e., data that has a unique ID~\cite{olufowobi2017data}. In accordance with~\cite{freire2008provenance} and~\cite{olufowobi2017data}, we derive the functional requirements~(\Crefrange{req:abstraction}{req:parallel}) of our framework. Further, in accordance with Hasan et al.~\cite{hasan2009preventing}, we define non-functional requirements that need to be fulfilled by a tamper-proof data provenance system for the IoT~(\Crefrange{req:integrity}{req:scalability}).

\begin{requirements}[leftmargin=*]
	\item \textit{Provenance Abstraction:} The framework needs to provide generic data provenance capturing, storing, and querying functionality which can be adopted by provenance use cases to map their specific requirements. \label{req:abstraction}

	\item \textit{High-level and Low-level Provenance:} Provenance records represent high-level as well as low-level data points. Low-level data points stem from low-level devices such as sensors. High-level data points do not have a single physical origin (such as a sensor reading) but represent more abstract concepts, e.g., some physical object in a supply chain or an analytics result based on multiple inputs.\label{req:high-level

	\item \textit{Completeness:} A provenance record is complete if every relevant action which has ever been performed on a data point is gathered~\cite{hasan2009preventing}. Here, relevance implies that some actions can be neglected if they do not contribute to the provenance information of a particular data point.\label{req:complete

	\item \textit{Creation of Lineage:} Provenance records for a data point can be created based on the last provenance record for that same data point. This enables the creation of lineage. For instance, the lineage of a data point representing a physical good travelling along a supply chain can be tracked by creating a new provenance record based on the old one at each critical step of the supply chain.\label{req:lineage

	\item \textit{Derivation:} A provenance record entails references to the provenance records of the data points that led to its creation. For instance, a provenance record for an analytics result based on value readings from multiple sensors must not only contain information about the sensor values but must also be able to access provenance information of those same values, such as location and time of recording.\label{req:derivation

	\item \textit{Provenance for Modifications of Data Points:} The framework enables the tracking of the modification history of a specific data point. For instance, if an analytics result runs through multiple stages of different calculations, the history of these calculations can be tracked.\label{req:modification

	\item \textit{Parallel Provenance:} Multiple provenance records for the same data point can exist in parallel, e.g., one provenance trace might track the ownership of a data point (e.g., ownership of a physical good), while another provenance record is tracking the location of that same data point.\label{req:parallel

	\item \textit{Integrity:}  Integrity mandates that provenance records cannot be manipulated or modified by an adversary in any way. This is crucial for establishing trust in the data. Without guaranteed integrity, clients can potentially repudiate provenance records.\label{req:integrity

	\item \textit{Availability:} Data can be accessed when needed.\label{req:availability

	\item \textit{Privacy:} Provenance records of IoT devices can contain sensitive data, e.g., in a health monitoring system. It is therefore vital to keep this data confidential, i.e., to prevent access by unauthorised entities. In addition, even when the data itself is kept confidential, malicious actors might still be able to create user profiles by identifying user-specific data patterns. Hence, traceability of provenance data needs to be prevented to ensure user privacy.\label{req:privacy}

	\item \textit{Scalability:} A provenance system is required to have a reasonable expenditure. Storing and accessing provenance information must have a low overhead. Especially, even though some IoT devices are resource-constrained, they must not be excluded from participating in the provenance framework. Further, applications in the IoT potentially deal with massive amounts of data and very frequent data updates which a provenance solution needs to account for.\label{req:scalability

\end{requirements}
\section{Related Work}
\label{sec:related}

As mentioned in Section~\ref{sec:intro}, other works~\cite{baracaldo2017securing, polyzos2017blockchain} focus on providing generic blockchain-based data provenance solutions for the IoT. However, these approaches remain conceptual with no provided implementation. In contrast, the framework presented in the work at hand has been fully implemented and is available as open-source software. Other solutions related to blockchain-based data provenance in the realm of the IoT go beyond conceptual approaches~\cite{toyoda2017novel, westerkamp2018blockchain, wu2017distributed, griggs2018healthcare, cebe2018block4forensic}. While the approaches presented in \cite{westerkamp2018blockchain, toyoda2017novel, wu2017distributed} focus on securing provenance information in supply chains, the works in~\cite{griggs2018healthcare} and \cite{cebe2018block4forensic} focus on a blockchain-based patient monitoring system to provide notifications in case of medical emergencies, and a framework that tracks information about vehicles to resolve disputes between drivers, insurance companies and maintenance server providers in case of accidents, respectively. In general, these solutions demonstrate how provenance concepts can be brought onto the blockchain~(e.g., via smart contracts). However in contrast to our work, though IoT technologies are addressed, these solutions are use case-specific and do not provide a generic provenance framework that is required for the heterogeneous nature of the IoT~\cite{olufowobi2017data, li2015internet}.

Provenance in the supply chain has also received attention in the industry. Startups like Provenance\footnote{\url{https://www.provenance.org/}} and Everledger\footnote{\url{https://www.everledger.io/}} focus on securely tracking goods traveling along a supply chain via blockchain technology. However, their sole focus lies on tracking physical items instead of any kind of data within the IoT. Further, works have also focused on blockchain-based data provenance solutions outside the IoT domain, e.g., blockchain-based data provenance for cloud environments to verify the operation history of data in the cloud~\cite{tosh2019data}, or in the scientific field where blockchain technology is used to secure the derivation history of scientific data~\cite{ramachandran2018smartprovenance}.

As can be seen by the discussion, to the best of our knowledge, there is no other approach which provides a generic framework for tracking data provenance in the IoT.

\section{Conclusion}
\label{sec:conclusion}

The presented framework provides a data provenance solution which is appropriate for the heterogenous nature of the IoT. By leveraging a generic data model together with a layered architecture of smart contracts, the framework is able to fulfil the functional requirements. By building on blockchain technology, the framework further fulfils the non-functional requirements of integrity and availability but has some limitations regarding scalability and privacy. Multiple current blockchain developments seek to overcome these issues without jeopardising blockchain security, e.g., state channels, zero-knowledge proofs, and sidechains~\cite{eberhardt2017or}. Thus, in future work, we will evaluate in detail to what extent these approaches provide solutions to the privacy and scalability problem in the context of blockchain-enhanced IoT applications, such as our data provenance framework.

\section{Introduction}
\label{sec:intro}
The Internet of Things (IoT) is transforming many areas of our everyday lives. IoT technologies such as GPS, RFID-based identification, and low-resource computing platforms like the Raspberry Pi already play important roles in various domains, e.g., mobility, logistics, healthcare, and retail~\cite{li2015internet}. Since data collected by these technologies find application in an increasing number of use cases, ensuring the trustworthiness of such data is of high importance~\cite{aman2017secure}.

Data provenance systems are one way to ensure trustworthiness in the IoT~\cite{bertino2014data}. These systems can provide information about the origin and evolution of data such as the various stages of data creation and data modifications, who initiated them, and when and how they took place~\cite{freire2008provenance}. In short, a data provenance system tracks who has created, updated, deleted, and in some cases read particular data points~\cite{freire2008provenance}. In order to trust the information provided by a provenance system, it is essential that the provenance system stores information in a tamper-proof and replicable way~\cite{hasan2009preventing}.

Traditionally, in distributed settings, participants must either trust each other or an independent third-party to store data in a tamper-proof way. With the advent of blockchain technologies, the requirement of such trust in a central authority is eliminated. Instead, a decentralised network can be established, acting as a distributed, tamper-proof ledger~\cite{christidis2016blockchains}. Thus, leveraging blockchain technology in a data provenance solution for the IoT is a promising choice~\cite{christidis2016blockchains}.

The IoT is characterised by a multitude of use cases and potential application areas~\cite{li2015internet}. An IoT data provenance solution has to account for this diversity~\cite{olufowobi2017data}. However, approaches aiming at scenario-agnostic blockchain-based data provenance solutions for the IoT offer so far no concrete software solutions~\cite{polyzos2017blockchain, baracaldo2017securing}, and more concrete solutions to data provenance in the IoT only focus on specific application areas, for instance, supply chains~\cite{toyoda2017novel, westerkamp2018blockchain, wu2017distributed}, health monitoring systems~\cite{griggs2018healthcare}, or digital forensics~\cite{cebe2018block4forensic}.

Hence, we propose a generic blockchain-based data provenance framework for the IoT that can be applied to a variety of use cases. The advantages of a generic framework are the easier adoption of provenance concepts by new use cases and the interoperability of applications that use the framework. The contributions of this work are as follows:

\begin{itemize}[leftmargin=*]
	\item We define functional and non-functional requirements for a generic IoT data provenance framework.
	\item We conceptualize and implement an IoT data provenance framework consisting of smart contracts using a generic data model to provide provenance functionality for a wide range of IoT use cases.
	\item We present an evaluation of the framework with regard to the defined requirements using a proof-of-concept implementation with Ethereum smart contracts.
\end{itemize}

Following, we briefly explain underlying concepts and provide exemplary use case scenarios~(\cref{sec:background}), define the requirements~(\cref{sec:requirements}), and explain the concepts, architecture, and proof-of-concept implementation of our IoT data provenance framework~(\cref{sec:framework}). In~\cref{sec:eval}, we evaluate the framework with regard to the defined requirements. \Cref{sec:related} provides an overview of the related work. Finally, \cref{sec:conclusion} concludes the paper.

\section{IoT Data Provenance Framework}
\label{sec:framework}

\begin{figure}
	\centering
	\includegraphics[width=0.49\textwidth, height=4.2cm]{architecture}
	\caption{Data Provenance Framework Architecture}
	\vspace{-2.5mm}
	\label{fig:architecture}
\end{figure}

This section presents the proposed generic blockchain-based data provenance framework for the IoT. As mentioned in~\cref{sec:intro}, the benefits of a generic framework are interoperability between applications using the framework and the facilitated implementation of provenance concepts for new IoT use cases. \Cref{fig:architecture} displays the core architecture of the framework. It consists of three layers all embedded within a blockchain smart contract platform. Each layer represents a different level of abstraction with a diverse set of responsibilities within the framework. The storage layer is primarily concerned with low-level representation and storage of provenance data, the generic provenance layer provides general-purpose provenance functionality, while the specific provenance layer can be modified by use cases to fine-tune the framework to their specific requirements.

A proof-of-concept implementation of the framework based on Ethereum smart contracts is available as open-source software at Github\footnote{\url{https://github.com/msigwart/iotprovenance}}.

\subsection{Data Model}
\label{sec:data-model}
Provenance information varies depending on the specific domain or application~\cite{olufowobi2017data}. Since the IoT domain is characterised by heterogeneous applications and a wide range of possible use cases~\cite{li2015internet}, there is a need for a generalised provenance model suitable for IoT applications. As the underlying data model, our framework utilises the data provenance model by Olufowobi et al.~\cite{olufowobi2017data} since their model is specifically designed to address IoT provenance data. The model defines a provenance record for some data point \textit{dp} as follows:

\begin{displaymath}
\begin{aligned}
	\textit{prov} : \textit{dp} \mapsto & \langle \textit{addr}(\textit{dp}), \{\textit{prov}(\textit{idp}) | \forall\textit{idp} \in \textit{inputs}(\textit{dp})\}, \\
	& \textit{context}(\textit{dp})\rangle
\end{aligned}
\end{displaymath}

A provenance record \textit{prov}$($\textit{dp}$)$ for a data point \textit{dp} consists of a 3-tuple associating the address \textit{addr}$($\textit{dp}$)$ of \textit{dp}~(i.e., some kind of ID) with the set of provenance records of the data points that led to the creation of \textit{dp}~(i.e., \textit{inputs}$($\textit{dp}$)$), and a context~\textit{context}$($\textit{dp}$)$. The context denotes information of interest for provenance about the state of the IoT system, e.g., information about agents involved in the computation of the data point, time and location, or the execution context. This definition of provenance allows for the description of both creation and modification of data points. In the former case, the set of input provenance records contains an empty set. In the latter case, the set of input provenance records contains the provenance record of the data point before modification, i.e., \(\textit{prov}(\textit{dp}') = \langle \textit{addr}(\textit{dp}'), \{\textit{prov}(\textit{dp}), ...\}, \allowbreak\textit{context}(\textit{dp}')\rangle \).

The described data provenance model combined with blockchain technology builds the basis for our IoT data provenance framework. This way, the framework can not only represent provenance information for various IoT use cases, but also provides integrity guarantees for the recorded data.

\begin{lstlisting}[caption={Storage Contract (Excerpt)	}, label=lst:provenance-records, float]
contract Storage {
struct ProvenanceRecord {
    uint tokenId;
    uint[] inputProvenanceIds;
    string context;
    uint index;
}
mapping (uint -> ProvenanceRecord) records;
uint[] provenanceIndex;
function getProvenance(uint provId)
public view returns (uint tokenId, ...) {...}
...
function createProvenance(uint provId, ...)
internal returns (uint index) {...}
...
}
\end{lstlisting}

\subsection{Storage Layer}
\label{sec:storage-layer}
This layer is responsible for the low-level storage of provenance records. It contains the generic representation for provenance records as defined by the data provenance model, as well as basic functionality to create, retrieve, update, and delete provenance records. Delete refers to the invalidation of provenance records, since truly deleting data from a blockchain is not possible. An invalidated provenance record cannot be used as input for subsequent provenance records.

\Cref{lst:provenance-records} displays an excerpt of the smart contract implementing this layer. The internal representation of provenance records (Lines 2--7) closely resembles the model discussed above with the field \textit{tokenId} representing the ID of a data point. However, not only are data points addressable, but also the provenance records themselves. Addressable provenance records allow the storage layer to manage provenance records as a mapping from provenance IDs to provenance records: $\textit{addr}(\textit{prov}) \mapsto \textit{prov}$ where the function \textit{addr}$($\textit{prov}$)$ represents the ID of a provenance record \textit{prov}. The mapping is implemented via the \textit{mapping} keyword~(Line 8).

The contract exposes an API for creating, retrieving, updating, and deleting (i.e., invalidating) provenance records. Note that, while functionality for retrieving provenance records is exposed publicly via the \textit{public} keyword (Lines~10ff), functionality for creating, updating, and deleting records is protected via the \textit{internal} keyword (Lines~13ff). These functions cannot be accessed publicly, but are accessible from inheriting contracts such as the contract representing the generic provenance layer. Read-functions are publicly accessible since these functions do not alter the state of the contract.

\subsection{Generic Provenance Layer}
\label{sec:generic-provenance-layer}
The generic provenance layer's main purpose is to provide general-purpose provenance functionality on top of the storage layer, i.e., it provides features that are universally applicable for a wide range of provenance use cases. The generic provenance layer has the following responsibilities.

\paragraph{Ownership of Data Points}
\label{sec:design-ownership}
While blockchain technology can guarantee the integrity of data provenance records once those records have entered the system, mechanisms need to be in place to ensure that the records that enter the system are correct. As a first step, we aim to prevent the creation of provenance records by arbitrary clients, i.e., if client $A$ generates some data point $\textit{dp}_0$, we want to make sure that only client $A$ (or any client authorised by client $A$) is able to create provenance records for $\textit{dp}_0$. Thus, we introduce the notion of ownership of data points. Each data point belongs to a specific client of the system, and only the owner or a client authorised by the owner can create provenance records for it. If an unauthorised client tries to create a provenance record for a data point, the system raises an error

The notion of ownership is closely related to so-called tokens, i.e., smart contracts deployed on a blockchain that represent a kind of digital asset~\cite{tokens}. Our framework leverages tokens to introduce ownership of data points. Each data point is represented by a single token and a single token identifies exactly one data point. This one-to-one mapping allows us to identify the owner of a data point by identifying the owner of a particular token.

Each token acts as an entry ticket to the provenance framework. To create provenance records for a particular data point, a client first has to become the owner or be approved by the owner of the corresponding token. The prototype uses the Ethereum token standard ERC721\footnote{\url{https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md}} which defines a common interface for non-fungible assets, for instance, functions for transferring ownership. This has the advantage that our tokens (i.e., the data points) can be traded by any client implementing this standard, such as wallets or exchanges. By transferring ownership, data points can pass from owner to owner, leaving a trail of provenance records created by each owner along the way. This is useful for implementing provenance applications, e.g., in supply chain scenarios

\paragraph{Associating Provenance Records with Data Points}
\label{sec:datapoint-provenance-mapping}
The generic provenance layer further links together data points and their respective provenance records. The framework provides information about associated provenance records of specific data points. Within the generic provenance layer, this is achieved by using a mapping from a data point~ID to a set of associated provenance IDs:
\begin{displaymath}
	\textit{addr}(\textit{dp}) \mapsto \{\textit{addr}(\textit{prov}_{1}(\textit{dp})), \textit{addr}(\textit{prov}_{2}(\textit{dp})), ...\}
\end{displaymath}
All associated provenance records (\textit{prov}$_{1}$, \textit{prov}$_{2}$, etc.) represent parallel provenance traces for the same data point. Of those records, each one represents a completely independent trail of provenance information. For instance, one trail of provenance records might trace the temperature history of a physical good, while another one might trace its location.

\Cref{lst:associated-provenance} displays an excerpt of the smart contract implementing this layer and demonstrates the general workflow for creating new provenance records. First, the contract verifies that a given token (i.e., data point) exists~(Line~7) and that the token belongs to the sender of the message~(Line~8). After validating the input provenance records~(Line~9), the contract creates a new provenance ID~(Line~10), adds it to the list of associated provenance~(Line~11), and calls the storage contract's \textit{createProvenance} function~(Line~12). Note that the \textit{createProvenance} function of the generic contract is again internal, and thus not accessible publicly. This enables specific provenance contracts which implement concrete use cases to further adapt the functionality according to their needs.

\begin{lstlisting}[caption={Generic Provenance Contract (Excerpt)}, label={lst:associated-provenance}, float]
contract GenericProvenance is ERC721, Storage {
...
mapping (uint => uint[]) internal associatedProv;
...
function createProvenance(uint tokenId, ...)
internal returns (uint index) {
    require(exists(tokenId));
    require(ownerOf(tokenId) == msg.sender);
    checkValidProvenance(inputProvenance);
    uint provId = getProvId();
    addAssociatedProvenance(tokenId, provId);
    return super.createProvenance(provId, ...);
}
...
\end{lstlisting}

\subsection{Specific Provenance Layer}
\label{sec:specific-provenance-layer}
\begin{lstlisting}[caption={Specific Provenance Contract (Example)}, label={lst:specific-provenance}, float]
contract Specific is GenericProvenance {
function requestToken()
public returns (uint tokenId) {
    uint tokenId = getTokenId();
    return super.mint(msg.sender, tokenId);
}
function createProvenance(uint tokenId,
string location, uint temperature, ...)
public returns (uint index) {
    string context = createContext(location,
    temperature, ...);
    return super.createProvenance(provId,
    context, ...);
}
...
\end{lstlisting}
Smart contracts within this layer utilise the functionality provided by the generic provenance layer, but control a subset of parameters by themselves. This way, use cases can customise the provenance model according to their needs, and control access to the functionality provided by the storage and generic provenance layer. \Cref{lst:specific-provenance} displays an excerpt of an exemplary smart contract implementing this layer.

The provenance model can be customised by defining the \textit{context} parameter, so that it presents the provenance information needed for a specific use case scenario. For instance, in the case of vaccine supply chains, the context should contain temperature and location information about individual vaccines. Hence, a specific contract could define its own \textit{createProvenance} function that requires parameters like \textit{temperature}, and \textit{location}~(Lines~7ff) which are then combined to form the \textit{context} to be passed on to the \textit{createProvenance} function of the generic provenance contract~(Lines~10ff).

Access control happens on two levels. First, a specific contract defines which parts of the generic provenance layer's API are exposed. For instance, even though the generic provenance layer could permit updating or deleting (i.e., invalidating) provenance records, this could be unwanted behaviour in the specific use case at hand. In this case, 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 the ownership of data points. Since data point ownership is the decisive factor with regard to who can create provenance records for which particular data points, contracts in the specific provenance layer are responsible for actually assigning ownership, i.e., which tokens get assigned to which clients. For simplicity, our prototype automatically assigns new tokens to requesting clients~(Lines~2ff). However, ultimately, the most suitable approach is dictated by the specific use case at hand. For instance, clients could purchase tokens. This would keep the framework publicly available while reducing the risk of spamming attacks since the acquisition of tokens incurs financial cost. Another alternative is a white list of authorised clients allowed to request new tokens. This way, the list controls exactly who participates in the provenance system. However, the question arises who is responsible for managing the white list of authorised clients.

\section{Scalable Data Provenance}
\label{sec:scalability}

The fundamental design of what makes the blockchain so secure, causes its limited scalability~\cite{christidis2016blockchains}. Thus, merely packaging a data provenance model within a smart contract platform is not enough for providing a provenance framework that is useful for IoT scenarios, since the IoT potentially involves hardware-constrained devices, frequent data updates, and massive amounts of data~\cite{fernandez2018review}. Following, we review some of the various blockchain scalability solutions with regard to their suitability as scalability solutions in an IoT data provenance framework.

\subsection{Scalability Solutions}
\label{sec:scalability-solutions}
Scalability solutions can generally be divided into ``layer~1'' solutions and ``layer~2'' solutions~\cite{bitcoin2017wiki-scalability-faq}. Layer 1 solutions regard the base layer of the blockchain. They seek to make improvements to the underlying protocols of the blockchain to improve its overall scalability. Some proposed solutions for improving layer 1 scalability are raising the block size limit and sharding. Contrary to layer 1 scalability solutions, layer 2 scalability solutions are not rooted at the base layer and generally revolve around the question of which data and computation should be performed \emph{on} the blockchain versus which data and computation should be performed \emph{off} the blockchain~\cite{eberhardt2017or}. Examples for layer~2 solutions are state channels~\cite{eberhardt2017or}, zero-knowledge proofs~\cite{eberhardt2018zokrates}, and sidechains~\cite{back2014enabling}.

\subsubsection{Raising the block size limit}
Raising the block size limit is an obvious but problematic solution for improving blockchain scalability. The block size limit is used to limit the number of transactions that can be included within each block. A raised block size limit in theory allows for more transactions to be included within each block thus increasing throughput.

However, doing so promotes centralisation. As the size of each block grows, validator nodes have to process more and more data, therefore raising the hardware requirements for each validator. In consequence, some nodes will no longer be able to act as validators because they do not possess the necessary hardware. Thus, scaling vertically by increasing block size reduces the decentralisation of the network---one of the pillars on which the security model of blockchains is built. These shortcomings are also relevant for blockchain applications targeting the IoT. A blockchain where hardware requirements are so high that only supercomputers are able to run full validator nodes is not suitable for the IoT, since IoT applications are usually characterised by devices with low computational resources~\cite{baracaldo2017securing}.

\subsubsection{Sharding}
Sharding is a proposed scaling solution for the base layer of the Ethereum blockchain~\cite{ethereum2018sharding-faq}. Currently, all nodes of the blockchain are required to store the complete state, i.e., all account balances, contract code and storage, etc. They are responsible for processing and validating all transactions occurring within the network. This is what makes the blockchain very secure, but at the same time extremely slow (and expensive).

Sharding splits the state into multiple different partitions, so-called ``shards''. The aim is to only have a subset of nodes validating each shard. If a validator only validates the transactions arriving at a specific shard, requirements for individual nodes can remain fairly low while the overall throughput of the network increases. Of course, it has to be guaranteed that the number of nodes validating each shard is still sufficiently large to keep the overall security of the network at a high level~\cite{ethereum2018sharding-faq}.

Sharding in blockchains is still under active development, so it remains an open question whether this technique can provide secure blockchain scalability at the base layer. Until then, several technological challenges need to be solved, e.g., validators taking over single shards in 51\% attacks, or ``cross-shard'' communication of smart contracts~\cite{ethereum2018sharding-faq}.

\subsubsection{State Channels}
State channels increase scalability by off-chaining state transitions~\cite{eberhardt2017or}. Two participants can open a state channel by locking some state on the blockchain~(e.g., in a smart contract). Once locked, they can perform any number of transactions on that state off-chain. The only requirement is that both participants sign off these transactions, using signatures verifiable on-chain, and that the transactions are ordered. This allows both participants to finalise the state on the blockchain at any time, since they can prove via the signatures that the counterpart agreed to the update. A state channel reduces the cost of transactions or hides them from outsiders since the guarantee of settling a transaction at any point is as good as having the transaction executed directly on the blockchain and only the final state update becomes visible in the blockchain~\cite{eberhardt2017or}.

These characteristics make state channels a viable choice for increasing scalability in blockchain-based IoT applications, e.g., in scenarios with micro-transactions occurring between devices. However, the technology does have its drawbacks, too. For instance, state channels can only have two participants. If other users are also interested in the state updates occurring between these two users, state channels are not a suitable choice.

\emph{State channels} are already in widespread use. The lightning network~\cite{lightning} offers payment channels for the Bitcoin ecosystem. For the Ethereum network, the Whisper Protocol~\cite{whisper} and Raiden~\cite{raiden} are available.

\subsubsection{Zero-knowledge proofs}
Zero-knowledge proofs are an off-chaining pattern, where a \emph{prover} tries to convince a \emph{verifier} about the correct execution of a computation without revealing the parameters of the computation to the verifier~\cite{eberhardt2017or}. The aim is for the verifier to be able to verify that the prover knows all the required input to correctly execute the computation without knowing any of the inputs herself, thus having \emph{zero-knowledge}.

To take advantage of zero-knowledge proofs in blockchains, zkSNARKs (zero-knowledge Succinct Non-interactive ARguments of Knowledge) can be employed~\cite{eberhardt2018zokrates}. This serves two purposes: resource-intensive computations can be performed off-chain; the input of computations can be kept private.

However, proof construction in zkSNARKs is computationally expensive, leading to high hardware requirements for the prover. This can be a problem in IoT scenarios when the prover is hardware-constrained. Also, off-chaining state transitions is only beneficial when the verification of the computation is less expensive than the computation itself. Thus, while zkSNARKs can greatly improve scalability and privacy, in IoT applications with many frequent but small updates (e.g., sensor value updates), the initial overhead in setting up zkSNARKs may not be cost-efficient.

\subsubsection{Sidechains}
Sidechains as introduced by~\cite{back2014enabling}, represent a layer 2 scalability solution. The main idea of sidechains is to take load off of an existing blockchain (i.e., the parent chain) by outsourcing some of its data and computation to a separate blockchain (i.e., the sidechain).

Sidechains are ``pegged'' to the parent chain, i.e., the state of the sidechain is secured via regular commits to the parent chain. Each commit to the parent chain entails the root hash of a merkle tree consisting of all transactions that have occurred on the sidechain. This way, all transactions of the sidechain are secured via a single hash on the parent chain. This link enables participants to retreat back to the secure and reliable parent chain via so-called exit transactions in case malicious behaviour is detected on the sidechain~\cite{back2014enabling}, e.g., when sidechain validators mine invalid blocks or withhold blocks completely.

While different sidechains may deploy different, more efficient consensus protocols, or have shorter block confirmation times so that transaction throughput can be increased at the base layer, scalability gains primarily stem from the fact that participants of a sidechain do not have to validate all global transactions of the parent chain anymore, but only the transactions occurring on the sidechain. Thus, a validator's hardware requirements can remain the same, while transaction throughput can be increased as transactions and data of the parent chain are split up into multiple different sidechains. As such, sidechains improve throughput rather than latency~\cite{konstantopoulos2018plasma}. Throughput can be increased even further by creating sidechains of sidechains~\cite{plasma}.

While sidechains underly the same security-scalability trade-off as any blockchain, their flexibility combined with the security of the parent chain makes them well suited for applications which do not have the same strict security requirements as cryptocurrencies like Bitcoin and Ether, but rather rely on better scalability. Further, contrary to state channels, sidechains are fully-fledged blockchains. Hence, they can have an unlimited number of participants. At the same time, since hardware requirements for validators remain small, the entry barriers to use the system are low.

These properties make sidechains a suitable choice for global IoT scenarios which require a certain degree of integrity but are characterised by computationally restrained devices combined with frequent but relatively small data updates, such as an IoT data provenance system. There are already a number of sidechain projectsin development for both the Bitcoin and the Ethereum blockchains. For instance, in the Bitcoin ecosystem, the RSK project~\cite{rsk} is implementing a sidechain which will allow for the development of Turing-complete smart contracts in a similar way to Ethereum. For Ethereum, Plasma~\cite{plasma} and POA~\cite{poa} are available. The following section describes the data provenance solution for the IoT enhanced with sidechain technology.

\subsection{Scalable Data Provenance Using Sidechains}
\label{sec:scalable-provenance}
The essence of the framework lies in the creation of provenance records for data points. The ownership of a particular token allows participants to create provenance records for the associated data point. Thus, it is crucial that the access to tokens is strictly protected. We therefore demand clients of the provenance system to acquire tokens via a smart contract on the parent chain. This way, the system controls who acquires tokens using the security of the parent chain.

Once the system has assigned tokens to clients, these clients need to create a potentially very large number of provenance records. Because token ownership is protected via the parent chain, clients can move tokens freely onto different sidechains. Each chain can represent different IoT provenance use cases~(\cref{fig:provenance-sidechains}). For example, there might be a sidechain representing the provenance system of a vaccine supply chain as described in~\cref{sec:background}. Another chain might implement a provenance use case in a smart manufacturing scenario, etc. Each of these chains apply their own security-scalability trade-offs using different consensus protocols and network topologies depending on the requirements of the use case at hand, however in case trust in one of the sidechains is eroded or malicious behaviour is detected, clients can always retreat back to the parent chain.

\begin{figure}
	\centering
	\includegraphics[width=0.49\textwidth]{provenance-sidechains}
	\caption{Data Provenance Sidechain Architecture}
	\label{fig:provenance-sidechains}
\end{figure}

\section{Implementation}
\label{sec:implementation}
This section presents a proof-of-concept implementation of the framework based on Ethereum smart contracts. The smart contracts are written in Solidity and are available as open-source software\footnote{\url{https://github.com/iotprovenance/iotprovenance}}.

\subsection{Provenance Storage Contract}
As described in \cref{sec:storage-layer}, the storage layer of the framework provides low-level storage functionality of provenance records. Some of the internals of the smart contract implementing this layer are shown in \cref{lst:provenance-records}. The data structure for a provenance record contains the fields defined by the provenance data model described in~\cref{sec:provenance-model}, such as input provenance IDs and the context. To recall, the context needs to contain all information necessary for a concrete provenance use case. The current prototype implements the context parameter as string value to allow storing any kind of information. To save storage costs, \textit{context} could hold a hash which references provenance data stored in a content-addressable storage such as IPFS\footnote{\url{https://ipfs.io/}}. The \textit{tokenId} field references the data point for which the provenance record was created.

The contract stores provenance records as a mapping $\textit{addr}(\textit{prov}) \mapsto \textit{prov}$. The mapping is implemented via the \textit{mapping} keyword~(Line 8). As mentioned in~\cref{sec:architecture}, this mapping enables random access by the ID of a data point. Further, the contract defines a field \textit{provenanceIndex} implemented as an array containing all provenance IDs within the system~(Line~9). These IDs can be used for iteration over provenance records. The contract exposes an API for creating, retrieving, updating, and deleting (i.e., invalidating) provenance records. Note that, while functionality for retrieving provenance records is exposed publicly via the \textit{public} keyword, functionality for creating, updating, and deleting records is protected via the \textit{internal} keyword. These functions cannot be accessed publicly, but are accessible from inheriting contracts such as the contract representing the generic provenance layer. Read-functions are publicly accessible since these functions do not alter the state of the contract.

\begin{lstlisting}[caption={Storage Contract}, label=lst:provenance-records, float]
contract Storage {
struct ProvenanceRecord {
    uint tokenId;
    uint[] inputProvenanceIds;
    string context;
    uint index;
}
mapping (uint -> ProvenanceRecord) records;
uint[] provenanceIndex;

function getProvenance(uint provId)
public view returns (uint tokenId, ...) {...}
...
function createProvenance(uint provId, ...)
internal returns (uint index) {...}
...
}
\end{lstlisting}

\subsection{Generic Provenance Contract}
As mentioned above, the generic provenance layer augments the storage layer by generic provenance functionality. The contract implementing this layer is primarily responsible for managing the ownership of data points and associating data points to their respective provenance records. As described in \cref{sec:generic-provenance-layer}, our framework uses tokens to represent data points. Consequently, ownership of tokens determines ownership of data points. Data points represent non-fungible assets. As such, the contract implements the Ethereum standard ERC721 which defines a common interface for non-fungible assets, for instance, functions for transferring ownership. This has the advantage that our tokens can be traded by any clients implementing this standard, such as wallets or exchanges. The generic provenance contract complies to the standard by inheriting from an existing ERC721 implementation provided by OpenZeppelin\footnote{\url{https://openzeppelin.org/}}.

\Cref{lst:associated-provenance} displays an outline of the contract and demonstrates the general workflow for creating new provenance records. First, the contract verifies that a given token (i.e., data point) exists~(Line~7) and that the token belongs to the sender of the message~(Line~8). After validating the input provenance records~(Line~9), the contract creates a new provenance ID~(Line~11), adds it to the list of associated provenance~(Line~12), and calls the storage contract's \textit{createProvenance} function~(Line~13). Note that the \textit{createProvenance} function of the generic contract is again internal, and can thus not be accessed publicly. This enables specific provenance contracts which implement concrete use cases to further adapt the functionality according to their needs.

\begin{lstlisting}[caption={Generic Provenance Contract}, label={lst:associated-provenance}, float]
contract GenericProvenance is ERC721, Storage {
...
mapping (uint => uint[]) internal associatedProv;
...
function createProvenance(uint tokenId, ...)
internal returns (uint index) {
    require(exists(tokenId));
    require(ownerOf(tokenId) == msg.sender);
    checkValidProvenance(inputProvenance);

    uint provId = getProvId();
    addAssociatedProvenance(tokenId, provId);
    return super.createProvenance(provId, ...);
}
...
\end{lstlisting}

\subsection{Specific Provenance Contracts}
\label{sec:implementation-specific}
As briefly mentioned in \cref{sec:specific-provenance-layer}, the contracts of the specific provenance layer adapt the behaviour provided by the generic provenance layer to reflect the requirements of specific provenance use cases, i.e., by customising the provenance model, and by certain access control mechanisms.

The provenance model can be customised by defining the contents of the \textit{context} parameter, so that it presents the provenance information needed for a specific provenance scenario. For instance, in the use case of vaccine supply chains (see Section~\ref{sec:usecase1}), the context should contain temperature and location information about individual vaccines. Hence, a specific contract could define its own \textit{createProvenance} function that requires parameters like \textit{temperature}, and \textit{location} which are then combined to form the \textit{context} to be passed on to the \textit{createProvenance} function of the generic provenance contract.

Further, access control happens on two levels. First, a specific contract defines which parts of the generic provenance layer's API are exposed. For instance, even though the generic provenance layer permits updating or deleting (i.e., invalidating) provenance records, this can be unwanted behaviour in the specific use case at hand. In this case, the contract in the specific provenance layer implementing the use case  simply ``hides'' the functionality, i.e., does not expose it publicly.

Second, access control is relevant for controlling the ownership of data points as defined in~\cref{sec:generic-provenance-layer}. Since data point ownership is the decisive factor with regard to who can create provenance records for which particular data points, contracts in the specific provenance layer are responsible for actually assigning ownership, i.e., they define which clients become the owners of which data points, or rather in the notion of tokens, which tokens get assigned to which clients. For simplicity, our prototype automatically assigns new tokens to requesting clients. However, ultimately, the most suitable approach is dictated by the specific use case at hand. Two possible alternative strategies for assigning ownership are listed below:

\begin{itemize}[leftmargin=*]
	\item One possibility is for clients to purchase tokens. This has the advantage that the framework is publicly available without the risk of spamming attacks since the acquisition of tokens incurs financial cost.
	Essentially, the token acquisition costs need to be low enough for honest users to be willing and able to participate, but high enough to discourage spammers. Of course, such an approach cannot prevent malicious actors with sufficient purchasing power.
	\item In another approach, the layer manages a white list of authorised clients allowed to request new tokens. This way, the list controls exactly who participates in the provenance system. However, the question arises who is responsible for managing the white list of authorised clients.

\end{itemize}

redpajama_set_name: RedPajamaArXiv


text:
Stephen Jacob Williams (born June 29, 1986) is an American football wide receiver who is currently a free agent. He was signed by the Arizona Cardinals as an undrafted free agent in 2010.

College career
He played college football at Toledo, where he set several major team receiving records.

Professional career

Arizona Cardinals
He signed with the Arizona Cardinals as an undrafted free agent in 2010.

Seattle Seahawks
On January 25, 2013, Williams signed with the Seattle Seahawks. He was released by the Seahawks on October 5, 2013, to make room for Bruce Irvin, who finished serving a four-game suspension for performance-enhancing drug use.

Jacksonville Jaguars
On October 7, 2013, Williams was claimed off waivers by the Jacksonville Jaguars.

He was placed on injured reserve on November 23.

He was released on May 12, 2014.

Miami Dolphins
Williams signed with the Miami Dolphins on May 15, 2014.

References

External links
Official Website
Arizona Cardinals bio
Toledo Rockets bio

1986 births
Living people
Players of American football from Houston
American football wide receivers
Toledo Rockets football players
Arizona Cardinals players
Seattle Seahawks players
Jacksonville Jaguars players
Miami Dolphins players

redpajama_set_name: RedPajamaWikipedia


text:
Home > Sport > Boxers
196.2 cm (6 ft 5.2 in)
86 cm (34 in)
Biceps size
Compare your height to Wladimir Klitschko
Wladimir Klitschko is 196.2 cm (6 ft 5.2 in) tall
The difference in height is 196.2 cm or 6 ft 5.2 inches
Who is Wladimir Klitschko?
Wladimir Klitschko is an outstanding and remarkable retired professional boxer that has built up a reputation as a two-time heavyweight world champion.
His career kicked off in 1996 as he fought against Mexican boxer, Fabian Meza, in Germany.
Wladimir has attained much recognition throughout his boxing career for losing only 5 matches as well as setting 3 world records.
Wladimir is straight. Judging from his relationship history, he seems to have a particular preference for celebrities like himself. In the past, he has been romantically linked with icons such as Yvonne Catterfeld, Diana Kovalchuk, Karolina Kurkova and Alena Gerber.
He has been in a committed long-term relationship with American actress Hayden Panettiere up till their split in 2018.
His parents are Wladimir Rodionovich Klitschko and Nadezhda Ulyanovna.
His brother Vitali Klitschko has been exposed to fame for many decades as he was first a professional boxer and now is the Mayor of Kyiv, Ukraine.
As a result of his current relationship with Hayden, he has a daughter named Kaya.
Wladimir Klitschko is definitely a Christian. He christened his daughter in Kyiv Pechersk Lavra in Ukraine.
Academically, Wladimir has attained the highest height as he is currently a PhD holder.
He fluently speaks 4 languages - English, Russian, Ukrainian and German.
He officially retired from boxing in August 2017.
Nikolai Valuev
Jack O'Halloran
Floyd Mayweather Sr.
Floyd Mayweather Jr.
Share your thoughts about Wladimir Klitschko
Suggest a Wladimir Klitschko Update

redpajama_set_name: RedPajamaCommonCrawl


Paul is the Head of Information Technology at Toowoomba Grammar School. He has been a full-time teacher of Information Technology (IT), and a myriad of other subjects, for over 25 years. Paul holds a Bachelor of Information Technology, a Master of Educational Leadership specialising in Information Technology. He is also a Microsoft Innovative Education Expert and a Google Education Certified Trainer.
Paul has engaged heavily in cloud-based technology since its emergence, having quickly identified the collaborative possibilities, creative freedom and portability that it allowed both his students and colleagues to explore. Teachers and students at Toowoomba Grammar School utilise a hybrid model of both Microsoft and Google tools.
A BYOD program was rolled out in 2015, but as of 2019, Toowoomba Grammar School has chosen to return to a School supplied model commencing for students from Year 4 to Year 9. The timeline, strategies, and justification for this change in direction will be discussed.
Paul has been working with his co-presenter Brett Sawyer (Head of e-Learning at Toowoomba Grammar School) since the beginning of 2014. They look forward to sharing their experiences, and those of their colleagues and School, with you at the National Future Schools Expo 2019.
The story of a school who implemented BYOD... and then removed it!


text:
Class of 2020 Nostalgia Playlist
Jerry Huang '23 Staff Writer
To the seniors, thank you for your immense contributions to our community. Although your time was cut short, your Deerfield spirit is something that I hope will remain with you forever. Here are some of the songs that defined your most memorable moments.
Mr. Brightside — The Killers
Christina Halloran recalls this song because it "plays at every dance and everyone always sings along."
Maniac — Conan Gray
Liv Mikesell chooses this song as she remembers "this song echoing through the walls of the rink at the boys' hockey games this winter."
Ethan Chen relives "screaming bah bah bah at the top of my lungs in the dorm."
One Kiss — Dua Lipa and Calvin Harris
This song reminds Alton Machen of the hockey season.
She Used To Be Mine — Sarah Bareilles
Izzy Hamlen shared a sweet memory: "The night before graduation, sophomore year, my friend Lara and I pulled an all-nighter, surprised our proctors and everything, and at 5:30 AM, when Mather's doors unlocked, we went on a walk around campus and played this song at the river while reminiscing and talking about how we wanted to be proctors… Senior year, when we became proctors in Mather, we promised each other that on our night of graduation, we'd pull an all-nighter and go to the same spot at the river and listen to this song again— it was supposed to be our final farewell together like we were coming full circle. I could not have gotten through Deerfield without Lara and wish I could've thanked her in person; but I know that once this all blows over, we'll go back to that spot and do what we planned."
Any song by the band AJR
Adam Sussbauer chooses this because "it's literally the only thing that David Chen would ever play."
Bad and Boujee — Migos ft. Lil Uzi Vert
Henry Renelus remembers this song from Risky Business 2017.
The Box — Roddy Rich
"I heard The Box for the first time in Alex Kirley's room and I remember thinking it went super hard. It later became the song on the ski team that we'd listen to before races to ski faster." – Sam Laur
"The swim bus reminds me of 'The Box'" – Maggie Tydings
Hot Shower — Chance the Rapper ft. MadeinTYO & DaBaby
Stuart Grow likes this song because of its contrast to "the cold water-only showers in the dorms."
Hold My Liquor — Kanye West
"During the fall when I was in Barton, this was the song I set for my alarm tone on my phone. So whenever I needed to wake up at 3 AM to finish my homework, this would be the song that woke me up. This past autumn was the most fun I've ever had at school, and I will hold on to the memories from those days forever." – YDD Salmassi
Lover (Remix) — Taylor Swift ft. Shawn Mendes
Nikita Pelletier shares, "There's always one song every once in a while that I listen to and never stop listening to and this past year it was definitely this one. I played it so many times that most of my friends got sick of it, but whenever I hear it, I think of nights walking back from the library with Saads playing it on my speaker, or walking to swim practice with Izzy, or when Mina Liang came to visit and me, Izzy, and Allison Xia just sat in her parked car blasting it. It always made me feel calm when I was stressed. In general, it just makes me think of all of the people I love at Deerfield and all the people that love me and the beautiful moments that made us who we are."
Build Me Up Buttercup — The Foundations
Victoria Patterson chooses this song because "The DAGXC team would play this song every Thursday afternoon while driving back from our river run in Vermont!"
I Lived — OneRepublic
Looks like David Chen listens to something other than AJR. @Adam Sussbauer
Tequila — The Champs
"Fireball with the boys," says Mason Zhao.
Say So — Doja Cat
Natasha Leong '21
Maggie Tydings says a lot of TikTok songs remind her of Deerfield, either watching or making TikToks with her friends. "Music, especially this song, reminds me of my beloved time at Deerfield because so many of the memories that I made were made with music. Whether it was making TikToks or dancing in the squash courts, my best spent time was spent with music!"
Senior year is always the most memorable year of high school. Even though we may not be able to celebrate one last time together this year, hopefully, these songs can remind you of some of the most meaningful times you had at Deerfield.


text:
Senators, don't let Congress hurt our children
It is difficult to believe, but the Senate is about to pass a health bill that will seriously harm America's children.
Senators, don't let Congress hurt our children It is difficult to believe, but the Senate is about to pass a health bill that will seriously harm America's children. Check out this story on commercialappeal.com: http://memne.ws/2svJu1D
Guest Columnist Published 6:00 a.m. CT June 15, 2017 | Updated 9:57 a.m. CT June 15, 2017
Gary Shorb(Photo: Brandon Dill, The Commercial Appeal)Buy Photo
Parents of sick children, pediatricians and children's advocates across the nation are looking to Tennessee Sens. Lamar Alexander and Bob Corker, in their leadership positions, to save the day.
Those of us working on behalf of Memphis' children's add our plea to theirs.
The American Health Care Act is being sold as a repeal of Obamacare. But the House of Representatives added another, bigger piece to the bill. They added massive cuts from Medicaid, the nation's health-care safety net.
The Medicaid cuts haven't gotten as much attention as the repeal, but they should. They will touch most Americans, whether they have Medicaid coverage or not, and they will deal a blow to our efforts to improve the lives of Memphis' children.
The AHCA is expected to take $834 billion out of Medicaid over the next decade, which will mean an average yearly cut of $500 million in Tennessee.
That is nearly twice what will be raised by the state's new gas tax. It will affect vulnerable Tennesseans of all ages.
Medicaid pays for nearly two thirds of elderly nursing home patients' care, for example, and is a primary source of coverage for adults with severe disabilities.
But no one will feel the cuts more than children, because no one counts more on Medicaid. The program covers half of the state's births, and half of Tennessee's children.
Children in rural communities rely on Medicaid even more than kids in cities and suburbs, but the program is still crucially important in Memphis.
Medicaid has been vital to recent successes in reducing Memphis' infant mortality rate, and we are depending on Medicaid to save more babies' lives in the future.
Medicaid funding supports school health programs vital to prevention. Medicaid helps combat diabetes, addiction and other chronic conditions that cloud so many children's futures. These cuts will affect the whole community.
Nearly three fourths of LeBonheur Children's Hospital admissions are covered by Medicaid. Medicaid covers two of every five children treated at St. Jude's.
The AHCA will make it difficult for children's hospitals to maintain services for the sickest of children. And in rural areas, the cuts will close many local hospitals, diminishing access to care for all of the children in those communities, whether or not they are covered by Medicaid.
The AHCA will affect children in other ways. With federal Medicaid funding accounting for twenty cents of every dollar in the state budget, it will be impossible for health care to absorb all of the loss. K-12 education will likely take a hit, along with higher education.
Child Protective Services relies on Medicaid funding, which means that efforts to curb child abuse and neglect will suffer.
How has such a damaging and widely disliked bill come so close to passage? Partly, it is because the Senate has been drafting it with very little public input or transparency, and no one knows exactly how the House bill has been changed.
Most importantly, I find that many people are simply in denial: "Surely Congress wouldn't enact something that would harm children."
Congress probably doesn't realize the harm it is about to inflict, but neither they nor we can blind ourselves to reality. Which is why I ask you, Sens. Alexander and Corker, to protect our kids. Please say no to the ACHA.
Gary Shorb is executive director of Urban Child Institute.
Read or Share this story: http://memne.ws/2svJu1D


"Your Source for Entertainment from America's Courts"
In 21st Century America, it is virtually impossible to avoid news and entertainment about courts and lawyers. Cable news personalities engage in televised mortal combat over celebrity trials. Although their antics are sometimes salaciously interesting, you rarely learn anything about the law, and—if you do—it's often misleading or simply a bizarre legal anomaly.
On the other hand, you could always pick up a scholarly law review. You can learn a lot about the law, and it's almost always correct. However, often times, you might as well be reading ancient Egyptian hieroglyphics, and—even if you can understand it—it's often so mind-numbingly boring you wonder why anyone would risk becoming addicted to sleeping pills when merely borrowing a book from your local law library would do the trick.
That's why we bring you Courtweek.
The origins for Courtweek come from a column David Horrigan wrote while at The National Law Journal and pieces he wrote for the Washington Examiner. The National Law Journal column, On Trial, was buried at page B-9 of the NLJ, but for those who could find it, it studied a significant legal issue each week--and did it in a way that tried not to be boring.
With litigants such as Dave the Dwarf, Mister Softee, and the Fatty Shack, On Trial took the Due Process Clause of the Fifth Amendment, the Equal Protection Clause of the 14th Amendment, the Lanham Act, Virginia drug paraphernalia laws,and other important jurisprudence, bringing them to life for enjoyable reading in a way only Dave the Dwarf, Mister Softee, and the Fatty Shack could do.
We hope to continue that proud tradition at Courtweek. We wish you an enjoyable read each time you visit. It'll be an added bonus if you learn something you didn't know about the law, and maybe even have a good laugh while doing it.
We search courts across the nation for good cases, but if you know of a good one—even if you're a lawyer engaging in the shameless promotion of your own trial victory—we would appreciate hearing from you.
Copyright 2011 courtweek.com. All rights reserved.


The hot water systems are in high demand in residential, commercial and industrial sectors. The water heaters are the most important items of daily need. You may need hot water for warm showers, laundry, washing dishes and other household chores….


• All products are sold at Full Price. There are no promotions or discounts during launch month.
• At 4 pm, the secret link will be updated on this page.
• There is no purchase/quantity limit for new products.
• Please check your emails (including spam and junk folders) for any updates.
• Delivery fees are non-refundable and orders cannot be combined.


text:
Q: How to export an html table as a PDF or image? I am working on creating a website which will allow users to update a table using Javascript.
What I am looking for is a way to allow the user to export the table as an image (jpg, png etc.) or a PDF once it has been modified.
If there is a similar thread or topic please let me know, I don't really know where to start here. If you can recommend background reading that would be great too.

A: This is not something that can really be done client side (without installing software on the clients, of course).  You will need to generate this PDF server-side.
How you do that depends on the language and platform you are using.

A: There are a couple open source PDF librarys you can use;
SharPDF, PDFClown, iTextSharp  just to name a few...

redpajama_set_name: RedPajamaStackExchange


text:
Spinisternum castaneipictus är en insektsart som beskrevs av Willemse, C. 1966. Spinisternum castaneipictus ingår i släktet Spinisternum och familjen vårtbitare. Inga underarter finns listade i Catalogue of Life.

Källor

Vårtbitare
castaneipictus


Fingerhut started back in 1948. Since then they have helped millions of people buy everything from furniture and bedding to jewelry to the latest electronics, all with affordable low monthly payments. Fingerhut offers you a great way to give your family the basics, but also make those birthdays and holidays extra special.
Fingerhut offers more than 165,000 products including the brand names you want like Samsung, Dyson, Skechers, KitchenAid and more. You'll find your favorite electronics, jewelry, shoes, furniture and decor items. Get what you need for your kitchen, living room, bed or bath, and find great gifts for your family.
Fingerhut offers the credit you need to buy the stuff you want for your family and they make it easy to apply. With NO annual fees, membership fees or over-limit fees, the only extras are the interest you may accrue on your account and any late fees the may be charged if your bills are not paid on time, and/or any return payment fees.
Fingerhut Credit can be used to buy more than 165,000 products on fingerhut.com, the Fingerhut catalog and over the phone. You may also use your Fingerhut Credit to make purchases with select Fingerhut partners. You will receive offers from these partners from time to time. These include online florists, insurance companies and others.
Apply for Credit and get low monthly payments on top brands from Fingerhut's catalog of over 200,000 items! Online shopping that fits any budget for electronics, furniture, jewelry, bedding, and much more!


text:
Q: The n mode on "iwlist wlan0 scan" I know how to determine if scanned AP uses B or G mode, but how to know (using "iwlist wlan0 scan") it uses N protocol ?
if I use "iw dev wlan0 scan" and see if the cell has a "HT capabilities" block.
OK. "iw dev wlan scan" partially works, but i can not get data about the signal quality,  Channel mode (is it master or ad hoc) and security options.
I need to find all security algorithm options in one command.
Is there other options? like third party commands?
Any source code hack suggestions?

A: No tool other than iw can give you more information. iw already gives all information that the network driver gives. If some information is missing, update your network driver (that mean your kernel) and/or iw.
An example of an up-to-date iw output:
BSS 42:42:42:42:42:42 (on w0)
    TSF: 4922636642679 usec (56d, 23:23:56)
    freq: 2437
    beacon interval: 102
    capability: ESS ShortPreamble ShortSlotTime (0x0421)
    signal: -80.00 dBm
    last seen: 600 ms ago
    Information elements from Probe Response frame:
    SSID: bestSSIDevar
    Supported rates: 1.0* 2.0* 5.5* 6.0 9.0 11.0* 12.0 18.0
    DS Parameter set: channel 6
    TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
    ERP: <no flags>
    Extended supported rates: 24.0 36.0 48.0 54.0

To get signal quality, just look at the signal: line.
The type of BSS is given in the capability: line: ESS mean this is an part of a larger network (so it's AP mode), IBSS means the network is independent, so it's ad-hoc mode.
Security options are one complex beast, given in several Information Elements.
If you see Privacy in capabilities, the network is protected somehow. If you see an RSN information element, then ... the network is protected via the Robust Security Network families of protocols, more know informally as WPA2. If you see an WPA information element, then, it's WPA1. If you see no RSN or WPA information elements but there is Privacy, then it's ye old WEP.
Here is a snipped of a network supporting both WPA and RSN with both CCMP and TKIP (but only TKIP for group) and using IEEE 802.1X (not PSK):
BSS 46:46:46:46:46:46 (on w0)
    TSF: 4923527793080 usec (56d, 23:38:47)
    freq: 2412
    beacon interval: 102
    capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
    signal: -59.00 dBm
    last seen: 872 ms ago
    Information elements from Probe Response frame:
    SSID: bestest
    Supported rates: 1.0* 2.0* 5.5* 6.0 9.0 11.0* 12.0 18.0
    DS Parameter set: channel 1
    TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
    ERP: <no flags>
    RSN:     * Version: 1
             * Group cipher: TKIP
             * Pairwise ciphers: TKIP CCMP
             * Authentication suites: IEEE 802.1X
             * Capabilities: 4-PTKSA-RC 4-GTKSA-RC (0x0028)
    Extended supported rates: 24.0 36.0 48.0 54.0
    WPA:     * Version: 1
             * Group cipher: TKIP
             * Pairwise ciphers: TKIP
             * Authentication suites: IEEE 802.1X
             * Capabilities: (0x0000)


To find hotels near Chesterfield Inlet airport, paste in search form the name of the city of (Chesterfield Inlet), then select the dates of Check In and Check Out, select the number of guests and click Search.
YCS airport Chesterfield Inlet transcript or YCS which airport?
The name of the airport: Chesterfield Inlet. The airport is located in the country: Canada. The city location of the airport in Chesterfield Inlet. IATA airport code Chesterfield Inlet: YCS. The IATA airport code is a 3 letter unique identifier, assigned airports world International air transport Association (IATA). ICAO airport code Chesterfield Inlet: CYCS. The ICAO airport code is a 4 letter unique identifier that is assigned to the airports by the International civil aviation organization (ICAO).
The geographic coordinates of the airport Chesterfield Inlet.
The latitude at which the airport is located: 63.345833000000, the longitude of airport: -90.727500000000. Geographic coordinates of latitude and longitude define the position of the airport on the earth's surface. To fully define the position of the airport in three-dimensional space, we should also know the third coordinate is the height. The height of the airport above sea level is 12 meters. The airport is located in the time zone: +6.0 GMT. The airline always indicates local time of departure and arrival airport according to the time zones.


According to a new report from TMZ Sports, Jim "The Anvil" Neidhart's wife told investigators that he was having difficulty sleeping on Sunday night and got out of bed in order to change the thermostat in the house. We're told he reportedly wanted to turn the air conditioner on as it was too hot. According to the police report, Elizabeth Neidhart said when Jim went to touch the thermostat, he "turned weirdly as if he were about to dance," then fell toward the wall and ground where he hit his head.
Elizabeth then called 911 believing he was having a seizure, which he took medication for. His last seizure took place back in December of 2017 and doctors believed that he may have also had Alzheimer's. When EMT's arrived on scene, Neidhart was found on the floor with a four-inch gash and blood on his face. He was pronounced dead a short time later.
It should be noted that investigators found medication at the home, but none of it appears to have been abused.
Jim "The Anvil" Neidhart's wife told emergency personnel the ex-WWE superstar collapsed while appearing to have a seizure early Monday morning … and slammed his head when he fell to the ground.
"He then fell towards the wall and ground," the investigation report says.
Neidhart's wife says Jim's last seizure was Dec. 2017 — and she notes doctors also believed he may have had Alzheimer's as well.
When officials arrived to Jim's home — they found the 63-year-old on the floor with a 4-inch gash on his face.
On behalf of everyone here on eWrestlingNews.com, we send our condolences to Natalya and the family and friends of Jim "The Anvil" Neidhart. R.I.P.
Is It Ever Appropriate To Integrate Real-Life Scenarios Into Storyline?