Faculty of Automation and Computer Science

Master Program: Software Engineering

DEMETRA - DECENTRALIZED METERING WITH USER

ANONYMITY ON BLOCKCHAIN

Dissertation Thesis

Author: Mario Vasile, Eng

Supervisor:
Prof. Bogdan GROZA, PhD. Eng.

Timișoara,
June 2018
 2

Abstract 4
Problem Statement 5
The Second Hand Market in Europe 7

Proposed Solution 10
Theoretical Foundation 11
Blockchain technology 11

Blockchain History 11

Blockchain Structure 11

Decentralization 13

Hard forks 15

Consensus 15

The practical byzantine fault tolerance algorithm (PBFT) 15

Proof of work (PoW) 16

Proof of Stake and Distributed Proof of Stake (PoS and DPoS) 17

Blockchain implementations 17

How do we use this in our system 18

Id-Based Cryptography 19

Description 19

How Identity-based signature is used in DEMETRA 20

BigchainDb 21

Tendermint 24

How BigchainDb is used in Demetra 25

QR Codes 25

How QR codes are used in. Demetra 26

Demetra Explained 27
How system works 27

First sale 28

Updating the asset 28

Reselling the asset 29

Data Stored 29

Data 30

Metadata 31

Peer to peer network 32

Decentralized nodes, who keep the Data 33

Public and Private keys used in the system 34

Android application implementation 35

Conclusions and Future Work 45

References 46
List of figures and tables 48
 4

Abstract
Wear and tear are quintessential in establishing the market value of an asset. From shutter coun-
ters on DSLRs to odometer inside cars, specific counters that suggest the degree of wear exist on
most products but malicious modification of the information that they report was always a con-
cern. Our work explores a solution to this problem by combining the Blockchain technology with
ID based cryptography. Merging the two is essential since blockchains facilitate the construction
of a distributed database that is resilient to adversarial modifications, while ID based signatures
set room for a more convenient way to check the correctness of the reported values based on the
name of the product and pseudonym of the owner alone. Since odometer fraud is still a major
practical concern, we discuss a practical scenario centered on vehicles, but the framework is easi-
ly extendable to many other assets.

 5

Problem Statement
Security technologies compensate for the absence of trust. In the second hand market, the
seller is trusted based on his reputation in the system (as implemented on e-bay or similar web-
sites). This reputation system is not friendly for newcomers or for those who are not regular sell-
ers (eg. they sell items only once). The most important aspects when someone is deciding to buy
an item from the second-hand market are the condition of the item and the price. These two are
closely related. The price is set based on the condition of the item, but usually the condition is
very hard to determine. The condition of the item is not only about the visual condition, wear and
tear play a signifiant role in the condition.
The history of a product is provided by the seller as a description written or spoken, but
the problem is that is very hard to prove is the description is real or not. We aim to solve this
problem by providing a system which keeps the history of a product (store metering information
about it) and ensure the data cannot be changed by anyone once submitted. The system developed
will store metering informations about the products. The level of wear, for the cars, this means
the odometer value, for the DSLR camera will be the shutter count, for laptops and mobile
phones can be the battery level or cycle counts. Also the item will contain information about the
initial authorized seller which sold it. The system provides a public database, and all the transac-
tions could be checked. Information about the owner of the asset will not be available and this
makes the data to be anonymous. We started to see this problem in the automotive second hand
market where the odometer tampering is a real problem and through out the paper our focus will
be on this problem. The system can be applied for other markets like DSLR cameras, laptops,
phones, luxury goods etc.
Odometer tampering consist in manipulation of mileage reading shown on odometer. This
manipulation create the impression that the motor of the vehicle has a lower millage than in reali-
ty and because and this leads to an increase of the re-purchase value. This problem is encountered
mostly in countries where the percentage of the resale car is higher. The most affected by this
manipulation are the customers who buy the vehicles, the ones who pay a higher price for the ve-
hicle thinking that the car is not that used.
In the European Union is estimated that between 10% and 50% [1] of the number of cars
traded in the second-hand market are having the odometer modified. The numbers are even high-
er for the cross-border trade because the lack of cooperation on supranational level and insuffi-
cient informations about the history of the vehicle. Cars having rolled-back odometers are esti-
mated between 30% and 40% [1] of the total number of cars traded across borders. These num-
bers show that the problem is widespread across European Union and represent a serious concern,
affecting almost all second-hand car markets.
The customer is affected in many ways, first is the price paid when he buys the car, sec-
ond is the priced paid on the lifespan of the car, a very used car have a higher chance to breaks
 6

down and the cost of the reparation will increase. The safety of road users and the environment
also suffer from this fraud, many of the cars sold should not be used anymore because of the high
usage, these cars encounter more frequent technical problems which results in increasing number
of spare parts produced for an old model of the car. The odometer manipulation has impact also
on the credibility of the market, because this kind of frauds are often, the trust between the seller
of the car and the potential buyer is very low, even if the buyer is honest and the car doesn’t have
the odometer modified.
In the recent years odometer fraud gained more attention from public institutions from
European Union first was addressed in the “Roadworthiness Package” of 2014[2] where the
Member States needed to adopt specific rules for collecting and storing the mileage of the vehicle
at every Periodic Technical Inspection (PTI). The problem remains because the regulation for
making the first PTI of the new vehicle which states that the first PTI for a vehicle should not be
made later than 4 years. Member States can decide when the first PTI should be made with the
condition that is not later than 4 years, this period is considered an issue.
The “Roadworthiness Package” was followed by Regulation (EC) No 2017/11512 [3],
which entered into force in June 2017. This require that the car manufacturers to come with a se-
curity mechanism to stop reprogramming the odometer. The car manufacturer is expected to
come with implementation for systematic anti-manipulation of the odometer, and this implemen-
tation must be approved by the relevant European Commission-type approval authority.
Others country from Europe implemented extra regulation on top of the ones from Eu-
ropean Union, a good example for this represents Belgium and Netherlands. They implemented a
system called “Car-Pass” , through this system every car professional who works on a car or light
van is legally required to send odometer information to “Car-Pass”, then when someone wants to
sell his car, it is legally required to get a “Car Pass” paper which states the current state of the
odometer and give it to the buyer. According to informations from Car-Pass, the system nearly
eradicated the odometer tampering in Belgium and Netherland, the percentage of the unautho-
rized manipulation of the odometer draped from 8.6% to 0.2 in two years since the system is ac-
tive.
 7

The Second Hand Market in Europe

Second hand cars represent the largest number of the automobiles in terms of value and
volume. Compared with the market for new cars, the second hand market is two to three times
bigger (according to BCA European car market). In 2012 the the market for second hand cars
from Germany, Italy, France, Spain and UK accounted 24 millions of used cars and the market
for the new cars accounted 9 millions.

Fig. 1 Trend of the used car markets in EU major markets. Source: https://www.buckingham.ac.uk/wp-
content/uploads/2014/11/pnc-2014-usedcar.pdf

The second hand market has a lowest trust level between other goods markets according
to Consumer Market Scoreboard prepared by the DirectorateGeneral for Health and Food Safety
(DG SANCO) (European Commission, 2014), the figures highlighted in the study show consid-
erable difference between the Market Performance Indicators (MPI’s) [5] for the top and the low-
est ranking Member States respectively.
Based on the DG SANCO consumer survey from above, the traders of the used cars usu-
ally inform verbally the customers about the history of the car, the mileage and if it was involved
or not in a previous accident. A total of 34% of the consumer survey responded that they were not
 8

inform about the vehicle mileage and that they not known that the legislation obliges dealers to
prove the correctness of the odometer readings.
In some EU13 countries, the problem of the odometer tampering reported is higher than in
the EU15 countries. Between 15-20% of all respondents from Romania, Bulgaria, Poland and
Hungary reported experiencing odometer tampering.
The cross-border transactions have proved to be more affected by this problem, most of
the second hand cars sold in the EU13 countries are coming from the EU15 countries, the coun-
tries with the highest proportion of imported second hand cars are: Romania(30%), Malta (27%),
Luxembourg (18%), Bulgaria (16%), Cyprus (15%), Latvia (14%), Poland (13%) and Lithuania
(12%) (European Commission, 2014).
Base on the information from above we can split the European used car market by two
categories, the old members of the European Union (EU15) and and the newer members of the
European Union(EU13). The EU15 group has developed a very strong and competitive used car
sector over the years, the principal countries in this group are Germany, France, Netherlands and
United Kingdom. In these countries people are changing often the car to buy new ones, and this
produce a large number of used cars on the market, most of them fully functional. On the EU13
group the market is increasing, mainly based on the imports from the EU15 countries. The ab-
sence of a well developed car industry in these countries and the lower number of cars owned per
person make that the used market car to be less competitive in these countries.
In the EU15 countries there is often no reliable used car pricing structure, the second hand
cars are usually imported or passed from friends and relatives. Because there is no authority
which validate the history of the car, the millage and previous owners, the market fails to be cred-
ible, the only motivation remains the lower prices and the esthetics of the car. In most of EU15
countries there is a lack of franchised dealers for the second hand market and the transaction are
usually between individuals, this makes the trust between customers and sellers to be very low.
Even if the new car sector is rising and it’s at at peek in history, the used car market is
substantial larger than the primary new car market[8]. An average passenger car has 3-4 owners
before ending his lifetime, and an average ownership of 4-7 years per owner.
The largest exporting countries for used cars are Germany, Netherlands, Italy, and France.
Germany it’s responsible for 2/3 of all used cars in Europe and the largest importing countries are
represented by Romania and Poland. The main feature when people buy used car is consumption
of fuel, and because car industry make major improvements at the engine at every 10-15 years,
the used car markets continues to grow.
 9

Regulations in the EU obliges manufacturers to design and market new vehicles which are
more secured against the odometer tampering (Regulation (EU) No 2017/1151)[9]. With this law
in place, maybe the car manufacturers would want to be involved in keeping the records of the
car in a distributed system, which make the solution proposed to be a possible implementation.
Bellow in fig. 2 is shown promotions of the second hand purchased cross-boarder in EU.

Fig. 2 Proportion of second-hand cars purchased cross-border. Source: European Commission (2014),
Research for TRAN Committee - Odometer tampering: measures to prevent it

Outside Europe, the problem with odometer tampering was addressed by private compa-
nies which store a history of a vehicle and the customer who want to buy an used car will pay for
the car history.
I believe that with the current technology we could eradicate the odometer tampering and
make used car market safe. The technology is available at a resigning price and with a collabora-
tion with the car manufactures the market can benefit for the system for free.
 10

Proposed Solution
We started with the odometer tampering problem in the automotive second-hand market
but the solution can easily be extended to other markets(eg. laptops, DSLR camera, phones).
To resolve the odometer tampering problem, we proposed a decentralized system based
on the blockchain technology, which will provide information about the history of a car, especial-
ly the odometer value at different times. The items will be added in the system by the authorized
seller when these are first sold. The authorized seller will sign the data with his credentials, this
will resolve the problem with duplicates items in the system. All the information stored by the
system will be public accessible and could be verified by the possible buyer from the second-
hand market. The system will keep the record of the car. We use cryptography to make the data
resistant to modification and to provide information about the origin of the asset. The system will
also be distributed, and will be based on a peer to peer communication. Because the system is dis-
tributed it will not have a central authority to hold the data, multiple nodes will store the informa-
tion and the question is who will want to store it. We believe that the car manufacturers will store
the data because they could use the informations(like how many cars are still on the market, how
reliable are the cars, how many services a specific car model made on average) to make reports
informations which are valuable for them.
The assets stored on the blockchain are not linked to the personal information of the own-
er, the owner needs to remain anonymous but to be able to prove that he has the access for the
asset. The owner of the asset can modified further the asset using a pair of public and private key.
Using this pair of keys, he can update the asset or transfer it to another person in case of re-sell-
ing.
As a proof of concept we created an Android app which could be integrated in the info-
tainment system of the car, REST (Representational state transfer) service which communicate
with the Android app. Through the Android app the user will be able to update the asset, to re-
ceive another asset or to transfer the asset to another user. The authorized seller will use the app
to register the asset in the system and to transfer it to the buyer. The REST service will be on
every nodes, the Android will communicate with the REST service in order to register, transfer
and update the asset on the blockchain.
We use different technologies through out the system, technologies such as: Blockchain,
Id-based Cryptography, BigchainDb, Android, Python. Every one of these will be explained in
the further chapters.
 11

Theoretical Foundation
Blockchain technology
A blockchain is a growing list of records called blocks, these blocks are linked by a cryp-
tographic hash. The cryptographic hash function is a mathematical algorithm which take as an
input an arbitrary size string and provide an output of a fixed size string which is unique for that
input. The cryptographic hash is design to be a one way function and is infeasible to invert.
The hash is calculated based on the data from the block and the previous hash of the block, this is
used to keep records in a open distributed ledger. Once the data is recorded is cannot be modified,
if a previous block is modified that leads to alteration of all the block from the one modified until
the present block, this alteration in a distributed system lead to collision with the network.
Blockchains are secure by design and in a distributed system has a high Byzantine fault
tolerance. Decentralized consensus can be achieved and this make the blockchain suitable for
storing records of events, medical records, identity record, assets records, and other data for
which you need to track the history.

Blockchain History
The concept of cryptographic secured chain was described by Stuart Haber and W. Scott Stornet-
ta[10] in 1992. The first blockchain implementation was made by a person or a group of people
names Satoshi Nakamoto in 2008. In the same year Satoshi Nakamoto implemented the
blockchain as a core component of the bitcoin cryptocurrency, the blockchain serves in the cur-
rency as a public ledger for transactions. With the blockchain, bitcoin become the first digital cur-
rency which solved the double spending problem without requiring a trusted authority. The words
block and chain was used separately in the Satoshi Nakamoto’s original paper, but were popular-
ized in a single word by the public. The name of Blockchain 2.0 refers to the new applications
which are using the blockchain database, and it first appears in 2014[12]. Blockchain 2.0 have
increased capabilities from the previous version by adding the “smart contracts”, this enables the
exchange of the value without having intermediaries. The blockchain 2.0 offer possibility to store
individual persistent Id and has the potential to change the way wealth is distributed.

Blockchain Structure
The blockchain is a decentralized distributed and public ledger, which is used to store transac-
tions. Because of the decentralization the history cannot be altered without changing the further
nodes and create collision with the network. A blockchain database is managed autonomously in
a peer-to-peer network and a distributed timestamping server. The blockchain as the name sug-
gests it’s a chain of blocks, where every block contains data and the hash of the previous block.
 12

Blockchains can be public or private. In a public blockchain each transaction is validated by its
users. Users which store the blockchain and validates transactions are usually called miners. In
the blockchain the current value is calculated by looking on all the previous blocks, because of
this and the decentralized validation system, the problem of double spending is solved. Each
block from the blockchain contains two parts: the hash of the previous block, and the data. The
hash of the block is computed over the data field plus the previous hash, this ensure the integrity
of the history until the first block named genesis block. In Bitcoin the block contains an arbitrary
integer called nounce which is necessary for the proof of work algorithm, a header and the rele-
vant transaction data. The header from the block will contain the root of a Merkle tree, obtained
from the hashed of every transactions which are included in the block, this make the validation of
the transactions very easy. Even the smaller change in a transaction will lead to changing the
Merkle tree root which means changing the header of the block. This will lead to invalidation of
the block by other miners from the network[11].
The blocks can have any size, for example Bitcoin blocks can hold only 1 Mb through
which encapsulate an average of 1800 transactions[13]. The size of the block is determined in the
system specification, this is direct related with the number of the transactions per seconds.
An exemplification of a blockchain can be seen in the fig. 3. Every blockchain has a gen-
esis block, the first block from the chain. All the hashes from the blockchain will be linked to the
first block. Every block is linked to the previous one by a cryptographic hash. The cryptographic
hash function it’s a mathematical algorithm which maps data of an arbitrary size to a fixed string
named hash. These are designed as a one-way function type which is infeasible to invert. The
only way to recreate the input data from a hash is to try all the possible combination with a brute-
force attack, but since the input can be of an arbitrary length this makes the functions to be infea-
sible to invert.

Fig. 3 Visual illustration of a blockchain

Sometimes separate blocks can be produced in the same time, this leads to a fork of the
blockchain. Because this problems will happen in real life application, the blockchain store an
extra field for versioning, each implementation of blockchain will choose it’s own algorithm for
increasing the version. Peers who store the blockchain will look into the version and will store the
 13

blockchain with the higher version from the network, and blocks which are not selected by all
peers are called orphan blocks. When the peers receive a high scoring blockchain version, usually
it’s only a new added block to the blockchain, they check if the transaction is valid and in case
the response is positive they send the updates to other peers, they need to make sure that they
have the higher version of the blockchain. Because of the version system on the blockchain, we
can never be absolutely sure that a certain block will remain in the best version of the history for-
ever. Because the blockchain are build to add the score when new blocks are added and not for
changing the old blocks, the probability that a specific block to remain on the master version in-
crease exponentially with the number of blocks added after him, with more blocks added on that
blockchain the chances for that block to be on a wrong version of the blockchain are becoming
very low.
The blockchains can be public or private, depends on the system needs. In a public
blockchain everyone is able to write to the blockchain, and also everyone is able to become a val-
idator in the network, to participate in the consensus protocol. In a private blockchain one can
join if is invited by the network administrator, participating and validating access is restricted.
In our research we will use a private blockchain, where are some rules for validating and adding
data to the blockchain, this rules will be discussed in the following pages.

Decentralization
Storing the data across a peer-to-peer network makes the blockchain to be more safe, it
removes the problem of a central point of failure. The decentralized blockchain may use add-hoc
messages to pass informations between peers. Blockchain security models imply using the pub-
lic-key cryptography, data is sign with a private key and the signature can be validated by the
public key. A private key is like a password, it give access for that owner do sign blocks, which
will be registered in the blockchain. A decentralized system has advantages upon a centralized
one, and probably the most important one is the missing of a single point of failure. Decentraliza-
tion is decreasing chances to loose the data, but to be sure that no-one modify the data, decentral-
ization is not enough. The system must be decentralized but we must be sure that no-one in the
system has the majority of nodes, this may imply that the owner could modify the data. We need
to make sure that no-one will hold the majority in the system, and we will handle this by a voting
mechanism supported by the framework. Every new node must be approved by the majority of
the other nodes in order to enter in the system. By choosing carefully first set of nodes we can be
sure later that there will be no-one to control the whole network.
 14

A visual representation of a centralized system and a decentralized one can be seen in the fig.4
bellow.

Fig.4 Visual representation of a centralized system and a decentralized one

The main differences between centralized system and decentralized systems are:
• Point of Failure/Maintenance: Centralized system are easy to maintain because they have a
single point of failure, decentralized system have multiple nodes but still a finite number
• Scalability: Centralized system have a low scalability, distributed systems are more scalable
than those centralized.
• Fault tolerance/Stability: Centralized systems can he very unstable, once the main node is
down is chaos. If a node fails from a decentralized system there is nothing to worry, the sys-
tem will continue to work.
• Ease of development: Centralized systems are easy to develop, you can use different frame-
works which will help you. Decentralized systems are a little hard to develop, the systems
need to work at a lower level in terms of resource sharing and communications.
• Evolution and Diversity: Centralized systems fallow a single framework, they can be devel-
oped fast using the same framework but they lack of diversity, the decentralized system since
will evolve hard from the beginning until the infrastructure will be in place, but after that
everyone could create services on top and the evolution will be faster than the centralized sys-
tem.
 15

Hard forks
A hard fork usually is made when a big part of the network want to change the validating system,
and the blocks generated by the old rules will not be accepted anymore by the validators which
implies the new rules. We use Tendermint protocol and hard forks are not likely to happen to our
system, in the Tendermint protocol rules can be changed by proposing new rules and the valida-
tors can vote for accepting the new rules or not. A hard fork can still happen if some of the valida-
tors decide to make new rules and the majority is not with them. If a hard fork will happen we
can be sure that the validators are less hen 2/3 of the total number which will be considered a
small minority.

Consensus
The decentralization of the blockchain solve the problem of single point of failure, and
hacking a decentralized blockchain system is a lot harder than hacking a single database. For the
system to work a consensus must be achieved by the members of the network regarding the new
blocks. In a traditional centralized database the system is the one who decide who will write or
not on the database based on some business logic, on the other hand in the blockchain world the
users are unknown and untrusted.
Because anyone individual or party in the blockchain can submit information it is necessary for
the distributed operators of the blockchain to evaluate and agree about the new blocks which will
be added to the blockchain. Because we cannot trust the author of the data it is necessary for the
integrity of the blockchain that all new informations to be reviewed and confirmed before com-
mitting to the blockchain.
Depending of the type of the blockchain (public, private) and the field where the
blockchain is applied, different algorithm for consensus can be implemented. There are mainly
four main methods for consensus in the blockchain world and in distributed systems. The four
are: the practical byzantine fault tolerance algorithm (PBFT), the proof-of-work algorithm
(PoW), the proof-of-stake algorithm (PoS), and the delegated proof-of-stake (DPoS).

The practical byzantine fault tolerance algorithm (PBFT)

The PBFT algorithm was designed as a solution for a problem presented as an allegory:
“Imagine that several divisions of the Byzantine army are camped outside an enemy city, each
division commanded by its own general. The generals can communicate with one another only by
messenger. After observing the enemy, they must decide upon a common plan of action. However,
some of the generals may be traitors, trying to prevent the loyal generals from reaching agree-
ment. The generals must decide on when to attack the city, but they need a strong majority of
their army to attack at the same time. The generals must have an algorithm to guarantee that (a)
all loyal generals decide upon the same plan of action, and (b) a small number of traitors cannot
 16

cause the loyal generals to adopt a bad plan. The loyal generals will all do what the algorithm
says they should, but the traitors may do anything they wish. The algorithm must guarantee con-
dition (a) regardless of what the traitors do. The loyal generals should not only reach agreement,
but should agree upon a reasonable plan.”[14]

In our case to clarify a little bit the allegory from above, generals are the ones who are
holding the blockchain (ex. Manufactures of the car, statistics institutions, etc), the messengers
they are sending between them are the communication across the blockchain. The goal of the
“loyal generals” is to accept only valid blocks on the network. Loyal generals are faithful partici-
pants to the network which want to ensure the integrity of the blockchain and they need to make
sure that wrong informations are not passed on the network. The traitors generals are the one who
want to hack the blockchain, maybe they want to spend money which they don’t have or maybe
they want to rewrite the records to modify the history, or in our case someone who want’s to
modify the odometer with a lower value in order to be trusted by the customer.
The PBFT algorithm in a simplified version can be saw like this: each validator (“gener-
al”) holds an internal state, when he receive a message that a new block is proposed to be added
to the network he will make a decision based on that block and broadcast his decision to the net-
work to all validators. A consensus decision is made by the votes of the validators. For a message
to be committed it need that at least 2/3 of the validators to agree on the block. Examples of
projects which are using the PBFT algorithm are: Tendermint, Hyperledger, Stellar and Ripple.
The blockchain technology used for the proposed system is named BigchainDB and it’s using the
Tendermint for achieving consensus. The Tendermint consensus is explained under the
BigchainDb chapter.

Proof of work (PoW)

The most known method for reaching consensus is the proof of work protocol. The con-
cept of proof of work was presented in a journal article in 1993 by Cynthia Dwork and Moni
Naor [12]. The proof of work cousins in resolving a problem using your cpu/gpu and return the
response to the server in order to be validated. The problems used usually are easy to validate but
hard to resolve, example is finding a certain hash for a string input, once you founded is very
easy to validate the result. There are two variants of the PoW protocol: Challange-Response and
Solution-verification.
The Challenge-Response protocol assume that is a direct communication channel between
the requester or client and the provider or server. The server choose a challenge and send it to the
requester, the requester resolve the challenge and send back the response, if the response is valid
the server grant access for that client. Because the challenge is chosen by the server when the re-
quest is coming is hard to predict which challenge you need to fulfill as a client. This is used
mainly to block denial of service attacks.
 17

The Solution-verification protocol doesn’t assume that a direct communication channel

exists, the problem must be self-imposed before a solution is sought by the requester. Provider
must check both the problem and the solution. This type of solution-verification protocol is used
by Bitcoin, the miners (validators) are searching for a certain type of value that when is hashed
with SHA-256, the hashing begins with a specific numbers of zero. The average work is expo-
nential with number of zero required and the verification is just by computing one hash over val-
ue. The first who will find the answer will create the blockchain and send it to the network, the
network will validate the solution and if the solution is good and the block contains valid transac-
tion will get the new block and put it on their blockchain.

Proof of Stake and Distributed Proof of Stake (PoS and DPoS)

Another variation for establishing consensus is the Proof of stake (PoS) algorithm. In the
PoS algorithm the hash function calculation is replaced with a simple digital signature which
proves the ownership. An individual is selected by the network, instead any individual competing
against each other to complete a problem. The selected individual needs to confirm the validity of
the transaction based on his current stake from the network (if he tries to lie, the others from the
network will figure out and he will loose his stake). The network will choose randomly an indi-
vidual based on his stake, and the one who will validate the transaction will receive an amount of
the stake. There are many variations of this algorithm, because the system must be developed in
such a way that it will not reward only the ones which have the largest stake. One of the most
used methods for establishing consensus in a PoS way is called delegated proof-of-stake system
(DPoS) where every member can choose between validating the transaction on their own or join-
ing to an entity. By joining to an entity this so-called delegates nodes, he can compete with the
ones who have a large stake. This come with the cost of centralization but the algorithm remains
open to modifications
This are principal algorithms used to achieve consensus, this are very different not only in
the details of the implementation and also how they could handle potential attacks. The systems
that don’t use the proof of work algorithm to establish consensus are often call virtual mining. It’s
hard to say that solving a work problem has a security advantage.
In the system proposed we use a PBFT algorithm to establish consensus between different
nodes. This is implemented using the Tendermint library and is supported in the BigchainDb.

Blockchain implementations
Maybe the most notorious implementations of a blockchain are Bitcoin and Ethereum. I
will explain bellow some key features for both Bitcoin and Etherum and some differences be-
tween the two.
 18

Bitcoin was first introduced in 3 January 2009 by an anonymous person named Satoshi
Nakamoto in the paper named “Bitcoin: A Peer-to-Peer Electronic Cash System”. The paper pro-
posed an electronic currency where every transactions are stored in a public ledger using
blockchain. Communication will be based on a peer-to-peer architecture. Bitcoin is a decentral-
ized digital currency through which a person could send money to anyone in the world nearly in-
stant. Bitcoin resolve the current problem from the monetary system where a trust entity handle
the volume of the money in the market. The volume of bitcoin is fixed at 21 millions. Without a
central entity to control the currency, we can observe some benefits like:
• Not requiring any id to make a transaction. This can be used by anyone in the world, it
doesn’t require any infrastructure
• Permission-less and borderless. The software can be used by anyone
• Transactions are censorship-resistant meaning that no-one can block or freeze a transaction
• Online available all the time
• Bitcoins are easy to protect and hide. Can be encrypted on hard-disk or printed on paper
• Cannot be printed or debased. An fixed amount of 21 million bitcoins will be issue based on
an open source algorithm, at a described rate
• You are the direct owner of the bitcoins, no one need to keep it for you

Ethereum is implementing the blockchain 2.0. It is a digital cryptocurrency like Bitcoin,

with similar proof-of-work algorithm for validating transaction. While Bitcoin was created as an
alternative for money, Ethereum has a larger spectrum and can be applied to a broader kinds of
applications. The Ethereum network introduce among the currency, features like “Smart Con-
tracts” and distributed apps. The main focus of Ethereum is not to establish a payment alternative,
but to provide a medium for developers to create distributed apps which can run on the Ethereum
network. Distributed application created by the users of the network can run inside Ethereum. In
order to run an application you will need to pay for it, every developer decide what is the price to
run the application once, if you would want to run the app you must pay the price set by the de-
veloper. Ethereum block time is signifiant less than the Bitcoin, a transaction in Ethereum net-
work is fulfilled in couple of seconds while in the Bitcoin network, the transaction is confirmed
in couple of minutes. Another important feature for Ethereum is the proof-of-work algorithm,
which require large amounts of memory, this make it to be ASIC (specialized processors used to
mine Bitcoin) resistant.
How do we use this in our system
We use store the data in our system using the blockchain architecture. Every transaction is
linked by the previous one. We propose a decentralized blockchain which holds metering infor-
mation about a product, and is publicly available. We use blockchain because it provides features
which are suitable for our problem (e.g. resistance for data modification, distributed among dif-
ferent nodes, data replication, easy to track an asset).
 19

Id-Based Cryptography
Description
The concept of id-based cryptography was introduced in 1984 [17] by Api Shamir. The
key feature for this concept was using the identity from the real word in cryptography, for encryp-
tion and signature verification. The identity from the real world could mean a person email ad-
dress, phone number, passport id. This reduce the complexity of a cryptographic system, being
easier to verify the signature. The idea behind the id-based cryptography was to eliminate the ex-
change of the public keys between systems. The scheme will need the existence of a third party
key generation center, the only purpose of this center will be to provide a private key for every
new member of the network. Every user from the network will have a public and a private key,
the public key will represent his id from the real world (e.g. email, phone number) and the private
key will be generated once by the trusted key generation center. Once the private keys were gen-
erated, the network will not need the key generation center, it could run independently in a decen-
tralized way. The scheme is ideal for large corporations with multiple branches where the head-
quarter could be used as a key generator center, and every employee could get his private key
from it. The scheme could also be practical at a national level where it could replace the current
system from id generation. Everyone from the system could get an electronic id containing the
private key, which could be used to sign legal documents.
The scheme is based on a public key system, with a small modification. Instead of a ran-
dom generation of public and private key, the user of the system will use his name or a unique
combination for him to be identified in the real word, as a public key. Any combination of name,
email, social security number, phone could be used. The key generator center will provide a pri-
vate key for his identity. An identity-based scheme is similar with the mail system. In order for
you to send a message to a friend, you will need to know his email address and you are sure that
once the message sent, he is the only one who can read it. In id-based scheme when a user A send
a message to a user B, he signs the message using his secret key, encrypt the data using B public
key. When B receive the message, he will use his private key to decrypt the message and can ver-
ify A signature using A public key.
Identity-based signature
An identity-based signature scheme is a collection of four algorithms:
• Setup: Is the algorithm run by the key generator center in order to generate the master secret.
It will take as an input a security parameter and generate a public parameter and a master se-
cret. The entity will publish the public parameter and will keep the master secret.
• Extract: This is the process which will generate a private key for a user. The key generator
center will use the identity of a user, the params, and the master key to generate a private key
for the user and will distribute this to him.
 20

• Sign: Is the algorithm used by the user in order to sign a message. The message is sign with
his private key and could be verified with his identity
• Verify: The algorithm will verify if a message was written by a user. The algorithm will take
as an input the signature, the message and the id of the user. This will return true if the signa-
ture belong to the user or false if not.
A visual exemplification of the Identity based signature can be seen in the figure below.

Fig.5 Visual exemplification of Identity based signature, source: Identity-Based Cryptosystems and Sig-
nature Schemes, Adi Shamir

How Identity-based signature is used in DEMETRA

When a user buy an item, the authorized seller will register the item in DEMETRA. The
authorized seller will add identification information about the produce (e.g. serial number, manu-
facturer, model, production year, date of the sale). He will also add his identity(name or company
id) and sign this block of data with his Identity based secret key. This will help later other users to
verify the validity of an item in the blockchain in case of collusion (e.g. another item with the
same serial number is on blockchain, maybe an attacker introduce it). Identity-based signature
increase the trust for the assets from the network.
 21

BigchainDb
BigchainDb is an open source software which provides features from the blockchain
world combined with the ones from a database. The BigchainDb project started in February 2016
[15]. It was design at the beginning as a database with some properties from the blockchain. First
version of the BigchainDb had different issues like the system could not withstand arbitrary fault,
is wasn’t Byzantine fault tolerant, the internal database had a master node which made all the
writes, the other nodes just replicates from the master one, master node was a single point of fail-
ure. The current implementation of the BigchainDb (2.0) was designed to solve all of these prob-
lems and in the same time maintaining the core properties unmodified.
BigchainDb combines properties from the blockchain with the ones from the database
world. The properties are:
• Decentralization
• Byzantine Fault Tolerance
• Immutability
• Owner-Controlled Assets
• High Rate Transfer
• Low Latency
• Indexing and Querying of Structured Data

The new version, BigchainDb 2.0 is full decentralized and Byzantine Fault Tolerant. Each
node has a local instance of MongoDb installed, and all the communication between nodes are
made using Tendermint protocol. We explain in a separate chapter the Tendermint protocol. Since
the system is decentralized and use the Tendermint protocol to communicate between nodes if an
attacker will break a node and get a full access to the MongoDb, he will not be able to modify the
data from other nodes, in worst case scenario he can delete the local instance of MongoDb. Ten-
dermint still has a master node but this master node is changed at every round of validation in a
random way. If the nodes are run and owned by different persons or entities it means that the sys-
tem is decentralized and it has no single owner. In an ideal situation the nodes would be located
in many countries have different legal jurisdictions and different hosting providers, so if a prob-
lem will affect one of them the system will keep up running without a problem.
Because BigchainDb has the properties of a blockchain, once we store something in the
system, we cannot delete it or change it without controlling the two thirds of the network nodes.
All the transactions from the BigchainDb are cryptographically signed. After a transaction is
store, if someone will change the data from it, the signature for that transaction will be changed
which can be detected by the network.
In the BigchainDb every asset has an owner. Only the owner of the asset can update the
asset or transfer it to another user. A owner in BigchainDb is represented by a pair of public and
private keys. In other blockchains like Ethereum or Bitcoin, the network provide only one type of
 22

asset e.g Bitcoin, or ether but in the Bigchain every owner can create different assets and can is-
sue as many as they need. For example a user named Joe could create 1000 tokens and he will
sign all the 1000 tokens with his own private key. He than could send the tokens to another user
by making a transfer transaction and including the public key for the new user. BigchainDb
checks every transaction to prevent double spending situations.
Blockchains which are using Tendermint implementation for consensus have a low laten-
cy and fast acceptance for transactions. Usually it takes only a few seconds or less for a transac-
tion to be committed on the blockchain. Once the transaction is on blockchain, there is no way to
revert it. Bellow it’s an example of 4 nodes which are running BigchainDb.

Fig.6 Example with 4 nodes running BigchainDb. Source BigchainDb WhitePaper, https://
www.bigchaindb.com/whitepaper/bigchaindb-whitepaper.pdf

Because it has properties from a database system, the transactions rate per seconds are
very high. At the moment of writing this paper, the BigchainDb team hasn’t released any perfor-
mance benchmarks about this property. Since the BigchainDb is based on Tendermint we can
look to other Tendermint based networks for performance benchmarks. One network which is
using Tendermint is called Cosmos and according to their white paper [16]:
“Despite its strong guarantees, Tendermint provides exceptional performance. In benchmarks of
64 nodes distributed across 7 datacenters on 5 continents, on commodity cloud instances, Ten-
dermint consensus can process thousands of transactions per second, with commit latencies on
the order of one to two seconds. Notably, performance of well over a thousand transactions per
second is maintained even in harsh adversarial conditions, with validators crashing or broadcast-
ing maliciously crafted votes.”
 23

Indexing and querying data from a node is very easy since the database is build on a
MongoDb cluster. Each node can provide it’s own way to expose the data to the users. The trans-
actions are stored in a JSON format. By default BigchainDb provides a HTTP API which in-
cludes some basic query methods.
Others blockchain networks like Bitcoin or Ethereum allow anyone to enter in the net-
work. This brings the concern that someone could enter in the network with bad intentions, he
could add so many node, increasing the size of the blockchain at a level which it’s not feasible to
maintain. This type of attack is called Sybil and networks like Bitcoin and Ethereum defend
themselves by having fees for writing in the blockchain. In the BigchainDb, Sybil attacks are not
an issue since the nodes have control over the member list.
Bigchain Transactions are written in a JSON format. At the moment of writing this paper,
BigchainDb supports 2 version of transactions (v1 and v2). Since we use the BigchainDb version
2.0, the supported transactions for this version are v2 type. For constructing the BigchainDb
transaction we used the python sdk.
Every transaction need to be signed by the user private key. The public key of the user
will be inside the transaction. Every transaction can be validated with the public key. An example
of a valid transaction can be see bellow.

Fig.7 Transaction structure in BigchainDb

 24

Tendermint
Tendermint is a consensus algorithm for replicating securely an application on many ma-
chines. The consensus algorithm will work even if up to 1/3 of machines fail in arbitrary ways.
The algorithm is consistently, which means that every non-faulty machine will see the same
transaction log and computes the same state. The fundamental problems in a distributes system
are secure and consistent replication. If a system has the ability to tolerate machines failing in ar-
bitrary ways, we say about that system that is Byzantine fault tolerance. The blockchain is an im-
plementation of the BFT and the blockchain data structure actually optimizes BFT design.
Tendermint has two main technical components:
• blockchain consensus engine
• generic application interface
The consensus engine, is called Tendermint Core and ensures that the order and data of
every transaction are recorded on every machine.
The application interface is called the Application BlockChain Interface (ABCI) and en-
ables a transactions to be processed in any programming language. Developers can use Tender-
mint to achieve a BFT system using any programming language.[18]
Tendermint consensus can be seen in the fig. 8 bellow.

Fig. 8 Tendermint consensus diagram, Source: https://tendermint.readthedocs.io

Participants in the protocol are the validators of the network, they are proposing and vali-
date blocks in order to save informations to the blockchain. Every block in the chain have height.
The round starts with one validator proposing a new block to the network, after proposing the
block, two stages of voting is required to successfully commit the block. First stage is called Pre-
 25

vote and if 2/3 of the validators vote for the same block in the Prevote stage than it’s passed to the
next stage. The second stage is called Precommit and it similar with the Prevote stage, if 2/3 of
the validators approves the block in this stage, the block is committed to the blockchain. After a
block is committed to the blockchain, the height is increased and another validator will have the
chance to propose a block to the network. Validators may fail to commit a block for different rea-
sons, maybe the chosen validator goes offline, or the network is slow and he got the message to
late. Tandermint allow that a validator to be skipped. Tendermint guarantees the integrity of the
blockchain and that the safety will never be violated with the exception when more than one-third
of the validators are Byzantine.

How BigchainDb is used in Demetra

The proposed system is using BigchainDb to store the assets, transfer and update it.
BigchainDb provides 2 officials SDK to build transactions, a Python sdk and a Javascript. We
used the python SDK to interact with the BigchainDb nodes. In order to communicate with the
Android application, we implemented a REST API in Python. All the interaction with the
BigchainDb is made through the Python REST API. We are highly dependent on the BigchainDb
and we choose to used this system because it field the needs for creating, transferring and updat-
ing an asset without the need for a certain fee, it’s open source, which means we could further
implement our own version from it.

QR Codes
QR codes are an abreviation from Quick Response Codes and it’s a type of matrix bar-
code designed in 1994 for the automotive industry in Japan. A barcode is a special type of label
which can be read by machines. A QR code can use one of four standardized encoding modes:
kanji, numeric, alphanumeric, byte/binary. The QR code standard become popular outside the au-
tomotive industry because provides a greater storage capacity compared to UPC barcodes and
also provides a fast readability.
The QR code system was first introduced in 1994 by the company Denso Wave from
Japan. It’s first purpose was to track a vehicle during the manufacturing process, it was designed
to be read by a high-speed scanning component. Currently the QR code is widespread across dif-
ferent domains, from commercial tracking like postal system, to customer oriented applications
like accessing urls. QR code can be used to display text, to open URL, to compose emails or to
access private wi-fi networks.
There are couple of types available:
• Model 1 and Model 2. Model 1 is the original QR code. It can be sized up to the number 14
(73 * 73 modules) which can store up to 1167 numerals. Model 2 is the next generation of
 26

Model 1 and has an increased size up to 40(177 * 177 modules) and can store up to 7089 nu-
merals.
• Micro QR code. This code has only one orientation, this make it possible to be printed in a
smaller version. This can store up to 35 numerals.
• iQR code . This can be generated as a square module or as a rectangular one. The maximum
version can store up to 61(422 * 422 modules), approximately 40000 numerals
• SQRC. A special type of QR code which have some reading restriction. It is used to store sen-
sitive data. As appearance is not different from a normal QR code
• Frame QR. This QR code has a special canvas area where can be drawn anything. This is
mainly used for marketing campaigns
In crypto currency world the QR codes are the main way to communicate with other
users. If you would want to send money to a use, usually you will need his address which in most
cases is long and hard to manually copy therefore this can be stored as a QR code. An example of
a QR code can be seen bellow.

Fig. 9 Qr code example

How QR codes are used in. Demetra

We use QR codes to pass public keys and asset id between users. Once an authorized sell-
er will sell an asset, it will register that asset on the blockchain and transfer it to it’s user. In order
to transfer the asset, the authorized seller will need a public key, he will scan the QR code gener-
ated by the feature owner. After the transfer, authorized seller will generate a QR code which in-
clude the asset id, the user will scan the QR code of that asset and it will store the id in the phone
for feature updates. If a user re-sale his asset, in order to transfer the asset will scan a QR code of
the future owner, the QR code will contain the public key for the asset to be transferred.
 27

Demetra Explained
How system works
Decentralized Metering with User Anonymity (DeMetrA) is a system which stores meter-
ing information about assets and provides the history for potential buyers from the second hand
market.We use BigchainDb as a database to store the information. BigchainDb is a blockchain
database, which means the data stored is resistant to modification. The system is distributed
which means that same database will be replicated across different nodes. An overview of the
system can be saw in the figure bellow.

Fig. 10 Demetra system overview

In the figure 10 is shown an overview of the system. The first step in the lifecycle of the asset on
the blockchain is to be registered on the network. There are couple of steps through which an as-
set pass:
• First sale. The asset is first sold to the person by an authorized seller
• Updating the asset. The owner update the asset periodically with metering values
• Reselling the asset. The asset is sold by the owner to another person
• Updating the asset. The future owner update the asset further
 28

First sale
The process starts when a person will buy an item from an authorized seller, the seller will
ask the person if they want the product to be stored on the blockchain. If the person will approve
that, the authorized seller will make a transaction to one of the nodes from the blockchain. Every
node from the blockchain expose a REST (Representation State transfer) API, through which the
common actions are made. The first transaction for an asset in the blockchain will be a “Create”
transaction and will contain identification informations for the asset like manufacturer, model,
model year, meter unit type, seller name (which state also for a public key), date of sale and the
authorized seller signature. After the item is created on the network, the authorized owner will
scan the public key of the person to who just sold the product and will initiate a transfer transac-
tion for that public key. In the blockchain, a transfer transaction will be visible from the autho-
rized seller to the owner public key. The owner’s public key is a random string and doesn’t link in
any manner to the person real identity. The authorized seller will provide on a paper support the
asset id stored in the blockchain as a QR code.

Updating the asset

In order for a person to have control over an asset in the system, he will need to generate a
pair of keys (public and private) with the scheme Edwards-curve Digital Signature
Algorithm (EdDSA) specifically Ed25519[19]. He can use the REST api from a node to generate
this pairs or it could generate himself. In order for the asset to be transferred from the authorized
seller to the customer, the customer must provide a QR code with the public key, which he previ-
ously generated. This QR code can be generated from the Android app designed for interaction
with the blockchain. After the authorized seller will transfer the asset to the owner public key, in
the Android app, user can search for assets which belongs to his public key. Once he found the
asset he can use the app to update the metering value periodically. We build the Android app as a
proof of concept for the system, providing an easier way for the user to communicate with the
blockchain, but the Android app could be replaced with any smart device which has an internet
connection. The user will update the transaction signing the block of data with his private key,
this signature will be verified when the transaction arrive to the node. Only the one who has the
private key corresponding to the public key to which asset is bound, can modify the asset infor-
mation. We use the word modify but because our system use blockchain the modification of an
asset means adding a transaction with the fields modified, all the transactions (history of an asset)
will be public visible and cannot be changed or deleted
 29

Reselling the asset

If the owner decide to sell the item, he could provide his asset id as QR code and the pos-
sible owner can see the asset history stored on the blockchain. The BigchainDb offers also the
possibility to search based on certain fields an asset has, in our case the potential buyer could
search based on the serial number of the car. In case of selling, the current owner must transfer
the asset to the next owner. He would make the same steps that authorized seller did, he will use
the android app to scan the owner public key QR code. Then will create a ‘TRANSFER’ transac-
tion in which he will include the public key of the future owner and will sign the block with his
current private key. After that, the future owner will have control over the asset, and he can up-
date further the asset with metering information.

Data Stored
We want to save a copy of the car on the blockchain, to be accessible by the owner, trans-
ferable from the owner to another persons with owner permission and in the same time we need
to provide value for the validators, the ones which will hold the blockchain. The data will be
stored in a JSON format and we will have mainly two types of transactions: create, transfer.
All the transactions will be made over an asset. We can see our car like an asset on the
blockchain. The asset will be created by the authorized seller when the item is first bought. The
authorized seller will add identification information about the asset and will save it to the
blockchain through one of the REST api provided by the nodes. The authorized seller will trans-
fer the asset to the current owner and then he can modify some fields from the asset, having all
the history of the modifications. The owner will also be able to transfer the asset to another per-
son, if he sell the car. The system provides two types of information which can be stored for an
asset:
• Data
• Metadata
The system stores the data as JSON objects and every transaction will contain a data child
or a metadata child or even both of them. We must explain the transactions before continue. Be-
cause we use BigchainDb all the data which is send to the system are throughout transactions. A
transaction is a JSON object which hold different information described in the specifications pro-
vided by BigchainDb[15]. In the BigchainDb two types of transactions are available:
• Create
• Transfer
The ‘Create’ transaction is used, like the name suggest, to create an asset on the
blockchain. When the asset is created, the transaction will contain the Data field in it and other
informations like the public key of the owner and the number of assets created.
 30

The ‘Transfer’ transaction is used when the owner decide to transfer the asset to another
person or when he want to add more data to his own asset. In case the owner wants to transfer the
asset to another person, he will make a ‘Transfer’ transaction which will contain the public key of
the future owner and will sign the transaction with his private key. In case he wants to update the
asset, it will make a ‘Transfer’ transaction to himself, he will include his own public key in the
transaction and the metadata field. In the table below can be seen which type of data and which
type of transactions need’s to be made in order to make the main actions in the system.

Create transaction Transfer transaction

Add item in the system Data

Update item Metadata

Transfer ownership of the Include the public key of the

asset future owner

Table. 1 Table Relations between action in the system and type of data

Data
The data field is represented as a JSON object. It’s added by the authorized seller when
the asset is first sold. The ‘Data’ field contains identification informations about the asset, if we
take the car as an example, the data filed will contain information like model of the car, serial
number, manufacturer, model year, engine specifications. Beside all of identification information,
the authorized seller will add his name which serves also as a public key in the id-based scheme
and will sign the whole block of data with his signature. This signature is made in case of dupli-
cates in the system, if the same item will have the same identification data, the id-base signature
will prove who was the authorized seller which created the transaction.

Fig. 11 Example of the data field stored on the blockchain

 31

The data field will be contained in a ‘Create’ transaction initiated by the authorized seller. Once
the data field is added to an asset, it cannot be changed or deleted. The data field is locked and
stays as an identification information for the asset, once it was written the owner will not be able
to add more field for this data. The data field can be query by another person, in case he will want
to verify the asset history. All the data stored in the blockchain are public available and
queryable. The owner of the asset will be linked by the data with his public key, but the public
key is a random string and has no linking to the owner identification information.

Metadata
The metadata information will contain metering information of the asset. In case of a car
this will be the odometer value, in case of a laptop, the metering value will contain the battery
cycle count, in case of a DSLR camera, the value of the shutter count will be stored. The unit of
measure for the metering value will be written by the authorized seller in the ‘Data’ fields with
the name ‘MeterUnit’. The metadata is more flexible than the data fields, the user will interact
with metadata structure in order to update the metering information for the asset. The owner will
create a ‘Transfer’ transaction to his own public key and will add the metadata with the new value
inside the transaction. In the system a history of transaction will be available, with the latest
transaction containing the current information of the product. An example of the metadata object
can be seen in the fig.12 bellow.

Fig. 12 Example of private data stored on the blockchain

The metadata fields can be customized entirely by the owner, but in order for the data to have
value for him in case of a reselling, he will need to add the meterValue along with the record date.
From the Android app we provide this functionality for him. Other informations are optional.

The Data and the Metadata provides value for the ones who store the blockchain and vali-
dates the information. This data cam be used to in different way, from the marketing decisions
 32

until the statistics reports which can influence certain laws. If the manufacturers of the cars will
hold the blockchain, they could see how long the car stays on the market, how many miles the
engine resist in the real word, could do some reports to compare the models. The value provided
by the data can also be used by research institutions, statistics institutions and public institutions
which are approved to make Periodical Technical Inspection of the car. This public information
need to be enough for validators to maintain the blockchain, but with the current technology and
because we address large companies and institutions we strongly believe that this would not be an
impediment.

Peer to peer network

A peer to peer network has it’s design around the notion of peer node function simultane-
ous as both “clients” and “servers” to the other nodes in the network. This architecture is different
from the client-server where communication is usually to and from the central server. In the sys-
tem proposed by this paper, the communication is not purely peer to peer, the owner of the car
will send the block to one of the validators available, this will validate the transaction and will
send it further to the network.
The owner of the system could store the blockchain himself. Since there are no fees in
order to interact with the system, an attacker could try to store a large amount of data, making the
database impossible to store or access, this type of attack is called Sybil. The system use Tender-
mint protocol to achieve consensus and the problem of a Sybil attack is solved by voting to block
certain users from the network.
All the nodes (validators) can vote to block a certain public key from writing to the sys-
tem this solve the Sybil attack. In order for a new node to enter in the system, all the other nodes
will vote for him. If the vote will pass the new node can participate for the consensus. The normal
users we believe will not intent to become validators, they will interact with a random node from
the system. We’ve build a REST api on top of the BigchainDb infrastructure which will let the
user to interact easier with the network. The Tendermint algorithm for consensus says that a block
is committed if the validation pass 2/3 of the validators. Currently validators will not verify the
data containing information of the asset like metering values or serial numbers, they will verify if
the signature of the data was made by the owner of the asset.
 33

Decentralized nodes, who keep the Data

The blockchain technology combined with decentralization of the system assure certain
properties like:
• Data resistant to modification
• The history of the asset can be tracked very easy
• Asset ownership. Every transaction is signed with a private key. The nodes verify the signa-
ture using the public key provided in transaction
• Eliminates the single point of failure. The system use Byzantine Fault Tolerant consensus al-
gorithm which means that consensus can be achieved with 2/3 of the network online.

The challenge is to find companies, public institution which will be willing to keep the data. In
order to trust these companies, they should be from different businesses, countries, and competi-
tors.

Fig.13 Visual representation of the decentralization of the system

Because the system is decentralized, we need peers to store the blockchain on their own.
If the system will be wide spread the blockchain size can increase that’s why we would need to
 34

provide value to the keepers. The value for storing the blockchain will be from the public data
which every owner of the asset will share with the network.
There are numbers of way for that data to be used, statistical data from the current mar-
kets for used cars could be used by the manufacturers for producing a certain model of the car in
a larger number, maybe the most reliable car in the market. Data could also be used by govern-
ments to see the trends in the current market and adapt to it. The insurance companies could use
data to see which is most viable car in the market and maybe change the insurance policy based
on this values. The online service for selling products like EBAY, OLX, Shpock could provide a
history of a used asset and make a correlation with the products listed on their platforms.
These are just a couple examples of how the data could be used and why someone will
want to keep the blockchain. The system will be open for everyone, and anyone could actually
keep the data on their servers, but our target will be the manufacturers, the insurance companies
and public statistics institutions, the online platforms for the second hand market.

Public and Private keys used in the system

In the system proposed we use two types of signatures:

• An EdDSA signature used to interact with the BigchainDb
• An Id-based signature used to certify the origin of the Asset

A signature is provided by the BigchainDB where every transaction needs to be signed by

a private key and include the public one for validation. The public and private key used to sign
transactions are based on the Edwards-curve Digital Signature Algorithm (EdDSA)[19] scheme.
The public and private key can be generated offline, and they are attached to an asset when this is
first created. A user of the will generate the public key and the private key on the Android app
and will provide the public key as a QR code to the authorized seller. The authorized seller will
initiate a ‘Transfer’ transaction for that public key. When a transaction will be put on the
blockchain, the protocol from the BigchainDb will verify the validity of the data against the pub-
lic key of the owner. The transaction id represent SHA3-256 hash of the transaction which con-
tains the a signature on all the data with the private key of the owner.
In order to provide the origin of the asset we use another type of signature, an Id-Based
signature. In the Id-Based signature scheme, the public key of a user is his name in the real world,
and the private key is generated by a Key Generation System. An asset is added in the system by
an authorized seller when the item is first sold. The identification information will be sign in the
‘originatorSignature’ field by the authorized seller. The ‘Data’ object will also contain the field
‘seller’ which will contain the name of the seller from the real world (which is also his public
key). With all the information from the data field one can verify if the signature is correct and the
 35

origin of the asset. Only the authorized seller will sign the asset once, in the ‘Create’ transaction,
the future owner will use only the private key for the BigchainDb.

Android application implementation

In order for users to be able to communicate with the system, we created an Android app.
The Android app is just a proof of concept and does not incorporate all the features provided
through the BigchainDb. Because we implemented the app as a proof of concept we structured he
app is in two parts, one for the seller and one for the buyer. In a real life scenario these should be
in 2 separated apps.

Fig. 14 First page of the app

 36

In the figure 14 can be seen the the first page from the app, it shows two options: one for
the authorized seller and one for a normal owner of the asset. Further we will take a look on the
authorized seller scenario. We will see a step by step guide for him to add an asset in the system
and to transfer it to the owner.
First time when the authorized seller will access the application, an screen for setup the
credentials will appear. The seller will be need to fulfill this step in order to be able to add data in
the blockchain. The public and private keys are for the Identity-based signature. The private key
will be provided to the authorized seller by a Key Generator Center.

Fig. 15 Screen for setup the private and public key for Identity-based signature

Because the authorized seller used the Identity-based signature to sign the informations of
the asset, the public key will be his name from the real world. The private key can be introduce
from the keyboard or by scanning a QR code in case it exists. After this step, we will store the
 37

keys in the phone memory using Room, a persistence library which provides an abstraction layer
over the SQL Lite.
The assets list will be displayed for the authorized owner as it is show in the figure 16 bellow. We
can see that currently he has added only on asset to the network. Every asset is identified by an
Asset Id, which is a SHA3-256 hash of the ‘Create’ transaction.

Fig. 16 Assets List from the Authorized Seller

The authorized seller will add an asset when the item is first sold, only with the owner
consent. From the bottom right corner the authorized seller can navigate to the create asset page
where he can add more assets in the network. Every time when a asset is created by an authorized
 38

seller, a new pair of keys (public and private) are generated. With this pair, the authorized seller
will interact with the system for that specific asset.
The assets id are stored locally on the Android app using Room a persistence library
which provides an abstraction level over the SQL lite. The authorized owner can also store the
public key of the asset on a paper as a QR code and in case the transaction id is lost he could
make query to the system to retrieve the asset id.
The asset creation screen can be seen in the figure 17. We’ve build this proof of concept
having the automotive car industry as a foundation. But the information stored can be applied to
other assets such as Electronics, DSLR Camera or any other asset which has a trackable metering
information.

Fig. 17 Create the asset screen

 39

Once the authorized seller agreed with the owner to store the asset in the system, he will
need to fill the form from the fig.14 and press the “Add asset” button. Many of these field can be
predefined but to illustrate the whole process we let them unfilled. After the authorized seller will
full-fill the form and will press the “Add asset” button, the app will calculate the signature for the
form based on seller private and public key provided in the setup phase. All the informations
from the form and the signature will be added to the blockchain. The communication between the
Android app and the blockchain is made through an REST api provided by every node. Every
node will expose a REST api with the same “contract” to communicate with the peers.
After the asset was created, the authorized seller can access it from the app. The screen
which displays the asset information and the action to interact with can be seen in the figure bel-
low.

Fig. 18 Asset details

 40

These are the asset details through which the seller could interact with. The same screen
will be also seen by the owner of the asset. Under the asset details are the main actions for an as-
set available in the application. Every button is explained bellow.

Is the ‘Transfer button’. This will open the

camera in order to scan QR code of public key

This button will display the QR code for the

specific field. This may be an asset id or a public
key

This button will display the history of the asset and

the identification information.

This button will navigate the user to the a screen

where he can update the metering information

Table. 2 Main actions for the asset in the Android app

In normal scenario after the authorized seller created the asset, he will want to transfer it
to the new owner and in this case will press the transfer button. The camera screen will pop-up
and he will need to scan the QR code which contains the public key of the new owner. After a
successfully scan, the app will display the fallowing screen.

Fig. 19 Dialog displayed for transferring an asset to the new owner

 41

The user will be able to verify the public key which he just scanned. After pressing the
transfer button, the asset will be transferred to the new public key and the old owner will not be
able to update the asset anymore. This are the main actions which the authorized seller will per-
form in the system.
The owner of the asset will have a different interaction with the system. In order to receive an
asset he must generate a pair of public and private keys which based on the scheme Ed25519[19].
The user will be able to generate this keys from the Android app. In the figure 18, a list of keys
can be seen and the user can generate more pairs with the button from the bottom right corner.

Fig. 20 Public keys created by the user

All the keys are stored in the phone memory, a QR code can be provided for both public and pri-
vate key and this can be save as a screenshoot and then printed. Under a pair of keys the user can
 42

hold as many assets as he wants. The public key will be displayed on the blockchain, but user
anonymity is persevered since there is no linking between the public key and the owner identity.
For a better security, it would be good if the user will generate a pair of public and private keys
for every asset he posses. In this way even when he will sell an item and the potential buyer will
ask for the asset history and in the same time he will see the owner public key, all the records for
that public key will be regarding the item just sold. After creating the keys, he can access further
in the App to check if any assets are linked by that key. In the figure bellow it can be observed
that the public key is linked in two assets and a button which will display the public key as a QR
code. This action is used by the owner when the authorized seller will want to transfer the item to
him.

Fig. 21 Assets list for a pair of public and private key

The owner can navigate further for every assets, and once he click on an asset, the app will dis-
play the asset details screen presented in the Figure 16. From the asset details screen he can
choose to update the asset, view history or transfer it to another user.
 43

We will explain further how a user can update the asset metering value. In order to do that
he will navigate to the asset details screen and will choose the update asset button presented in
the table 2. After he press the update button, this screen will appear in the app.

Fig. 22 Update asset information screen

From this screen, the one can see the asset details, the last metering value for that asset
and he can add another record. The app is focussed on the car example but this can be easily
changed for other electronics such as laptops, phones, DSLR camera, or even can be made auto-
matically be the manufacturer.
Another screen which is available from the app is the Asset history screen. This will ap-
pear if the user will press the Asset history button (see table 2) or after he updates the value of the
 44

asset. The asset history screen display the data and the metadata stored for the asset in the
blockchain. The history of the asset will presented in the app as it is shown in the figure bellow.
The first card view shows the Data block stored for the asset and bellow is a list with the updates
made over time for the asset. The updates are stored as a Metadata object.

Fig. 23 Asset history screen

We presented the basic action which the Android app is capable of. The entire app was designed
based on automotive use case, but this can be changed in the future to support all other assets.
The Android application is compatible with the older version down to Android 4.0 and it’s
require an active internet connection. For making the app faster we store some informations in
memory, using Room an abstraction layer over the SQL lite.
 45

Conclusions and Future Work

The system that we address provides an efficient way to keep the history of a product by
relying on two modern concepts from cryptography: blockchains and id-based signatures. Users
can trust that the history of the product remains unchanged on the blockchain based on strong
cryptographic guarantees. The history of the product will increase the trust level and potentially
give the owner a better price when he decides to sell it. We believe that the system has value for
both the owner of the asset and for the holder of the database. We are aware that the solution pro-
vided will not fully solve the trust issue since dishonest owners may still find a way to fill false
information about the asset on the blockchain (e.g., cracking the counter report) and a reputation
system may help in this respect.
We believe the system will provide value for both parties involved in the process. The
owner of the asset will have an incentive to update the asset and use the history in case of a re-
sale. The companies who will store the informations could use it to provide reports, understand
better the market and take decisions based on this data. The assets will provide a view of the cur-
rent market for different sectors, and because the user identity is preserved we believe that the
owners will be honest.
Due to inherent space constraints, this small research communication is restricted to the
problem statement and some details on our proof-of-concept implementation. As current and fu-
ture work we pursue the development of specific protocols and procedures for each step and hope
to extend this work as a full research paper.
As for the future, one of the main challenge will be to discuss with online e-commeree
companies , manufacturers and public institutions to see if they are willing to store the data. Inte-
grations with their application may be possible or even integrating the system directly into the
product and providing the history as a feature.
If the system will be implemented, we will need to think to a future version because the
blockchain will grow after years and maybe some of the products will not have any value even if
they have the history on the blockchain. One possible way will be to reset the blockchain and af-
ter a certain amount of years. This will reduce the storage, and will provide informations only for
the products which are still in the market.
As a feature can also be implemented different applications or protocols which could be
user by manufacturer to include in the products in the fabrication process. This will enhance the
security of the data stored in the network, but it is harder to be adopted as a standard by the man-
ufacturers.
 46

References

[1] Research for TRAN Committee - Odometer tampering: measures to prevent it, http://www.eu-
roparl.europa.eu/RegData/etudes/STUD/2017/602012/IPOL_STU(2017)602012_EN.pdf
[2] The “Roadworthiness Package” consists of three Directives: 2014/45/EC of the European Par-
liament and of the Council of 3 April 2014
[3]Commission Regulation (EU) No 2017/1151 of 1 June 2017, supplementing Regulation (EC)
No 715/2007 of the European Parliament and of the Council on type-approval of motor vehicles
[4]The Consumer Markets Scoreboard surveys consumers with recent purchasing experiences in
order to track the performance of over 40 consumer markets.
[5] The ‘Market Performance Indicator’ (MPI) is a composite index taking into account five key
aspects of the consumer experience: comparability, trust, expectations, choice and overall detri-
ment.
[6] EU13 The Member States which joined the EU after 2004
[7] EU15 EU Member States before the 2004 enlargement
[8] Data gathering and analysis to improve the understanding of 2nd hand car and LDV markets
and implications for the cost effectiveness and social equity of LDV CO2 regulations
http://www.tmleuven.be/project/pricingandtradesecondhandcars/2nd_hand_cars_en.pdf
[9] Commission Regulation (EU) No 2017/1151 of 1 June 2017, supplementing Regulation (EC)
No 715/2007 of the European Parliament and of the Council on type-approval of motor vehicles
with respect to emissions from light passenger and commercial vehicles
[10] Haber, Stuart, Stornetta, W. Scott (January 1991). "How to time-stamp a digital
document". Journal of Cryptology. 3 (2): 99–111. doi:10.1007/bf00196791. Retrieved 4
July 2017.
[11] "Blockchains: The great chain of being sure about things". The Economist. 31 October
2015. Archived from the original on 3 July 2016. Retrieved 18 June 2016. “The technology be-
hind bitcoin lets people who do not know or trust each other build a dependable ledger. This has
implications far beyond the crypto currency.”
[12] Bheemaiah, Kariappa (January 2015). "Block Chain 2.0: The Renaissance of
Money". Wired. Archived from the original on 14 November 2016. Retrieved 13 November 2016.
[13] https://blockchain.info/charts/n-transactions-per-block
[14]The Byzantine Generals Problem, LESLIE LAMPORT, ROBERT SHOSTAK, and MAR-
SHALL PEASE SRI International https://www.microsoft.com/en-us/research/uploads/prod/
2016/12/The-Byzantine-Generals-Problem.pdf
[15]Carlo Thomas. ascribe announces scalable blockchain database BigchainDB. CoinReport,
February 2016. https://coinreport.net/ ascribe-announces-scalable-blockchain-database-
bigchaindb.
 47

[16] Cosmos: A Network of Distributed Ledgers. https://cosmos.network/ resources/whitepaper.

[17] A. Shamir, Identity-based Cryptosystems and Signature Schemes, Proceedings of CRYPTO
'84, LNCS 196, pages 47-53, Springer-Verlag, 1984.
[18] Tendermint documentation, https://tendermint.readthedocs.io/en/master/
introduction.html#what-is-tendermint
[19] Edwards-curve Digital Signature Algorithm (EdDSA), https://en.wikipedia.org/wiki/EdDSA
 48

List of figures and tables

Fig. 1 Trend of the used car markets in EU major markets. Source: https://www.bucking
ham.ac.uk/wp-content/uploads/2014/11/pnc-2014-usedcar.pdf
Fig. 2 Proportion of second-hand cars purchased cross-border. Source: European Commission
(2014), Research for TRAN Committee - Odometer tampering: measures to prevent it
Fig. 3 Visual illustration of a blockchain
Fig.4 Visual representation of a centralized system and a decentralized one
Fig.5 Visual exemplification of Identity based signature, source: Identity-Based Cryptosystems
and Signature Schemes, Adi Shamir
Fig.6 Example with 4 nodes running BigchainDb. Source BigchainDb WhitePaper, https://
www.bigchaindb.com/whitepaper/bigchaindb-whitepaper.pdf
Fig.7 Transaction structure in BigchainDb
Fig. 8 Tendermint consensus diagram, Source: https://tendermint.readthedocs.io
Fig. 9 Qr code example
Fig. 10 Demetra system overview
Fig. 11 Example of the data field stored on the blockchain
Fig. 12 Example of private data stored on the blockchain
Fig. 13 Visual representation of the decentralization of the system
Fig. 14 First page of the app
Fig. 15 Screen for setup the private and public key for Identity-based signature
Fig. 16 Assets List from the Authorized Seller
Fig. 17 Create the asset screen
Fig. 18 Asset details
Fig. 19 Dialog displayed for transferring an asset to the new owner
Fig. 20 Public keys created by the user
Fig. 21 Assets list for a pair of public and private key
Fig. 22 Update asset information screen
Fig. 23 Asset history screen

Table. 1 Table Relations between action in the system and type of data
Table. 2 Main actions for the asset in the Android app