[nobreak=true,outerlinewidth=1,backgroundcolor=yellow!50,
outerlinecolor=black,innertopmargin=0pt,splittopskip=skipbelow=skipabove=ntheorem,roundcorner=5pt,font=]resultResult
[nobreak=true,outerlinewidth=1,backgroundcolor=yellow!50,
outerlinecolor=black,innertopmargin=0pt,splittopskip=skipbelow=skipabove=ntheorem,roundcorner=5pt,font=]theoremTheorem
[nobreak=true,outerlinewidth=1,backgroundcolor=gray!10,
outerlinecolor=black,innertopmargin=0pt,splittopskip=skipbelow=skipabove=ntheorem,roundcorner=5pt,font=]remarkRemark
[nobreak=true,outerlinewidth=1,backgroundcolor=pink!30,
outerlinecolor=black,innertopmargin=0pt,splittopskip=skipbelow=skipabove=ntheorem,roundcorner=5pt,font=]quaestioQuaestio
[nobreak=true,outerlinewidth=1,backgroundcolor=yellow!50,
outerlinecolor=black,innertopmargin=5pt,splittopskip=skipbelow=skipabove=ntheorem,roundcorner=5pt,font=]backgroundBackground

#  The Probability Conflation: A Reply

Nassim Nicholas Taleb1, Ronald Richman2, Marcos Carreira3, James Sharpe4
Corresponding author: N N Taleb<EMAIL_ADDRESS>We thank Fergal McGovern and
participants in the webinar Global Uncertainty Reading Group (formerly Global
Technical Incerto Reading Group) special meeting on Dec 2, 2022. We also thank
Pasquale Cirillo, Sara Lapsley, Brandon Yarckin and Mark Spitznagel. 1Tandon
School of Engineering, New York University and Universa Investments 2Old
Mutual Insure and University of Witwatersrand 3Ecole Polytechnique 4Sharpe
Actuarial Limited
Forthcoming, International Journal of Forecasting, 2023

###### Abstract

We respond to Tetlock et al. (2022) showing 1) how expert judgment fails to
reflect tail risk, 2) the lack of compatibility between forecasting
tournaments and tail risk assessment methods (such as extreme value
theory).More importantly, we communicate a new result showing a greater gap
between the properties of tail expectation and those of the corresponding
probability.

##  I The Fat Tails Problem

Tetlock et al. (2022) [1], in their criticism of claims by a paper titled ”On
single point forecasts for fat-tailed variables” in this journal (Taleb et
al., 2022 [2]) insist that discriminating between a binary probability and a
continuous distribution is a false dichotomy, that binary probabilities
derived from expert forecasting tournaments can provide information on tail
risk, in addition to some claims about a collaboration with the first author
and a ”challenge”.

We apologize for not answering most of their points as these are already amply
covered in two papers in this very journal, which includes the one they are
criticizing, [2] and the more formal [3]. Alas ”probability” is a mathematical
concept that does not easily accommodate verbal discussions and requires a
formal treatment, which necessitates precise definitions.

At the gist of what we referred to as ”the so-called masquerade problem” is
the following conflation, we simplify from [3] using a continuous distribution
for ease of exposition:

Let $K\in\mathbb{R}^{+}$ be a threshold, $f(.)$ a density function for a
random variable $X\in\mathbb{R}^{+}$ , $P_{K}=\mathbb{P}(X>K)\in[0,1]$ the
probability of exceeding it, and $g(x)$: $\mathbb{R}^{+}\to\mathbb{R}$, an
impact function. Let $G_{K}$ be a partial expectation of $g(.)$ for the
function of realizations of $X$ above $K$:

$G_{K}=\int_{K}^{\infty}g(x)f(x)\,\mathrm{d}x,$

and for clarity lets write the survival function (that is, the complementary
cumulative distribution function, CDF) at $K$:

$P_{K}=\int_{K}^{\infty}f(x)\,dx$

Figure 1: The inverse survival function (complementary quantile function)
corresponding to a complementary CDF ($P_{K}$) is unbounded while the
complementary CDF is bounded; it is extremely concave for tail probabilities,
and compounds the estimation errors on $p$. Simply the transformation reverses
the signs of the second derivative and compounds it. We show how errors on
$P_{K}$ translate in larger and larger values for $K$, possibly infinite.

The error comes from conflating the properties of $G_{K}$ which those of
$P_{K}$, often associating $P_{K}$ with some constant representing the
presumed impact associated with the threshold $K$.

The intuition of the difference can be shown as follows: assuming $g(x)=x$,
for $X$ a random variable with finite first moment, we have, focusing on the
positive domain, generalizing the Tail Probability Expectation Formula,

$G_{K}=\underbrace{K\;P_{K}}_{\text{Prob times impact at
threshold}}+\underbrace{\int_{K}^{\infty}P_{x}\;dx}_{\text{additional term}},$
(1)

with a second term that can dominate the first, particularly under heavy
tailed distributions.

As explained in the two referenced papers, $P_{K}$ as a random variable, being
bounded between $0$ and $1$, necessarily has thin tails, with finite mean,
variance, and all moments. By the probability integral transform, its
unconditional probability distribution is the Uniform $\mathcal{U}(0,1)$ –and
its conditional is usually treated, particularly in the Bayesian literature,
as a Beta (a special case of which is the Uniform) –the Beta distribution can
accommodate practically all shapes of double bounded unimodal distributions. A
sum of such bets becomes rapidly Gaussian. [Moments] $P_{K}$ corresponds to
the zeroeth moment and is always thin-tailed. $G_{K}$ maps to higher moments,
and up to the infinite moment (i.e. the extremum) dealt with in extreme value
theory.111Consider the expectation of the $p^{th}$ moment
$\mathbbm{E}(x^{p})$. $P_{K}$ corresponds to $p=0$ and the expected maximum to
$\lim_{p\to\infty}\mathbbm{E}(x^{p})$. In general, risk management concerns
extrema, another point of divergence with Tetlock et al.

As discussed extensively in Taleb (1997) reflecting the author’s experiences
as a derivatives market-maker [4], one fails to ”hedge” the other in practice
(and, of course, in theory). For instance, a rise in skewness of the
distribution will tend to increase one side ($G_{K}$) while decreasing the
other ($P_{K}$): simply, the number of realizations above $K$ drops, but their
impact becomes larger.222Tetlock et al states that Taleb and Tetlock (2013)
claims that the two methods are ”complementary”. Our understanding of the
latter paper is that says the exact opposite: there is no such complementarity
fat tailed variables, which is what this discussion about ”masquerade” is
about. This is the reason why the first author (Taleb) refused to be involved
in the IARPA forecasting exercise.

And if one does not hedge the other, then being ”good at predicting $P_{K}$”
provides no information on $G_{K}$.

[Probability Classes] If $P_{K}$ and $G_{K}$ are not in the same probability
class, that is, while $P_{K}$ is always thin tailed, if $G_{K}$ is not thin-
tailed, then one cannot be a practical proxy for the other.

The field of extreme value theory was designed to deal with the issue.
Basically, ”probability” is not a tangible object like a tomato; it is,
mathematically, a kernel inside an integral (or a summation), inseparable from
other integrands, and one should avoid drowning it with verbalism. This point
applies no matter the probability interpretation (Bayesian, frequentist,
propensional, or subjectivist). Furthermore, science is not about precise
measurements of exceedance probability, but understanding properties in a
comprehensive and useful ways. As explained in the paper criticized by Tetlock
et al (2022), one does not handle pandemics via forecasting tournaments and
reliance on champions for single point forecasts, but by getting full
distributional properties, particularly the shape in the tails. Decisions must
be informed by the shape of the total distribution, and some understanding of
the dynamics involved in generating such a distribution (multiplicative
effects cause thick tails while additive ones tend to be benign stochastic
outcomes).

Just as warning is not predicting, understanding distribution classes and tail
properties is not forecasting. Furthermore, the language of ”false positive”,
while useful in medicine and similar applications based on signal, in not
useful in risk and insurance based on distributional considerations.

[Gambling] It is worth noting that binary options on financial instruments
(that is, the trading of $P_{K}$ or $1-P_{K}$) proved of little economic value
and are not considered an investment in the U.S. and the European Union; they
are banned by most corresponding regulators, as they are considered gambling
devices. The European Securities and Markets Authority (ESMA) have disallowed
retail dealing with binary options. These binaries were also traded at Lloyds,
until banned by U.K. legislation with the 1909 Marine Insurance Act.

Note on ”dichotomies”: Tetlock et al (2022) seem to mix the ”dichotomy”
between binary and full payoffs with another distinction, that probability
estimates help to flag tail risk. Our representation can accommodate both with
the function $g(.)$ which as mentioned earlier can reflect the infinite
moment, i.e. the extremum.

##  II A New Result

At the Global Uncertainty Reading Group discussion around Tetlock et al
(2022), on Dec 1, 2022, a new useful result emerged, which we find worth
communicating333This result can be useful in financial risk management,
particulaly the mapping between ”VaR” (Value at Risk, maps to $K$ for a set
probability $P_{K}$ of losses above that threshold) and expected shortfall,
”CVaR” (maps to $G_{K}$, that is, includes the impact of losses)..

[Events are not defined] A well known problem with heavy tails is that, at the
core, in that class of distributions, ”events” are not defined verbally: a
”war” can have 200 or a million casualties, so it does not have a quantitative
meaning. But setting a precise threshold no longer maps to a precise
probability under an error rate, and, vice versa.

As illustrated in Fig. 1, The error in the evaluation of the probability
$P_{K}$ can translate into an explosive value for the corresponding $K$, and
the more fat tailed the distribution, the more explosive such corresponding
value.

There is no space for a general proof, so we shall provide one for any
distribution that ends (for large values) with Paretan tails, which is the
standard case. Let us assume the probability $P_{K}$ follows a Beta
Distribution $\beta(a,b)$ (both parameters $>0$ and as we mentioned this fits
the unconditional uniform with $a=b=1$).

$f_{P_{K}}(p)=\frac{p^{a-1}(1-p)^{b-1}}{B(a,b)},$

$0<p<1$, where $(B.,.)$ is the standard Beta function.

The mean and variance will be $M_{P_{K}}=\frac{a}{a+b}$,
$V_{P_{K}}=\frac{ab}{(a+b)^{2}(a+b+1)}$.

Now assume the underlying distribution for $X$ where $X>K$, lies in the strong
Pareto basin, meaning $P(X>K)=L^{\alpha}K^{-\alpha}$, where $\alpha$ is the
tail index an $L$ a scaling constant –this is general for large values of $X$
under all fat-tailed distributions.

The inverse complementary CDF (quantile function) can be expressed as:
$K=L\left(P_{K}\right)^{-1/\alpha}\text{ if }0\leq P_{K}\leq 1$.

If probability taken as a random variable $P_{K}$, that is, $1-CDF$ (the
cumulative distribution function), follows a Beta distribution $\beta(a,b)$,
then $K$, the inverse complementary CDF has for density:

$f_{K}(k)=\frac{\alpha\,K^{-a\alpha-1}L^{a\alpha}\left(1-K^{-\alpha}L^{\alpha}\right)^{b-1}}{B(a,b)},$
(2)

with mean

$M_{K}=\frac{L\,\Gamma\left(a-\frac{1}{\alpha}\right)\Gamma(a+b)}{\Gamma(a)\Gamma\left(a+b-\frac{1}{\alpha}\right)},$

and variance

$V_{K}=\frac{L^{2}\,\Gamma(a+b)\left(\frac{\Gamma(a)\Gamma\left(a-\frac{2}{\alpha}\right)}{\Gamma\left(a+b-\frac{2}{\alpha}\right)}-\frac{\Gamma\left(a-\frac{1}{\alpha}\right)^{2}\Gamma(a+b)}{\Gamma\left(a+b-\frac{1}{\alpha}\right)^{2}}\right)}{\Gamma(a)^{2}}.$

The proof is done via the standard Jacobian Method for the transformation of
probability distributions.

As we can see the first moment exists only if $\alpha>\frac{1}{a}$ and
$\alpha>\frac{1}{a+b}$; the second moment exists only if $\alpha>\frac{2}{a}$
and $\alpha>\frac{2}{a+b}$; more generally the $n^{th}$ moment exists only if
$\alpha>\frac{n}{a}$ and $\alpha>\frac{n}{a+b}$.

[Error Propagation] While the error on the probability can be small and
controlled, the error on the corresponding quantity under consideration can be
infinite.

We note that the tail index $\alpha$ for pandemics (as addressed at length in
the paper criticized by Tetlock et al. (2022)) is well below $1$. The same
applies to wars, which means that when it comes to conflicts, forecasts for
tail events are not compatible with probability theory.

##  III A Rather Unscientific ”Challenge”

> ”We challenge Taleb et al. (2022) to be equally transparent about the
> performance of their tail-risk hedging strategies —-a controversial topic
> (Brown, 2020).”

We are surprised to see such a remark coming from professional evidence-based
researchers: requesting the single track record of a tail hedging program as a
back-up for a claim about the mathematical inadequacy of using a binary
forecast for, say, Covid 19 or similar events under fat tailed distributions.
Said tail-hedging strategy consists in capturing the difference between
idiosyncratically selected option prices in the market and subsequent market
jumps. (Incidentally Professor Tetlock has appeared to conflate tail events
–which take place in the tails of any distribution – and the fat-tailedness
attributes of statistical distributions). And, on top, such request is made to
the author of an entire book, Fooled by Randomness about the futility of such
claims. To repeat the famous disparagement by the economist Jagdish Bhagwati
of the claim by the speculator George Soros that he ”falsified the random
walk” [5], we find it highly unscientific to use a single track record to make
any general claim – this bizarre demand on the part of professional
researchers is no different from anecdotal claims ($n=1$) used by medical
charlatans. In addition, trading records are not like points in soccer games,
particularly when they can hide tail risks.444Since Tetlock et al (2022) is
uncritically citing a web opinion article by Aaron Brown, we would like to
debunk the claim in it that the performance record is not available: not being
a retail product, it has been continuously available to what the Security and
Exchange Commission (S.E.C.) defines as qualified investors, not Twitter
activists, and Mr. Brown (who by his own disclosure had a severe conflict of
interest) violated, willingly or unwillingly journalistic standards. For it
turned out that Brown never did the fact checking, and never asked to see the
audited returns. We also note that only dimensionless returns are to be
compared.

So we prefer the more robust challenge which, under these circumstances,
becomes fair. We believe that academia is about search for knowledge and
understanding the world, not a commercial enterprise. The same with societal
risk management, which is about the public good and does not issue precise
point forecasts (recall that Taleb et al.(2022), as its title indicates, is
against single point prediction in some domains). So the burden is on
forecasters to forecast. And we fail to get how a practical project with
remarkable forecasting skills could work for government and not the private
sector. The superforecasting project is just about such betting. So, as much
as we would have preferred to voice the unspoken question, here we are
obligated to put the old adage as ”if they claim to be so good at forecasting,
and their forecasts are actionable and related to reality, why aren’t they so
rich?” –in other words, why do they depend on taxpayer funds and, possibly,
tax deductible (that is, charitable) contributions to finance such forecasts?

##  IV Conclusion: Some More Evidence Required

Finally, can Tetlock et al. prove that better estimates of $P_{K}$ can provide
real benefits to decision makers?

In addition to the problems in the financial domain mentioned above, we
completely fail to see the link in insurance –and in event risk in general. In
our experience as risk and insurance practitioners, decision makers are
usually not well equipped to deal with probabilistic information (compounding
the difficulty in translating probabilistic information into practical
effects)555There is the other problem that payoffs are in in expectation space
not in frequency space. For instance hedge funds with the best track records
turned out to be the most vulnerable to tail events in 2008, see [6].. For
instance, in a military context, if we refine the estimate of a South China
sea conflict from e.g. 15% to 17%, can Tetlock et al prove that this makes a
difference in any practical situation?

Also, one is allowed to wonder why the superforecasting project is not applied
to sports and election forecasts where 1) $P_{K}$ applies, 2) compatible with
probability theory, 3) provides repeatable tests with overly abundant data
and, centrally, 4) is ”bankable” (that is, translatable into dollars and
cents)?

We conclude with the following recommendation: in future work, it would be
helpful if Tetlock et al. provided more rigorous backing of their claims about
the link between $P_{K}$ and $G_{K}$. For, as it stands, we see neither
theoretical nor practical benefits to that ”superforecasting” enterprise.

## References

  * [1] P. E. Tetlock, Y. Lu, and B. A. Mellers, “False dichotomy alert: Improving subjective-probability estimates vs. raising awareness of systemic risk,” _International Journal of Forecasting_ , 2022.
  * [2] N. N. Taleb, Y. Bar-Yam, and P. Cirillo, “On single point forecasts for fat-tailed variables,” _International Journal of Forecasting_ , 2022.
  * [3] N. N. Taleb, “On the statistical differences between binary forecasts and real world payoffs,” _International Journal of Forecasting_ , 2021.
  * [4] ——, _Dynamic Hedging: Managing Vanilla and Exotic Options_. John Wiley & Sons (Wiley Series in Financial Engineering), 1997.
  * [5] J. Bhagwati, “Wheel of fortune,” _The New Republic_ , pp. 40–41, October 5, 1987.
  * [6] N. N. Taleb, _The Statistical Consequences of Fat Tails_. STEM Academic Press https://arxiv.org/abs/2001.10488, 2020\.

## Supplementary Material

The recording of the discussion session (webinar) is available at
https://www.techincertoreadingclub.com.


# PrivChain: Provenance and Privacy Preservation in
Blockchain enabled Supply Chains

Sidra Malik11footnotemark: 1<EMAIL_ADDRESS>Volkan Dedeoglu
<EMAIL_ADDRESS>Salil S. Kanhere<EMAIL_ADDRESS>Raja Jurdak<EMAIL_ADDRESS>University of New South Wales, Sydney, NSW,
2052 Australia  CSIRO Data61, Pullenvale  Queensland University of Technology,
Brisbane, QLD, 4000 Australia

###### Abstract

Blockchain offers traceability and transparency to supply chain event data and
hence can help overcome many challenges in supply chain management such as:
data integrity, provenance and traceability. However, data privacy concerns
such as the protection of trade secrets have hindered adoption of blockchain
technology. Although consortium blockchains only allow authorised supply chain
entities to read/write to the ledger, privacy preservation of trade secrets
cannot be ascertained. In this work, we propose a privacy-preservation
framework, PrivChain, to protect sensitive data on blockchain using zero
knowledge proofs. PrivChain provides provenance and traceability without
revealing any sensitive information to end-consumers or supply chain entities.
Its novelty stems from: a) its ability to allow data owners to protect trade
related information and instead provide proofs on the data, and b) an
integrated incentive mechanism for entities providing valid proofs over
provenance data. In particular, PrivChain uses Zero Knowledge Range Proofs
(ZKRPs), an efficient variant of ZKPs, to provide origin information without
disclosing the exact location of a supply chain product. Furthermore, the
framework allows to compute proofs and commitments off-line, decoupling the
computational overhead from blockchain. The proof verification process and
incentive payment initiation are automated using blockchain transactions,
smart contracts, and events. A proof of concept implementation on Hyperledger
Fabric reveals a minimal overhead of using PrivChain for blockchain enabled
supply chains.

###### keywords:

zero knowledge proofs, provenance, traceability, privacy, permissioned
blockchain , supply chain

##  1 Introduction

Blockchain is a disruptive technology for provenance and traceability in
supply chains[15, 7, 14, 1]. Provenance refers to the data related to the
origin of products and the primary producers, whereas, traceability refers to
the trail of ownership and state of the products as they make their way
through the supply chain life cycle, i.e., from primary producers to the end-
users. However, providing traceability and protecting privacy are two
conflicting goals in blockchain enabled supply chains[33, 26]. Logging
traceability and provenance data on blockchain may pose risks, such as
exposure of trade secrets for many supply chain participants. The specific
information that constitutes trade secrets may vary across supply chain
domains, but generally includes any piece of information that could offer
competitive advantage such as product formulas, the location of origin, list
of suppliers and payment contracts. Nevertheless, the dilemma between privacy
and traceability is similar in other blockchain based decentralised
applications.

Most blockchain based traceability frameworks proposed in the literature [24,
32, 34] and industry solutions [14, 1] rely on permissioned blockchains,
wherein information is only revealed to authorised participants or validating
entities. For instance, in consortium blockchains, where peer nodes represent
several organizations, a common ledger is shared among the peers of the
participating organizations. The ledger provides an audit trail of supply
chain events, thus affording provenance and traceability of products. Since
the events are associated with the digital identifier of supply chain
participants, any peer accessing the ledger has full information about the
product, its trade flows, or the participants related to the supply chain
activities.

To address this data privacy problem, data can be encrypted before sharing it
on the ledger [25, 12]. However, encrypted data cannot be used in systems
which use blockchain technology for instant verification of provenance. Some
solutions[22, 9] propose to record supply chain event data anonymously to
protect trade flows. However, reliance on known identifiers is necessary to
allow authorised participation and to have accountability and trust mechanisms
integrated with blockchain [23, 6]. Another solution proposed by Hyperledger
Fabric[8], a permissioned blockchain platform, is the use of private channels
for privacy preservation. Although, this limits the visibility of supply chain
events within a channel, it is inflexible to support selective data protection
by a peer and involves additional overheads [8].

A reliable solution would be not to share the private data itself but to
generate and share computations[29] and proofs on the data[18] in line with
the system’s traceability and provenance criteria. However, a blockchain based
privacy preserving mechanism employing data computations and proofs, would
require additional resource consumption from supply chain participants. Unless
there are monetary incentives to compute and share privacy-preserved
provenance and traceability information, adoption of blockchain technology in
supply chain will remain undervalued. Although privacy preservation coupled
with monetary incentives can encourage more participation from supply chain
entities, devising such a mechanism is challenging. The reason is that the
blockchains that underpin cryptocurrency cannot directly be used for physical
asset transfers such as in supply chains, and in absence of cryptocurrency it
is hard to ensure incentive amounts are both kept private and paid as agreed.

In this work we propose privacy preservation and incentive enforcement
mechanisms on permissioned blockchain based on Zero Knowledge Proofs (ZKPs)
(see Section 2.2) and commitment schemes (see Section 2.3). ZKPs help to prove
possession of a secret without revealing the actual information whereas
commitment schemes can be used to verify a committed secret later in time.
Supply chain participants can provide ZKP proofs and get reciprocated by the
committed incentive amounts for utilizing their resources. The blockchain can
verify these proofs, initiate an off-chain payment mechanism and log the
results in an immutable way. PrivChain leverages the blockchain based supply
chain model proposed in [24] and described in Figure 1. The supply chain
participants register products on the ledger with product specific data and
events. IoT sensor data, such as location, quality, and temperature are hashed
and linked to the transactions that log product’s events. Availability of this
data contributes to the provenance and quality of the product. We propose that
instead of sharing this data, participants share proofs of their valid data
pertaining to products. The verification of such proofs is then automated by a
blockchain smart contract, which is a self executing software program invoked
when some pre-defined conditions are met. The successful verification attests
to the claim made regarding quality or provenance of a product. The
verification results are then made available with the final product. Sharing
proofs rather than the supply chain data allows supply chain entities to keep
product and trade specific information private. Since the proof generation
incurs additional effort for the supply chain participants, a monetary
incentive mechanism is proposed to reward participants for generating
successfully verified proofs. PrivChain framework is applicable to other use-
cases, such as energy trading and in healthcare where sharing data on
blockchain compromises privacy yet it is essential for accountability.

The main contributions of our work are:

  * •

We devise a ZKP based privacy preservation solution for blockchain enabled
supply chains, where the participants provide proof of provenance claims
without disclosing privacy-sensitive data such as location and trade flows.

  * •

We design a smart contract to automate the verification of the provenance
proofs and the integration of the incentive mechanism that enforces instant
payment of rewards from buyers to sellers for providing verified proofs.

  * •

We implement the proposed framework on Hyperledger Fabric and demonstrate that
the overheads for proof verification are minimal.

The rest of the paper is organized as follows. Section 2 discusses relevant
background knowledge. Section 3 details PrivChain architecture and the related
components. The performance evaluation and security analysis is outlined in
Section 4. Lastly, Section 5 concludes the paper.

##  2 Preliminaries

In this section, we present a brief description of the supply chain use case
and the transaction vocabulary [24] which will be used as a baseline for our
proposed work. Next, a background of ZKP schemes is given with a brief
discussion on our choice of ZKP variant for masking provenance data. In
addition, we present a brief description of the Pedersen commitment scheme,
which provides the basis for our incentive mechanism for providing proof of
provenance.

Figure 1: Transaction vocabulary with supply chain process

###  2.1 Supply Chain Use Case and Transaction Vocabulary

A blockchain-enabled supply chain model, as shown in Figure 1, consists of
producers, suppliers, manufacturers, logistics, retailers and consumers who
store the physical supply chain events such as production and trade on the
blockchain. To demonstrate our privacy preservation mechanism, we consider a
wine supply chain, where the wine producer provides a proof for the grape
production region but does not want to reveal the exact location of production
(to keep his suppliers in that region as a trade secret). Thus, we provide
location proofs rather than sharing exact locations for provenance
verification. The proposed underlying network is built on multiple regional
side chains [24] that operate in parallel to increase scalability. Each of
these side chains is a permissioned blockchain network with a dedicated
administrator and a certification authority for registering participants. To
participate in the network, a supply chain entity first registers with the
certification authority of his region and obtains a blockchain identity which
certifies his digital profile on the ledger. The supply chain participants log
supply chain events on the blockchain using the transaction vocabulary
proposed in [24]. For the wine supply chain use case, a grape producer
registers a new batch of commodity on the ledger using a create transaction,
$TX_{create}$. When the grapes are sold to an intermediate supplier or a wine
producer, the trade is recorded using a trade transaction, $TX_{trade}$. A
wine producer processes the grapes sourced from multiple suppliers and
registers the final product (e.g., a bottle of wine) on the blockchain using a
produce transaction, $TX_{produce}$, which also contains the identifiers of
constituting batches of grapes using $TX_{create}$. The final product, a wine
bottle, is then traded through logistics and retailers to the end consumers.
The wine producers prove origin information through blockchain, without
revealing the exact location and identities of grape producers. The grape
producers provide location proofs using ZKPs. The wine producers on the other
hand commit to incentive payments to grape producers and keep the sellers’
information private in $TX_{produce}$. Without loss of generality, we limit
the seller and buyer model to grape and wine producers only and eliminate any
intermediate suppliers.

###  2.2 Zero Knowledge Proofs

ZKPs are cryptographic methods in which a prover can attest to a verifier that
some secret information is true without revealing any details about the
secret.

Depending on the requirement of interactions between the prover and the
verifier, ZKPs are interactive or non-interactive. For a distributed network
such as blockchain, interactive ZKPs are impractical due to the communication
overhead for verification. Zero-Knowledge Succinct Non-Interactive Argument of
Knowledge (ZK-SNARKs) [11] are an efficient non-interactive variant of ZKPs.
In addition, the proofs generated are of constant size despite the complexity
of proof generation. One practical example of the use of ZK-SNARKs is Zcash
[13]. The steps involved in the process of non-interactive ZKPs are defined
below:

  * •

Setup: This step is performed by a trusted third party and entails key
generation. The key generator G, takes a secret parameter $\lambda$ to
generate two publicly available keys: proving and verification keys.

  * •

Proof Generation: A prover uses the proving key, a common input and a secret,
$\delta$ to generate a proof.

  * •

Verification: The verifier runs a function that takes proof, common input and
the verification key as inputs and returns true if the proof is correct and
false otherwise.

Generic ZKPs, e.g., ZK-SNARKs, are less efficient than specific ZKPs such as
ZK Set Membership (ZKSM) or ZK-Range Proofs (ZKRPs) [20]. The ZKSM scheme
allows anyone to prove that a secret $\delta$ lies within a given set $[u,v]$.
ZKP-Range Proofs (ZKRPs) are a special instance of ZKSM [20] , which prove
that a certain secret number lies within a specific numeric range. To create
ZKRP, the secret $\delta$ is decomposed into base $u$ using

$\delta=\sum_{j=0}^{l}\delta_{j}u^{j}$ (1)

if each $\delta_{j}$ belongs to the interval $[0,u)$, then
$\delta\in[0,u^{l}]$. The ZKSM algorithms[27] can be easily adapted to carry
out ZKRP computation as it is specific to numeric intervals as compared to
ZKSM. When compared to a generic ZKP, ZKRP is proven to reduce the computation
overhead of proof verification by an order of 10 [20]. Hence, ZKRP can be
applied to a range of decentralised applications where numerical data needs to
be proven without actually revealing it such as account balances (e-finance),
sensor readings (IoT), electronic auctions (e-commerce), rating/trust scores
(supply chains), and distribution of sales (energy trading).

Bulletproofs[3] are short and efficient ZKRPs designed specifically for
blockchain. They have a performance advantage as the size of proofs are
logarithmic to the input size and they do not require a trusted setup. Note
that, the choice of the range proof methods differs based on the computation
power of the prover and the verifier. Bulletproofs with a smaller proof size
reduce the transaction size when compared to other variants of ZKRP such as
signature based methods[4]. However, signature based methods incur lower
verification complexity only when the range size is less than $10^{2}$
bits[5]. For the proposed privacy preservation scheme, we choose non-
interactive signature based range proofs [4] based on 1) our reliance on
permissioned blockchains for trusted setup and verification whereby the
computation overhead for setup and verification is delegated to the blockchain
provider; 2) the lower proof verification complexity of non-interactive
signature based range proofs given the high transaction send rate in typical
supply chain use cases.

Figure 2: Overview of Workflow

###  2.3 Pedersen Commitment Scheme

Pedersen commitment [28] is a non-interactive secret sharing scheme. It allows
a user to commit to a secret, and send a verifier a commitment to the secret
without disclosing the secret itself. The secret is shared with the verifier
at some later point in time. The verifier computes a new commitment from the
secret and verifies it by comparing it to the previous commitment shared by
the committer. This scheme is based on the following three steps:

  * •

Generator Setup: Let $p$ and $q$ denote two large prime numbers such that $q$
divides $p-1$. $G_{q}$, a unique subgroup of $\mathbb{Z}_{p}$ of order $q$, is
chosen by a trusted third party where $g$ is the generator of $G_{q}$. Next,
$h\in G_{q}$ is chosen such that $log_{g}h$ is a secret. The parameters $p$
and $q$ are then made public by the trusted third party.

  * •

Commit: To commit to a secret message $m$, first a random number
$r\in\mathbb{Z}_{p}$ is chosen. Then, a commitment at the committer’s end is
computed as $com_{c}=g^{m}h^{r}$ mod $q$ and sent to the verifier at time
$t_{m}$.

  * •

Commit Open: This step involves the commitment verification at time $t_{n}$
where $n>m$. The committer reveals $m$, and $r$ to the verifier. The verifier
computes another commitment $com_{v}$ and compares it with the previous
commitment to validate if and only if
$com_{c}\stackrel{{\scriptstyle?}}{{=}}com_{v}$.

We choose this scheme based on its strong properties, namely: 1) it does not
allow a committing party to change the $m$ once committed and 2) it is hard
for an unbounded adversary (in terms of time and resources) to find $m$ [28].

##  3 Privacy Preservation in Blockchain-Enabled
Supply Chains

Recall from Section 2.1, that our aim is to preserve the privacy of the
provenance data and trade flows associated with a final product, while
ensuring that the primary producers receive the pre-agreed incentives for
providing provenance proofs. In this section, we present an overview of
PrivChain and provide details of the components involved in recording
provenance of the grapes on the blockchain, protecting trade flows of wine
producers, and actioning the incentive payment mechanism. Finally, we outline
how end-consumers can query the blockchain to verify the origin of grapes used
in production of a wine bottle.

Figure 3: Setup Phase

### Overview

The high-level workflow for PrivChain is shown in Figure 2. The blockchain
service provider sends the public setup parameters to the registered supply
chain participants (Step 1). Using these parameters, the grape producers
generate ZKRP location proofs, $\phi_{loc}$ (see Section 2.2), to register a
new batch of grape commodity using $TX_{create}$. The grape producer also
generates a commitment $com_{inc}$ to the pre-agreed incentive amount,
$\$_{inc}$ (see Section 2.3), using $TX_{trade}$. Both the $\phi_{loc}$ and
$com_{inc}$ are recorded on the blockchain through the initiation of a
$TX_{trade}$ by the grape producer (Step 2). Next, a verification and
incentive smart contract, $VISC$, verifies $\phi_{loc}$ and registers the
grape commodity along with the verified region (Step 3(a)). It also generates
a request for incentive payment to a financial institution, such as a bank
using $Req_{pay}$ (Step 3(b)). The bank verifies $com_{inc}$ and releases the
incentive amount to the grape producer (Step 4). In the final stage of
manufacturing, the wine producer encrypts the grape producers’ and commodity’s
details and stores the identifier of a final product on the ledger using
$TX_{produce}$. The wine producers then imprint the origin information on the
wine bottle along with a QR code which can be used to query the blockchain
(Step 5). The end-consumers can scan the QR code (Step 6) to retrieve the
origin information from the blockchain which can be used to verify the printed
origin on the wine bottle (Step 7). Having covered the high level workflow, we
discuss each of the steps in more detail next.

### Step 1: Setup Phase

The setup phase is illustrated in Figure 3. Recall from Section 2.1, we rely
on a scalable network model where multiple regional side chains are operating
in parallel. Figure 3, for example, shows a map with different regions, each
depicting a side chain. We describe the specifics within one side chain, which
is replicated across all side chains. In order for a grape producer to
generate $\phi_{loc}$ and $com_{inc}$, public parameters for setup and
commitment generation are required (as outlined in Section 2.2 and Section
2.3). For a particular side chain, a blockchain administrator generates the
following standard ZKRP setup parameters [27]: proving key $pk$, verification
key $vk$, and $f_{\phi}(x,y)$ for generating $\phi_{loc}$ and a proof
verification function. The grape producer takes location input from a sensor
device in form of a signed commitment to GPS coordinates $(x,y)$. Specific to
our use-case, we assume that the GPS device is trusted [31] and cannot be
tampered with. In case the devices are not guaranteed to be trusted, we can
use existing solutions in literature such as signal strength or frequency
analysis to identify spoofed signals, etc [21]. The grape producer uses the
signed commitment to $(x,y)$ as an input to $f_{\phi}(x,y)$, which is used to
compare the input to authorised locations in a particular region.

However, computing signatures for every possible GPS coordinate in an
authorised region is impractical for a business administrator. Thus, we
propose to map the GPS coordinates of a particular region to a Military Grid
Reference System (MGRS)[16] grid index. Using MGRS, Earth’s surface can be
divided into squares of 1000m × 1000m, 100m × 100m, 10m × 10m or 1m × 1m. Any
specific point on Earth can then be represented as an area specified by grid
indices. For our use-case, a region can be represented by a grid where each
square is of size 10m × 10m (across all the side chains). The blockchain
administrator can pre-compute the signatures on MGRS grid indices of known
farms within each square in a grid. However, during the process of generating
$\phi_{loc}$, conversion of farm coordinates into grid indices will also be
required which can be later mapped to the authorised region specific to each
side chain. The region boundaries and names can be agreed upon by the side
chains’ administrators, such that each $\phi_{loc}$ can be mapped to a
specific region name.

Algorithm 1 Non-Interactive ZKRP Generation for Location Proof

0: Request to log $TX_{cr}$ from the seller, location $\delta=(x,y)$ signed by
the GPS device at the farm

1: The seller wants to keep $\delta$ secret and prove that it lies within MGRS
indices of registered farms in a particular region.

2: for each $a\in\delta$ do

3: the seller generates a commitment (as described in Eq. 1), based $y=g^{a}$
to the base $g$ where $a\in[0,u^{l}]$

4: the seller chooses a random $v_{j}\in\mathbb{Z}_{p}$ for every $j$ in Eq. 1
and computes $t_{j}=g^{v_{j}}$.

5: The seller computes a commitment (see Algorithm 15 [27]) using a
cryptographic hash function, $com_{a}=HASH(g,y,t)$.

6: The $com_{a}$ and range for authorized region $[0,u^{l}]$ is given as an
input to a proof generating function, $f(a)$.

7: For each $j\in\mathbb{Z}_{l}$, $f(a)$ computes $r_{j}=v_{j}-ca$ and checks
if $g^{r_{j}}y^{c}\equiv t_{j}$, it generates a witness, $w$.

8: The witness, $w$ is then signed by the seller’s private key, $pk$ to
generate $\phi_{a}$.

9: end for

Figure 4: Proof and Commitment Generation

During the setup phase, the blockchain administrator also provides the public
parameters $p$, $q$, $g$ and $h$ for generating commitments such as
$com_{inc}$. The commitment and proof generating parameters are then
distributed to the registered supply chain participants to generate
$\phi_{loc}$ for their commodity and $com_{inc}$ for protecting incentive
amounts.

### Step 2: Proof and Commitment Generation for ZKRP

The proof generation is executed off-chain at the grape producer’s end and
illustrated in Figure 4. To create $\phi_{loc}$, a grape producer inputs the
secret location coordinates $(x,y)$ to a proof generating function,
$f_{\phi}(x,y)$. For our use-case, the location data $(x,y)$ is provided by a
GPS sensor registered at the grape producer’s farm. The sensor device signs
the location data using its private key. We assume that the public keys of the
GPS devices are known to the blockchain administrator. The proof generation
steps can be summarized as (for details of the signature-based range proof
construction, see [27]):

  * •

Generation of the digital signatures for the authorised region: To construct a
proof, a grape producer uses $f_{\phi}(x,y)$ to map $(x,y)$ to an authorised
region. The signed commitments for all $(x,y)$ in the authorised region are
provided by the blockchain administrator which are used as the public input
for $f_{\phi}(x,y)$. In the case of MGRS mapping (see step 1: setup phase),
the public input will comprise of commitments to MGRS indices of registered
farms only.

  * •

Generation of the commitment for the secret $(x,y)$: To generate a commitment
$com_{x,y}$ for $(x,y)$, the grape producer first decomposes the secret
$(x,y)$ into base-u, such that each element belongs to the interval $[0,u)$.
The producer then computes digital signatures on each element and blinds the
signatures by raising them to a randomly chosen exponent $v\in\mathbb{Z}_{p}$,
such that it becomes computationally infeasible to determine the signed
elements.

  * •

Generation of the proof: When a producer has a valid $com_{x,y}$ with respect
to the authorised region, a witness parameter is generated. In the final step,
the grape producer signs the witness using $pk$ to generate $\phi_{loc}$,
which is the final output of $f_{\phi}(x,y)$.

Algorithm 2 Commitment Generation for the Incentive, $\$_{inc}$

0: valid $TX_{trade}$ parameters, negotiated $\$_{inc}$ between a buyer and a
seller, $p$, $q$, g (generator of $G_{q}$)

1: The seller chooses a random $r\in\mathbb{Z}_{p}$ and $h\in G_{q}$

2: The seller then computes the commitment to incentive amount, $\$_{inc}$,
using $com_{inc}=g^{\$_{inc}}h^{r}$

3: The $com_{inc}$ is then included in $TX_{trade}$ by the seller before it is
logged on the ledger.

The non-interactive ZKRP used for generating $f_{\phi}(x,y)$ is outlined in
Algorithm 1. It is important to note that $f_{\phi}(x,y)$ cannot be altered by
the grape producer or any other unauthorised participants.The grape producer
registers a new batch of grapes using $TX_{cr}$. The structure of $TX_{cr}$ is
given below:

$TX_{cr}=\Big{[}\;ID_{g}\;|\;H_{data}\;|\;L_{\phi_{loc}}\;|\;Sig_{s}\;\Big{]}$
(2)

where $ID_{g}$ is the identifier of the grape commodity, $H_{data}$ is the
hash of the commodity data (e.g. commodity type, quantity, unit price, etc.),
$L_{\phi_{loc}}$ is the link to $\phi_{loc}$ which has been generated using
$f_{\phi}(x,y)$. $PU_{s}$ is the public key of the seller and $Sig_{s}$.

Next, the grape producer generates a commitment, $com_{inc}$. Prior to a
supply chain trade event, there is a negotiation between the seller (grape
producer) and the buyer (wine producer) to set the incentive amount
$\$_{inc}$, which could be included in a digital contract related to the
commodity trade. However, this exposes $\$_{inc}$ to the blockchain network.
On the other hand, if $\$_{inc}$ is encrypted, blockchain cannot verify
$\$_{inc}$. To keep $\$_{inc}$ confidential and to have the wine producer
adhere to $\$_{inc}$, a commitment $com_{inc}$ is generated by the grape
producer using the Algorithm 2. This commitment $com_{inc}$ attests to the
incentive amount $\$_{inc}$ which the producer is expecting in return for
providing a valid location proof $\phi_{loc}$. $\phi_{loc}$ and $com_{inc}$
are then sent to the blockchain during the trade of commodity using
$TX_{trade}$. The structure of $TX_{trade}$ is given below:

$TX_{trade}=\Big{[}\>ID_{g}\>|\>H_{data}\>|\>L_{\phi_{loc}}\>|\>com_{inc}\>\\\
|\>region\>|\>Sig_{s}\>|\>PU_{s}\>|\>Sig_{b}\>|\>PU_{b}\>\Big{]}$ (3)

where $ID_{g}$ is the identifier of the grape commodity, $H_{data}$ is the
hash of the commodity data, $L_{\phi_{loc}}$ is the link to $\phi_{loc}$,
$com_{x,y}$ is the commitment to $\$_{inc}$, $region$ attribute is populated
after $\phi_{loc}$ has been verified, $Sig_{s}$ and $PU_{s}$ are the
signatures and public key of the seller, and $Sig_{b}$ and $PU_{b}$ are the
signatures and public key of the buyer.

The proof verification process and incentive request mechanism is described in
Step 3(a) and 3(b) respectively.

### Step 3(a): Proof Verification

$TX_{trade}$ invokes a verification and incentive smart contract, VISC which
initiates an on-chain proof verification process (see Section
2.2:verification). The verification is done only at the time $TX_{trade}$ is
initiated. The contract uses the verification key $vk$ enlisted in its
properties against the proving key $pk$ distributed to the registered
participants. The verification function returns true if $\phi_{loc}$ is
successfully verified, otherwise it returns false. $TX_{trade}$ contains a
region attribute where the proof verification result is specified. When a
valid $\phi_{loc}$ is provided, the name of the region is stored in the region
attribute. In case $\phi_{loc}$ is invalid, the region attribute is populated
as “not verified”. Following the verification of $\phi_{loc}$, VISC transfers
the ownership of grape commodity to the wine producer and generates a request
to a bank for incentive payment, $Req_{pay}$ (discussed in Step 3(b)).

To keep blockchain usage open for all registered participants, provision of
proofs is not mandatory for the trade of commodity. If no $\phi_{loc}$ is
provided during the trade, “proof not provided” is embedded in region
attribute of $TX_{trade}$ and $Req_{pay}$ is not issued. However, based on the
supply chain use-case, the provision of $\phi_{loc}$ can be made mandatory.

### Step 3(b) and Step 4: Incentive Payments

The incentive mechanism is automated through smart contracts to ensure
participants contributing valid data, i.e., verified proofs, get instant
returns from the trading parties. Furthermore, the incentive amounts are kept
private from the blockchain network. As shown in Figure 5 and Eq. 3, during
the $TX_{trade}$, the seller also sends $com_{inc}$ (generated in Step 2) to
VISC. The buyer on the other hand encrypts the incentive amount $\$_{inc}$,
and seller’s ID, $ID_{sell}$ using the bank’s public key $PK_{bank}$, signs it
using $Sig_{buy}$ and sends it to VISC. Then, the VISC generates $Req_{pay}$
for the bank notifying a pending incentive payment as:

$Req_{pay}=\Big{[}\>com_{inc}\>|\>Enc\>((\$_{inc}\>|\>r\>|\>ID_{sell}\>),PK_{bank})\>|\>Sig_{buy}\>\Big{]}$
(4)

Figure 5: Incentive payment: request generation and verification

After receiving $Req_{pay}$, the bank decrypts $\$_{inc}$ and $ID_{sell}$
using its private key. Next, the bank computes a new commitment
$com_{inc}^{\prime}$ using the Algorithm 3. The bank then compares it with
$com_{inc}$ which was issued by the grape producer. If both commitments match,
it confirms that $\$_{inc}$ is the agreed incentive amount, and must be paid
to the seller for providing a valid $\phi_{loc}$. The bank transfers
$\$_{inc}$ to the seller’s account. The generation of ${com^{\prime}_{inc}}$
and comparison with $com_{inc}$ is carried off-chain to reduce any on-chain
computation overheads. Once the payment request is processed, a transaction is
logged on the ledger confirming the payment. To preserve the privacy of the
seller and the buyer, the transaction only includes an identifier for
$Req_{pay}$ and the status of payment.

### Step 5: Protection of Trade Flows

Recall from Section 2.1, the provenance of a wine bottle on blockchain is
computed by querying the transactions chained to the grape identifiers
involved in $TX_{produce}$. The inclusion of grape identifiers help in
locating $TX_{create}$ of each commodity listed in $TX_{produce}$ (see Section
2.1). Using $TX_{create}$, all the relevant details regarding origin, primary
producer, etc. can be derived. The grape identifier can also be used to trace
all the trade transactions $TX_{trade}$ involved. Hence, knowledge of grape
identifiers may lead to the exposure of trade flows involved in the life-cycle
of a commodity. Even if the trade flows are hidden from end-consumers, they
are accessible to the peers of the blockchain network. To preserve the privacy
of these trade flows within the blockchain network, we hide the identifiers of
grapes commodities that form the raw material for the wine in a bottle.

Algorithm 3 Commitment Verification

0: valid $TX_{trade}$, valid $\phi_{loc}$, $g$ (generator of $G_{q}$)

1: The verification and incentive smart contract, VISC generates a $Req_{pay}$
according to Eq. 2.

2: the bank decrypts $\$_{inc}$ and $r$ from $Req_{pay}$

3: The bank then computes another commitment ${com^{\prime}_{inc}}$ based on
the decrypted values using ${com^{\prime}_{inc}}=g^{\$_{inc}}h^{r}$.The bank
then checks:

4: if $com^{\prime}_{inc}$= =$com_{inc}$ then

5: The incentive amount, $\$_{inc}$ is paid to the seller’s account which is
identified using $ID_{sell}$ in $Req_{pay}$

6: The bank logs a payment transaction on the ledger

7: else

8: the bank logs a dispute against the commodity identifier, $CID$.

9: end if

As described in Step 3(a), once $\phi_{loc}$ is verified, the verified region
name is stored in $TX_{trade}$. When $TX_{produce}$ logs a wine bottle on the
ledger, all the pre-verified regions are included in regions attribute of
$TX_{produce}$ in a readable form, while the identifiers of grape commodities
are stored in encrypted form to preserve the privacy of the producers and the
suppliers involved in the production of the wine bottle. Upon provenance query
from an end-consumer, only the names of the pre-verified regions from
$TX_{produce}$ are returned. The modified $TX_{produce}$ is defined as:

$TX_{produce}=\\\
\Big{[}ID_{FP}\>|\>Enc(\>(ID_{g1},\ldots,ID_{gn}),Key)\>|\>regions\>|\>Sig_{buy}\Big{]}$
(5)

where $ID_{FP}$ is the final product identifier for the wine bottle, $ID_{gi}$
is the identifier for grape commodity $i$ encrypted using a symmetric
encryption key, $Key$, and $Sig_{buy}$ is the signature of the buyer (wine
producer). Note that $Key$ is only distributed to the authorised participants
who need to verify the constituting identifiers in a wine bottle, for example,
a food regulatory authority which may use blockchain transactions for
verification of provenance claims. The key distribution problem is out of the
scope of this work. However, some external nodes can be appointed for managing
keys such as “access guards” proposed in [29].

### Step 6 and 7: End-Consumer Query

Once the wine bottle is produced, it is then traded to a retailer for selling.
The wine bottle has printed provenance information and a QR code. The QR code
enables an end-user to generate a query transaction using a blockchain
consumer application. The query transaction returns the regions attribute from
$TX_{produce}$ for the $ID_{FP}$ of the wine bottle specified in QR code. End-
consumers can compare the results returned through the blockchain application
with those printed on the bottle.

##  4 Evaluation and Results

In this section, we first present the business model formulation in the
context of Hyperledger Fabric followed by the experimental setup. Next, we
present results quantifying the performance of our system for relevant
benchmarks. Finally, a qualitative security and privacy analysis of PrivChain
is presented.

###  4.1 Business Model

The proposed system is implemented on Hyperledger
Fabric222https://www.hyperledger.org/use/fabric, an enterprise grade
permissioned blockchain platform created for integrating blockchain with
business applications. For evaluation of PrivChain, we devise a commodity
trading business network in Hyperledger Fabric comprising of:

  * •

Participants: include grape producers, a wine producer, a bank and an end-
consumer.

  * •

Assets: we define two assets for our business model; commodity (grapes) and a
final product (wine bottle).

  * •

Chaincode (smart contract): consists of functions which initiate a ledger,
query or update it. These chaincode functions include registering a grapes
produce ($TX_{create}$), registering a wine bottle ($TX_{produce}$), trading
an existing produce or bottle ($TX_{trade}$), and querying a wine bottle
($TX_{query}$) according to the transaction vocabulary described in Section
2.1. For our proof of concept, we deploy a single chaincode which also embeds
the corresponding functions of verification of proofs and request generation
for incentive transfer.

###  4.2 Experimental Setup

The deployment of the business network and performance tests are carried out
on a Dell Notebook (Intel Core i7, 2.21 GHz, 8 GB memory). A complete business
network setup for our proposed system involves three components: Hyperledger
Fabric for chaincode deployment, Hyperledger Fabric network model and
Hyperledger Fabric Software Development Kit (SDK) for client application
interaction with the chaincode.

We build a Fabric network of two organizations, depicting grape producers
(sellers) and wine producers (buyers). Each organization consists of two peer
nodes, one orderer (using SOLO as the ordering method), a database (goleveldb)
and a certification authority. Before a client application can interact with
the Fabric network, it must be authorised by the respective certification
authority. Once authorised, the client application can invoke or query from
the ledger.

In addition, for the implementation of ZKRP [4] and Pedersen commitment, we
choose the ING-bank repository333https://github.com/ing-bank/zkrp, an open-
source reusable library for creating and verifying ZKRPs and set membership
proofs. The commitments $com_{inc}$ and proofs are generated on the client
application. However, verification is done on-chain, using the verification
key, $vk$ provided by the business network administrator. The chaincode
generates $Req_{pay}$ using Hyperledger chaincode events and sends them to the
respective bank’s application. Event handling is carried out using Hyperledger
Fabric SDK which provides a fabric network package to listen to chaincode
events when a specific transaction is executed. For encrypting trade flows as
outlined in Step 5, we use npm Crypto-JS
package444https://www.npmjs.com/package/crypto-js with AES encryption. In
addition, we used Hyperledger
Caliper555https://www.hyperledger.org/projects/caliper, a benchmark tool for
blockchain performance evaluation. The workload of generating transactions
registering a wine bottle was distributed across three processes capable of
simulating concurrent transactions.

###  4.3 Performance Evaluation

The proof of concept implementation of our proposed system is evaluated for
ZKRP overheads, and registering a wine bottle with encrypted trade flows. ZKRP
computations include: setup (by the blockchain administrator), proof
generation (by the grape producer), and proof verification (by the chain
code). Registering a wine bottle (by the wine producer) involves a) querying
the blockchain for the region information of grape commodities involved, b)
encrypting the identifiers of these grape commodities, and c) registering the
bottle on ledger. In the next subsections, we analyse the associated execution
times (averaged across 10 runs) in carrying out these computations. The
execution times of commitment generation and verification are excluded as
these tasks can be accomplished in minimal time.

####  4.3.1 ZKRP overheads

Figure 6 depicts ZKRP computation times for setup, proof generation and
verification (see Section 3). The time required for the setup phase is 1.35
seconds. The setup phase is executed once by a blockchain administrator, thus
it is a one-time cost and its effect is minimal. Proof generation takes 0.79s
on average which is acceptable given that the proofs will only be generated
when a new grape commodity is ready. The proof generation and storage is
carried off-chain. The proofs are not included in blockchain transactions,
hence the transaction size is not affected. To benchmark the proof
verification time, we first define a baseline consisting of a smart contract
for trading grape commodities. In the baseline, a smart contract (triggered by
$TX_{trade}$) only performs the ownership transfer from a seller to the buyer.
In contrast, in PrivChain, VISC not only transfers ownership but also performs
proof verification and payment request generation. As shown in Figure 6, the
execution time of $TX_{trade}$ without ZKRP is 161.31 ms whereas for
$TX_{trade}$ with ZKRP it is 939.50 ms. The proof verification overhead
compared to the baseline is only 0.77s.

Figure 6: Range proof generation and verification times Figure 7: Throughput
and Latency of $TX_{produce}$

####  4.3.2 Registering Products with Encrypted Trade Flows

To generate the $TX_{produce}$, the wine producer first queries the blockchain
for the region attribute of the commodities involved in the production of the
wine bottle. The producer then encrypts the identifiers of these commodities,
and generates $TX_{produce}$ as defined in Section 2.1 which registers the
wine bottle on the blockchain. Figure 8 shows that the time required to
register a wine bottle (including both the query and encryption steps) is
220.16 ms. The wine bottle registration time for the baseline on the other
hand is 148 ms. The results show that querying and encryption of grape
identifiers incurs an increase of only 0.07s compared to the baseline. Note
that for our proof of concept implementation, we considered three grape
commodities involved in the production a wine bottle. If the number of
involved commodities is more, the query and encryption time is likely to
increase linearly.

Figure 7 presents the throughput and latency of $TX_{produce}$ varying the
transaction send rate from 10 tps to 300 tps for the duration of one minute.
Throughput is measured as rate at which the transactions are committed to the
ledger whereas latency is the time taken from an application sending a
transaction to the time it is committed in the ledger. With three concurrent
processes, throughput increases linearly reaching a maximum of around 160 tps
with the available resources. Beyond this point the network saturates, so the
throughput decreases and the latency increases. However, if this trend
prevails on a faster computing resource then more validating peers will be
required to handle transaction load higher than 160 tps.

Figure 8: Registering product with encrypted trade flows

###  4.4 Security and Privacy Analysis

Herein, we analyse the major security risks and threats posed by malicious
activities with respect to the PrivChain.

####  4.4.1 Linking Attack

In a permissioned blockchain, participants are registered using permanent
identifiers. Recall from Section 2.1 that a trade transaction includes both
the seller and buyer information. If there are few sellers in a particular
region i.e, only a handful of farms, protecting location information becomes
difficult as it can be easily linked to the corresponding farm location.

The PrivChain design is based on an assumption that typical supply chains have
broad geographical coverage. When there are a large number of producers in a
region, it becomes harder to link transactions to individual producers and
respective farm locations. However, linking attacks would still be possible in
some cases and unavoidable. In such cases, regions with fewer farms can be
merged with nearby regions with higher number of farms to operate under one
side chain. Adjusting region boundaries can minimise the linking attacks,
albeit at the cost of reduced resolution of region information and thus
utility.

####  4.4.2 Denial of Service Attacks

In a permissioned blockchain network, only the registered participants can
query/invoke transactions to launch denial of service attacks. For instance, a
grape producer is able to launch a denial of service attack by sending a large
number of $TX_{trade}$ or $TX_{create}$.

Supply chain perishable commodities such as grapes, are registered in a
specific cycle, i.e., when the new produce is ready. Thus, the fake
commodities can be readily detected if they are registered outside the
expected cycle. In addition, a fake commodity cannot be traded, and hence can
easily be identified on the blockchain. In case a large number of $TX_{trade}$
are issued to gain more incentives, recall from Section 3 Step 3(a), that
location proofs are verified once for each commodity at the time of trade and
the validity status is stored in $TX_{trade}$. A blockchain peer does not
allow ownership transfer or proof validation if the commodity has been traded
in the past from the same seller. Thus, the commodity will only be traded once
as a result of $TX_{trade}$ and the remaining transactions will not be
successful.

####  4.4.3 Disputed Incentive Amounts

During the incentive payment process as shown in Figure 5, a grape producer
and a wine producer agree on an incentive amount, $\$_{inc}$. However, a
dishonest grape producer may choose a higher $\$_{inc}$ to generate
$com_{inc}$. Similarly, a dishonest wine producer may choose a lower
$\$_{inc}$ with an intention to pay less than the agreed amount. As a result,
the off-chain verification at the bank will be invalid. The payments will be
queued unless the disputes get resolved.

PrivChain does not allow payments if $\$_{inc}\neq\$^{\prime}_{inc}$ at bank’s
end. Instead, a negative status of $Req_{pay}$ can be recorded on blockchain
and payment transactions with a negative status can be traced back to
$TX_{trade}$. If a seller or buyer is repeatedly involved in disputes related
to incentives, their participation can be revoked.

####  4.4.4 Replication of QR Code

Recall from Section 2.1, after a wine bottle is registered on the blockchain,
the printed provenance information is encoded in a QR code provided on the
bottle. Since QR codes are easy to create and copy, counterfeiters may copy
the original QR codes to use with a lower quality wine product.

The retailer information of the bottle is logged in the last $TX_{trade}$
before a bottle makes its way to the shelves. When an end consumer buys the
bottle from the retailer, the status of the bottle gets updated automatically
as “sold” in the blockchain by the retailer. Thus, it is impossible for the
retailer to sell bottles with the same QR code. In addition, the retailer does
not have any incentive to sell fake bottles with copied QR codes as he can
only sell one bottle associated with each QR code. Alternatively, a Copy
Detection Pattern (CDP)[30] along with QR codes can be employed to detect
counterfeited wine bottles. A CDP is a maximum entropy image which exploits
the property of information loss. A CDP image results in a loss of information
when it is scanned and printed again from the original. A detector with an
information loss threshold can determine the authenticity of a QR code with a
CDP.

####  4.4.5 Regional Blockchain Administrator

Recall from Section 3, a regional blockchain administrator devises most of the
blockchain based tasks such as the access control and setup parameters for
ZKRP. However, one may argue that excessive reliance on an administrative
entity may pose an additional security risk to the system. A blockchain
administrator may behave maliciously and jeopardise the security of the
system.

Permissioned blockchains are particularly well suited for supply chains. Due
to the nature of how permissioned blockchains work, the role of regional
blockchain administrator cannot be evaded. In presence of audit and regulation
it is not straightforward for administrative entity to behave maliciously. We
argue that administrative rules must be decided by a consortium of entities
such that no single entity can take control of the ledger. Consortium
frameworks such as proposed in [17, 24], allow multiple entities to devise and
control the operations blockchain system.

In addition,the underlying cryptographic primitives of blockchain such as
digital signatures, hash functions, and the data stored in transactions can
prove the authenticity of information at the time of audit.

##  5 Related Work

Several data and identity privacy solutions have been proposed in the
literature for decentralised applications. Most of these solutions address
privacy preservation by hiding the identity of the data provider on the
blockchain while others focus on hiding the information shared. We discuss
below certain solutions in literature which use encryption schemes, ZKPs,
commitment schemes or multiparty computation to protect either data or
identity over blockchains.

###  5.1 Encryption Schemes

In [29], the authors achieve privacy preservation by proposing distributed
multi-hop accountability in which data can be accessed using Attribute-based
Encryption (ABE). There are four main participants in the proposed system:
access guards, collaborators, information storage providers and information
coordinator. Collaborators are supply chain participants which store or
retrieve information in a ledger. The access guards distribute ABE keys to the
collaborators which then use ABE to encrypt the symmetric key used for
encrypting raw data. The AES-encrypted raw data is kept at the storage
provider and data link is provided later to the information coordinator. The
information coordinator stores data submitted by a collaborator into a local
database and the hash of this data is stored into the blockchain. Access
guards can later distribute ABE attributes for authorised decryption of the
raw data.

In [17], authors have proposed an efficient and privacy preserving bloom
filter-enabled multi-keyword search protocol. The bloom filter selects a low-
frequency keyword while performing a multi-keyword search operation for
encrypted data on blockchain. The low frequency key-word is selected for data
filtration which limits the computational cost by returning small number of
results. The authors have also proposed the use of pseudo random tags to
further escalate the search process to be completed in a single round. The
protocol outperforms the traditional search method in terms of time complexity
and search cost.

A recent work [26] on traceability proposes the use of HMM, homomorphic
encryption and ZKPs for privacy preservation. The authors propose a
permissioned blockchain connected to a permission-less blockchain. The privacy
of information in the permissioned blockchain such as trade and financial
transactions and the involvement of participants is not addressed. The proof
of traceability requires calculations of more than quadratic degrees which are
encrypted using homomorphic encryption. The number of participants in the
permissioned blockchain corresponds to the number of additions made in the
HMM. The model is encrypted using homomorphic encryption and the model
establishment is later verified using ZKPs.

###  5.2 ZKP and Commitment Schemes

Another privacy preservation mechanism is proposed in [22] using stealth
addresses and ZKP. The service providers register their services on the
blockchain. The consumers after choosing the service, send a service request
to the ledger masking their identity. A transaction verifies if a consumer has
sufficient money to purchase the service. The verification is performed by
dedicated participants. The service provider searches for the related request
transactions, and commit response transactions. A consumer at some later stage
can prove to a supervising authority the requests and money paid for the
service.

A similar approach of hiding identities using ZKRP is adopted in [9] for
electric vehicles. Electric vehicles need to schedule in-advance with a
service provider as they take longer to charge. During the scheduling process,
a service provider can learn private information such as location patterns,
payment details, usage and habits. The proposed scheme issues scheduling and
charging tokens to registered vehicles by respective smart contracts. These
tokens are then used to avail the charging services at a charging station
anonymously. The token scheme is, however, expensive in terms of blockchain
transaction overhead [9]. The authors replaced the token based scheme with a
Pedersen commitment scheme which showed a better performance.

In [18], the authors use ZK-SNARK to prove that both the selling and buying
parties have done payment and delivery of goods in escrow with a mediator, a
registered regulator. Upon verification by the mediator, the funds are
released to the seller and goods are transported using the delivery contract.
The whole process is managed by three service oriented smart contracts: one
for exchange of funds, second for adding updating the goods contract, and
third to maintain delivery information of goods.

Another identity anonymization approach is presented in [33] where the
blockchain addresses are encrypted along with the product distribution
information on a public blockchain. The legitimate parties post manufacturing
prove their identity using ZKP at the time of shipment and retrieval of
product. Three contracts namely MMC, PMC and VC are used. MMC registers the
manufacturer using its blockchain address and public key. MMC owner can then
register its products with PMC, a contract which manages the ownership
transfer requests. The owner first shares the secret token with the recipient,
and using the same token, the owner encrypts the recipient address and
manufacturer’s public key. The encrypted recipient address and address of VC
(which performs verification of identities) is then stored in PMC. The
recipient generates a ZKP that it knows the secret token which was used to
generate the encrypted address. PMC calls VC to verify if the recipient has a
valid token and upon verification, it then grants the ownership of a product
to the recipient.

###  5.3 MultiParty Computation

In [2], authors argue that, since Hyperledger architecture aims to provide a
consistent shared ledger among all the peers, it is challenging to keep
information private. The authors propose a solution which uses Multi-Party
Computation (MPC). The peers store encryption of private data on blockchain,
and use MPC when a transaction requires this data. According to [2], ZKP
cannot be used in a setting where a smart contract depends on private data of
more than one participant. In such cases, MPC is a better approach. In
addition, the proof of concept was developed on Hyperledger for a bidding
system where sellers have a secret reserve price for listed assets, and
bidders publish their bids on the ledger by also keeping the bidding price
secret.

Table 1: Comparison of privacy preservation approaches in blockchain enabled applications Article Name | Use-Case | Scheme | Platform |  | Identity
---
protection
| Data
---
protection
Incentive |  | Privacy
---
Analysis
Pennekamp et al.[29] |  | Supply Chains
---
(traceability)
ABE, CP-ABE |  | Permissioned
---
(Quorum)
N | Y | N | Y
Li et al. [22] | Cloud Computing | Stealth addresses, PC |  | Permissioned
---
(Ethereum J)
Y (partial) | N | N | Y
Gabay et al.[9] |  | Electric Vehicle
---
(authentication )
PC, ZKP |  | Public
---
(Ethereum)
Y | N | N | Y
Jiang et al. [18] |  | Supply Chain
---
(trading)
ZKP |  | Permissioned
---
(Quorum)
Y | Y(partial) | N | N
Benhamouda et al. [2] |  | Supply Chain
---
(auctioning)
MPC |  | Permissioned
---
(Hyperledger)
N | Y | N | Y
S. Jiang et al [17] |  | Supply Chain
---
(database search)
| Bloom Filters,
---
symmetric encryption]
| encrypted database
---
N | Y | N | N
A. Mitani [26] |  | Supply Chain
---
(traceability)
| HMM, ZKP
---
Hommomorphic Enc.
| Permissioned,
---
Permissionless
Y | Y(partial) | N | Y
PrivChain |  | Supply Chains
---
(provenance
traceability)
ZKP, PC, AES |  | Permissioned
---
(Hyperledger)
Y(partial) | Y | Y | Y

###  5.4 Summary and Challenges

In summary, the solutions discussed above address some privacy challenges in
context of blockchains but most of them do not address the problem of privacy
while simultaneously achieving traceability and provenance. The work closest
to the objectives of PrivChain is presented in [29] and [26]. The novelty of
PrivChain stems from its suitability for data protection, provenance and
traceability provision without the need of masking identities, information
managing peers or need for decryption to retrieve provenance information. Some
significant features of PrivChain compared to the work proposed in [29, 26]
are: a) the data always stays with the data owner; b) the verification of
provenance data is pre-computed before a final product is registered, thus
minimising the query time for provenance; c) un-linkability of the trade flows
involved in a final product; d) incentive mechanism for data owners on
providing valid proofs; and e) introduction of minimal overheads to the
baseline system. In addition, the design of PrivChain can be generalised for
any type of data and supply chain use-case. Moreover, Table 1 provides a high
level comparison of PrivChain with the existing literature discussed in this
section. The incentive mechanism is clearly a unique feature of PrivChain
compared to other approaches, which ensures that participants are motivated to
incur the computational cost of providing verified proofs.

##  6 Discussions

In the following sections, we discuss the complexity of using ZKRPs in
blockchain enabled systems and the general application of PrivChain for other
use-cases apart from supply chain.

###  6.1 Complexity of Using ZKRPs for blockchain enabled applications

The computational complexity of the ZKRPs is discussed in Section 2.2.
Moreover, the time complexity is evaluated in Figure 6 which shows that proof
verification overhead of ZKRPs in blockchain, is low. This is because the data
used in ZKRP is numeric and the consensus mechanism of Hyperledger Fabric
(RAFT, Kafka) is not as computationally expensive as Proof of Work. Thus any
consortium based blockchain application can cater to the needs of resources
used for setup (off-chain) and proof verification (on-chain). In addition,
given the proof generation time, resource constrained devices can perform
these computations. However, the willingness for resource consumption for
proof generation is relative to the application scenario. For applications
where the resources may be limited for the end-users, PrivChain incorporates
an incentive mechanism for reciprocation of resource utilization at the user’s
end.

In general, the computational complexity of ZKPs depends on the underlying
variant of zero knowledge proof, data to be used in generation of proofs and
the resources available to end users, which is contingent on the specific
application.

###  6.2 Generality of PrivChain

The proposed PrivChain framework is generic and can be used to prove any
numeric range data stored on a permissioned blockchain without revealing the
data itself. For example, it can be used to prove if the account balances lie
within a certain threshold while making a payment. Alternately, zero knowledge
set membership protocols can be used to prove other non numeric data. For
example credential verification is another application of ZKP which requires a
user to prove their credentials to the requester. Such a credential proving
system is realised by Hyperledger Indy. Recall from Section 1, that PrivChain
framework can be applied in any decentralised application where provenance and
privacy cannot be acheived in parallel. The following use case demonstrates
PrivChain application in energy trading.

Figure 9: A Use-case of Energy Trading

With the advent of IoT and Distributed Energy Resources (DERs), (e.g solar PV,
battery, electric vehicles etc) energy production and consumption load is
widely managed through Peer to Peer Decentralised Energy Trading (P2P DET)[19,
10]. This has given rise to the role of prosumers, i.e. a producer-and-
consumer of energy for example, a residential smarthome equipped with a solar
panel. Blockchain is adopted as a promising solution in P2P DET due to its
salient features such as immutability which could support provenance and
traceability of DET data. To explain PrivChain application in DET, consider a
simple use-case of green energy production by prosumers of smart home. Smart
homes are registered producers of this green energy using different resources
i.e. solar, wind, bio-gas, stored energy etc. as shown in Figure 9. The green
energy is then sold to the micro-grid which further sells it to the energy
consumers. Consumers may be interested to know if the source of energy was
from renewable resources and thus require a proof of provenance. In this
particular use-case, blockchain is an ideal solution to prove the provenance
of the energy resources. However, the prosumers will likely want to hide their
energy production patterns to preserve their privacy, while proving that the
energy provided to the micro-grid is green. The PrivChain framework can be
applied here to hide either the location of smart homes or the type of
renewable energy sources or both using ZKPs. The micro-grid can verify the
proofs and the verification results can be stored on the blockchain for
consumer verification. Following a valid proof verification, the payments plus
proof generation incentives can be provided by the micro-grid through tokens
which could be redeemed from a third party financial institution.

##  7 Conclusion

In this paper, we proposed a privacy preservation framework, PrivChain, for
blockchain enabled supply chain applications. PrivChain aims to protect the
trade secrets of supply chain entities such as the data related to location
and trade flows, without losing the the provenance and traceability features.
To address the data privacy problem, PrivChain uses zero knowledge proofs,
where supply chain entities can share proofs instead of the actual data and
are incentivised for providing valid proofs. In particular, we applied the
PrivChain design on a use-case of wine supply chains. The grape producers
provide location proofs using ZKRPs which ascertain that the grapes are
sourced from a a particular wine-growing region without revealing the precise
location. PrivChain framework also ensures the grape producers are paid agreed
incentive amounts by the wine producers for providing proofs. In addition, to
protect the trade flows involved in the production of a wine bottle, the
respective ingredient identifiers are encrypted by the wine producers. The
implemented framework in Hyperledger incurs minimal overheads for proof
verification, and encryption related tasks. We also performed a qualitative
security analysis with respect to some known threats applicable to the
PrivChain framework. PrivChain framework can be adapted to use ZKRP for
proving many numeric calculations over decentralised applications without
revealing actual data, such as account balances, number of sales, sensor
readings, ratings, etc. For future work, we aim to explore other variants of
zero knowledge proofs such as Bulletproofs.

## References

  * [1] Provenance:every product has a story, 2020.
  * [2] F. Benhamouda, S. Halevi, and T. Halevi.  Supporting private data on hyperledger fabric with secure multiparty computation.  IBM Journal of Research and Development, 63(2/3):3–1, 2019.
  * [3] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, and G. Maxwell.  Bulletproofs: Short proofs for confidential transactions and more.  In 2018 IEEE Symposium on Security and Privacy (SP), pages 315–334. IEEE, 2018.
  * [4] J. Camenisch, R. Chaabouni, et al.  Efficient protocols for set membership and range proofs.  In International Conference on the Theory and Application of Cryptology and Information Security, pages 234–252. Springer, 2008.
  * [5] S. Canard, I. Coisel, A. Jambert, and J. Traoré.  New results for the practical use of range proofs.  In European Public Key Infrastructure Workshop, pages 47–64. Springer, 2013.
  * [6] V. Dedeoglu, R. Jurdak, G. D. Putra, A. Dorri, and S. S. Kanhere.  A trust architecture for blockchain in iot.  In Proceedings of the 16th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services, pages 190–199, 2019.
  * [7] Deloitte.  Continous interconnected supply chains: Using blockchain and iot in supply chain traceability.
  * [8] H. F. Documentation.  Private data.
  * [9] D. Gabay, K. Akkaya, and M. Cebe.  Privacy-preserving authentication scheme for connected electric vehicles using blockchain and zero knowledge proofs.  IEEE Transactions on Vehicular Technology, 2020.
  * [10] K. Gai, Y. Wu, L. Zhu, M. Qiu, and M. Shen.  Privacy-preserving energy trading using consortium blockchain in smart grid.  IEEE Transactions on Industrial Informatics, 15(6):3548–3558, 2019\.
  * [11] R. Gennaro, C. Gentry, B. Parno, and M. Raykova.  Quadratic span programs and succinct nizks without pcps.  In T. Johansson and P. Q. Nguyen, editors, Advances in Cryptology – EUROCRYPT 2013, pages 626–645, Berlin, Heidelberg, 2013. Springer Berlin Heidelberg.
  * [12] L. Guo, H. Xie, and Y. Li.  Data encryption based blockchain and privacy preserving mechanisms towards big data.  Journal of Visual Communication and Image Representation, 70:102741, 2020.
  * [13] D. Hopwood, S. Bowe, T. Hornby, and N. Wilcox.  Zcash protocol specification.  GitHub: San Francisco, CA, USA, 2016.
  * [14] IBM.  Ibm blockchain supply chain solutions.
  * [15] IBM.  Meet the 2020 consumers driving change: Why brands must deliver on omnipresence, agility, and sustainability.
  * [16] C. J. Jensen, D. H. McElreath, and M. Graves.  National geospatial-intelligence agency (nga).  In Encyclopedia of US Intelligence-Two Volume Set, pages 615–615. Auerbach Publications, 2014.
  * [17] S. Jiang, J. Cao, J. A. McCann, Y. Yang, Y. Liu, X. Wang, and Y. Deng.  Privacy-preserving and efficient multi-keyword search over encrypted data on blockchain.  In 2019 IEEE International Conference on Blockchain (Blockchain), pages 405–410, 2019.
  * [18] Y. Jiang, C. Wang, Y. Wang, and L. Gao.  A privacy-preserving e-commerce system based on the blockchain technology.  In 2019 IEEE International Workshop on Blockchain Oriented Software Engineering (IWBOSE), pages 50–55. IEEE, 2019.
  * [19] S. Karumba, S. S. Kanhere, R. Jurdak, and S. Sethuvenkatraman.  Harb: A hypergraph-based adaptive consortium blockchain for decentralised energy trading.  IEEE Internet of Things Journal, 2020.
  * [20] T. Koens, C. Ramaekers, and C. Van Wijk.  Efficient zero-knowledge range proofs in ethereum.  ING, blockchain@ ing. com, 2018.
  * [21] D. P. Leibner and E. T. Lundberg.  Gps spoofing detection techniques, Nov. 28 2019.  US Patent App. 16/532,672.
  * [22] B. Li, Y. Wang, P. Shi, H. Chen, and L. Cheng.  Fppb: a fast and privacy-preserving method based on the permissioned blockchain for fair transactions in sharing economy.  In 2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE), pages 1368–1373. IEEE, 2018.
  * [23] S. Malik, V. Dedeoglu, S. S. Kanhere, and R. Jurdak.  Trustchain: Trust management in blockchain and iot supported supply chains.  In 2019 IEEE International Conference on Blockchain (Blockchain), pages 184–193. IEEE, 2019.
  * [24] S. Malik, S. S. Kanhere, and R. Jurdak.  Productchain: Scalable blockchain framework to support provenance in supply chains.  In 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA), pages 1–10. IEEE, 2018.
  * [25] A. Manzoor, A. Braeken, S. S. Kanhere, M. Ylianttila, and M. Liyanage.  Proxy re-encryption enabled secure and anonymous iot data sharing platform based on blockchain.  Journal of Network and Computer Applications, page 102917, 2020\.
  * [26] T. Mitani and A. Otsuka.  Traceability in permissioned blockchain.  IEEE Access, 8:21573–21588, 2020.
  * [27] E. Morais, T. Koens, C. Van Wijk, and A. Koren.  A survey on zero knowledge range proofs and applications.  SN Applied Sciences, 1(8):946, 2019.
  * [28] T. P. Pedersen.  Non-interactive and information-theoretic secure verifiable secret sharing.  In Annual international cryptology conference, pages 129–140. Springer, 1991.
  * [29] J. Pennekamp, L. Bader, R. Matzutt, P. Niemietz, D. Trauth, M. Henze, T. Bergs, and K. Wehrle.  Private multi-hop accountability for supply chains.  In BIoTCPS (ICC Workshops), 2020.
  * [30] J. Picard.  Digital authentication with copy-detection patterns.  In Optical Security and Counterfeit Deterrence Techniques V, volume 5310, pages 176–183. International Society for Optics and Photonics, 2004\.
  * [31] A. Ranganathan, H. Ólafsdóttir, and S. Capkun.  Spree: A spoofing resistant gps receiver.  In Proceedings of the 22nd Annual International Conference on Mobile Computing and Networking, pages 348–360, 2016.
  * [32] Y. P. Tsang, K. L. Choy, C. H. Wu, G. T. S. Ho, and H. Y. Lam.  Blockchain-driven iot for food traceability with an integrated consensus mechanism.  IEEE Access, 7:129000–129017, 2019.
  * [33] T. Uesugi, Y. Shijo, and M. Murata.  Short paper: Design and evaluation of privacy-preserved supply chain system based on public blockchain.  arXiv preprint arXiv:2004.07606, 2020.
  * [34] H. Wu, J. Cao, Y. Yang, C. L. Tung, S. Jiang, B. Tang, Y. Liu, X. Wang, and Y. Deng.  Data management in supply chain using blockchain: Challenges and a case study.  In 2019 28th International Conference on Computer Communication and Networks (ICCCN), pages 1–8, 2019.

Sidra Malik is a Ph.D. student at School of Computer Science and Engineering,
UNSW and Distributed Sensing Systems Group of CSIRO Data61, Australia. Her
research work focuses on providing solutions regarding traceability, trust and
privacy for blockchain-enabled supply chains . Before commencing her Ph.D.,
Sidra worked as a Lecturer at COMSATS University, Pakistan. She has also been
working as Software Quality Assurance Engineer at Techlogix, Pakistan. She
received her MS degree in Computer and Communication Security from National
University of Science and Technology, Pakistan (2012). Her BS is in Computer
and Information Sciences from Pakistan Institute of Engineering and Applied
Sciences (2009).

###

Volkan Dedeoglu is currently a postdoctoral research fellow in the Distributed
Sensing Systems Group of CSIRO Data61. His current research focuses on data
trust and blockchain-based IoT security and privacy. Volkan also holds Adjunct
Lecturer positions at UNSW Sydney and QUT. Before joining Data61, Volkan
worked as a postdoctoral research associate at Texas A&M University on
physical layer security for communications. He completed his PhD in
Telecommunications Engineering from UniSA (Australia, 2013) on energy
efficient wireless sensor networks, data gathering and target tracking. He
obtained MSc in Electrical and Computer Engineering from Koc University
(Turkey, 2008), BSc in Electrical and Electronics Engineering from Bogazici
University (Turkey, 2006).

###

Salil S Kanhere received his M.S. degree in 2001 and Ph.D. degree in 2003 from
Drexel University, Philadelphia. He is a Professor of Computer Science and
Engineering at UNSW Sydney, Australia. His research interests include Internet
of Things, blockchain, pervasive computing, cybersecurity and applied machine
learning. He is a Senior Member of the IEEE and ACM and an ACM Distinguished
Speaker. He is a recipient of the Friedrich Wilhelm Bessel Research Award
(2020) and the Humboldt Research Fellowship (2014), both from the Alexander
von Humboldt Foundation. He serves as the Editor in Chief of the Ad Hoc
Networks journal and as Associate Editor of IEEE Transactions on Network and
Service Management, Computer Communications and Pervasive and Mobile
Computing. He has served on the organising committee of many IEEE/ACM
international conferences including PerCom, CPS-IOT Week, MobiSys, WoWMoM,
MSWiM, ICBC.

###

Raja Jurdak is a Professor of Distributed Systems and Chair in Applied Data
Sciences at Queensland University of Technology, and Director of the Trusted
Networks Lab. He received the PhD in information and computer science from the
University of California, Irvine in 2005. He previously established and led
the Distributed Sensing Systems Group at CSIRO’s Data61, where he maintains a
visiting scientist role. His research interests include trust, mobility and
energy-efficiency in networks. Prof. Jurdak has published over 180 peer-
reviewed publications, including two authored books most recently on
blockchain in cyberphysical systems in 2020. He serves on the editorial board
of Ad Hoc Networks, and on the organising and technical program committees of
top international conferences, including Percom, ICBC, IPSN, WoWMoM, and
ICDCS. He is a conjoint professor with the University of New South Wales, and
a senior member of the IEEE.