Thesis

BCaR: Blockchain in Car Registration
Tiago António Baptista Cabrita Arriegas Rosado
Thesis to obtain the Master of Science Degree in
Information Systems and Computer Engineering
Supervisor(s): Prof. André Ferreira Ferrão Couto e Vasconcelos

Prof. Miguel Nuno Dias Alves Pupo Correia
Examination Committee
Chairperson: Prof. Luís Manuel Antunes Veiga
Supervisor: Prof. André Ferreira Ferrão Couto e Vasconcelos
Member of the Committee: Prof. Sérgio Luís Proença Duarte Guerreiro
November 2018
ii
Dedicado aos meus pais...
iii
iv
Acknowledgments
I would like to thank my thesis supervisors professor André Vasconcelos and professor Miguel Pupo
Correia, for the support throughout this work and without whom this thesis would not have the same
value. All my friends whom I have met through this five years of university, helping me go through
every conquer and misfortune during this time. Lastly, I would like to thank my parents for their support
throughout my education and mostly throughout this journey.
v
vi
Resumo
A tecnologia blockchain permite o desenvolvimento de modelos de negócio descentralizados. No en-

tanto, organizações centralizadas, como entidades governamentais, podem tirar partido desta tecnolo-
gia para melhorar a integridade e aumentar a disponibilidade de informações crı́ticas. Neste documento
apresentamos uma solução, baseada na plataforma Hyperledger Fabric, para a implementação de um
sistema de registo automóvel baseado em blockchain. O sistema proposto poderá aumentar a interoper-
abilidade entre entidades governamentais, podendo mesmo ser estendido para um sistema interestatal
na União Europeia. O sistema é responsável por registar as operações relacionadas com o registo
automóvel, desde o registo inicial de propriedade ao registo de contractos de leasing. Pela natureza
descentralizada do sistema, este poderá simplificar o acesso e troca de dados entre múltiplos estados.
Por fim é feita uma breve análise ao desempenho do sistema proposto.
Palavras-chave: blockchain, registo automóvel, sistema de informação crı́tica
vii
viii
Abstract
Blockchain technology enables the development of decentralized business models but centralized or-
ganizations, as governments, can adopt this technology to improve safety and security of critical data.
In this document we present a solution, based on Hyperledger Fabric, to implement a car registration
system which can improve interoperability between government entities and might be extended to a
cross-borders system, extending the cooperation efforts in the European Union. The system handles
the processes related to car registration, from registering a vehicle, changing ownership status or regis-
tering a leasing contract between a lessor and a lessee. This system can ease the information exchange
among multiple states as the car registration information is distributed to each government entity in a
single decentralized system. We latter present an overview of the system’s performance and analyze
the obtained results.
Keywords: blockchain, car registration, critical data storage, distributed ledger
ix
x
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1 Introduction 1
1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 5
2.1 Current car registration system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Proof-of-work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Proof-of-stake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Ethereum and Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 BFT approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1 Tendermint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.2 Hyperledger Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Permissionless versus Permissioned Blockchains . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Business Processes of Car Registration 19

3.1 Current Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 National registry office operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Online operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Business Processes on a blockchain based system . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Register a new vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
xi
3.2.2 Update vehicle’s state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Request a change of ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Register as guarantee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.5 Remove vehicle as guarantee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.6 Associate lease contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.7 Cancel lease contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.8 Lock a vehicle to a pending seizure . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.9 Cancel a pending seizure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.10 Execute a vehicle seizure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.11 Supervision and issuance of new documents . . . . . . . . . . . . . . . . . . . . . 34
4 BCar System 37
4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1 Participant definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.2 Data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3 Car registry operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 Implementation 57
5.1 Implemented access control rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Hyperledger Fabric configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 System components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.2 System behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 Results 65
6.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.4 System bottlenecks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7 Conclusions 73
7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Bibliography 75
A Hyperledger Composer Data Model 79
B System resources’ statistics 85

B.1 1 MB block size with 250 millisecond timeout . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.2 2 MB block size with 500 millisecond timeout . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.3 4 MB block size with 1 second timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
xii
List of Tables
2.1 Blockchain applications comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Blockchain infrastructure comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 VehicleState object possible states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Vehicle class for vehicles within categories M and N. . . . . . . . . . . . . . . . . . . . . . 47
5.1 Operation types for resource access control. . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 Throughput (Transactions Per Second (TPS)) considering the variation of block size. . . . 67
6.2 Latency (seconds) considering the variation of block size . . . . . . . . . . . . . . . . . . 68
6.3 Register Guarantee function with 100.0 TPS send rate (1MB block size) . . . . . . . . . . 70
6.4 Register Guarantee function with 200.0 TPS send rate (1MB block size) . . . . . . . . . . 71
B.1 CreateVehicle function with 50.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . . . . 85

B.2 CreateVehicle function with 100.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . . . 85
B.3 ChangeState function with 50.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.4 ChangeState function with 100.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . . . 86
B.6 ChangeOwnership function with 50.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . 86
B.7 ChangeOwnership function with 100.0 tps send rate . . . . . . . . . . . . . . . . . . . . . 87
B.9 IssueSeizure function with 50.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.10 IssueSeizure function with 100.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . . . 87
B.12 RegisterGuarantee function with 50.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . 88
xiii
B.26 RegisterGuarantee function with 100.0 tps send rate . . . . . . . . . . . . . . . . . . . . . 92
xiv
List of Figures
1.1 Context diagram for the car registration system . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Comparison of BFT protocols with blockachain protocols regarding scalability and perfor-
mance. (Adapted from Vukolic̀ [13]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Over the counter (or front-office) operations . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Verify documentation sub process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Back-office operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Proposed process for creating a vehicle in a blockchain based system . . . . . . . . . . . 26
3.5 Proposed process for updating vehicle’s state in a blockchain based system . . . . . . . . 27
3.6 Proposed process for changing ownership information of a vehicle in a blockchain based
system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Proposed process for registering a vehicle as guarantee for a loan in a blockchain based
system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Proposed process (started by the owner) for removing a vehicle as guarantee for a loan
in a blockchain based system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9 Proposed process (started by the creditor) for removing a vehicle as guarantee for a loan
in a blockchain based system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10 Proposed process for registering a lease in a blockchain based system . . . . . . . . . . 31
3.11 Proposed process (started by the lessee) for canceling a lease in a blockchain based
system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.12 Proposed process (started by the lessor) for canceling a lease in a blockchain based system 32
3.13 Proposed process to issue a pending seizure over a vehicle in a blockchain based system 33
3.14 Proposed process to cancel a pending seizure over a vehicle in a blockchain based system 34
3.15 Proposed process to execute a seizure over a vehicle in a blockchain based system . . . 35
3.16 Proposed process for supervision and document issuance in a blockchain based system . 36
4.1 Use case for a simple car sale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Use case for a car lease. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Use case for registering a vehicle as guarantee for a loan. . . . . . . . . . . . . . . . . . . 39
4.4 Use case for registering a new vehicle in the Bcar System . . . . . . . . . . . . . . . . . . 39
4.5 Use case for verifying vehicle’s ownership information. . . . . . . . . . . . . . . . . . . . . 39
xv
4.6 Use case for overriding a vehicle’s ownership in BCar system . . . . . . . . . . . . . . . . 40
4.7 Use case for updating vehicle’s information on BCar system. . . . . . . . . . . . . . . . . 40
4.8 Proposed car registry system’s participant types . . . . . . . . . . . . . . . . . . . . . . . 43
4.9 Proposed vehicle data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.10 Change Ownership transaction flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.11 Lease transaction flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.12 Vehicle seizure flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.13 Register vehicle as guarantee flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.14 Block diagram of the BCar System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Component diagram of Hyperledger Fabric infrastructure . . . . . . . . . . . . . . . . . . 62

5.2 Block proposal and addition mechanism for Hyperledger Fabric. . . . . . . . . . . . . . . 63
6.1 Component diagram for the Hyperledger Fabric Infrastructure setup for evaluation. . . . . 66
6.2 Throughput of Create Vehicle function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3 Latency of Create Vehicle function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4 Throughput of Change Ownership function . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.5 Latency of Change Ownership function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.6 Throughput of Issue Seizure function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.7 Latency of Issue Seizure function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.8 Throughput of Register as Guarantee function . . . . . . . . . . . . . . . . . . . . . . . . 69
6.9 Latency of Register as Guarantee function . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.10 Throughput of Change State function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.11 Latency of Change State function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
xvi
xvii
xviii
Chapter 1
Introduction
Blockchain technology has reached the mainstream by numerous criptocurrencies implementing this
technology and shook the concept of currency. Bitcoin, as the most known application of blockchain
technology, implements a digital currency not relying on any central authority to be managed [1]. The
decentralization provided by blockchain technology can be considered a direct competitor to organi-
zations relying on a centralized business model, such as banks and governments. Considering an
extreme situation, blockchain technology could present a decentralized collection of services competing
with government’s services such as property registration, citizen registration and even a financial system
replacement that could render most of the government’s work useless.
However, centralized organizations can also look at blockchain technology as an innovation with the
ability to improve their efficiency. Currently some of these organizations are researching and implement-
ing blockchain technology to the benefit of business efficiency and government’s transparency. One of
such example is the Estonian government who implemented some of its services using this technology
around 2012 [2].
1.1 Objectives
Considering the potential of blockchain technology, the main objective of this work is to implement a
car registration infrastructure based on blockchain. A car registration system based on blockchain can
decentralize this kind of registries and as a consequence improve data availability and resilience to faults.
As a set of entities, ranging from leasing companies to government offices, rely on the car registration
system, a decentralized system based on blockchain may improve its performance and safety when
compared with a centralized solution. Considering the various entities interacting with a car registration
system, a context diagram is presented in Figure 1.1.
Given the decentralization inherent to blockchain it is crucial to understand the role of an entity such
as the national registry. As it will be discussed throughout this document, a blockchain application for car
registration can still take in consideration the authority of the national registry entity. With this require-
ment, a blockchain based car registration system can benefit from decentralization but still maintain a
1
Figure 1.1: Context diagram for the car registration system
centralized authority to partially manage and control the system.

This technology can also represent an effort to improve government efficiency and transparency
[2]. As blockchain technology tends to decentralize data storage and may enable for new business
models, the advantages and disadvantages of this technology applied to a car registration system will
be considered.
This work also has the objective to evaluate and understand the impact of a blockchain based car
registration on the currently implemented business processes. As this technology enables for main-
taining registries between untrusted, the implementation of new business processes, taking advantages
of blockchain technology, will be considered. Therefore we propose an implementation of blockchain
technology for car registration using smart contracts and analyse its impact on car registration business
processes.
1.2 Thesis Outline
In this document we will start by analysing the existing blockchain infrastructures such as Bitcoin [1] and
Ethereum [3] and we later introduce the use of smart contracts. As an evolution of Bitcoin’s consensus
mechanisms, proof-of-work, we introduce Fault Tolerant based blockchains and compare them consid-
ering the properties of fault tolerance and consensus of each one. Later we introduce Tendermint [4] as
a Byzantine Fault Tolerant (BFT) based blockchain and identify differences between permissioned and
permissionless blockchains. Related to permissioned blockchain we introduce the concept of smart con-
tract execution separation [5] and analyze Hyperledger Fabric (HLF). Finishing related work we compare
each infrastructure in terms of performance, scalability and fault tolerance. In Chapter 3 we analyze the
business processes currently in place for interacting with the car registration system and propose im-
provements over the current processes. We then propose a new set of business processes, considering
a blockchain based car registration system, inspired in the current processes. In Chapter 4, we define
the proposed blockchain based car registration system by defining the requirements of a car registration
2
system. Then we propose a data model for the blockchain based car registration system as well as a
set of participants for this system. Finalizing Chapter 4, we propose an implementation of smart con-
tract functions to perform the operations for a car registration system. We then present implementation
details and access control rules defined for the system in Chapter 5. In Chapter 6 we present a set of
performance test results for the proposed car registration system.
3
4
Chapter 2
Background
In this chapter we go over a set of blockchain infrastructures and applications available. We start by in-
troducing Bitcoin as the first application based on blockchain technology and how this technology solves
some of the problems behind the creation of a digital currency. In relation to blockchain we introduce the
problem of consensus, how Bitcoin reaches network consensus and other methods of consensus that
should be considered, such as proof-of-stake. Next we present Ethereum as an infrastructure enabling
the use of smart contracts and the development of decentralized applications. We define what are smart
contracts and how Ethereum handles their execution. Later we introduce the use of BFT based con-
sensus in blockchain technology, comparing them with the proof-of-work approach. As an application
of a BFT consensus algorithm to the blockchain technology we introduce Tendermint and explain the
advantages of this infrastructure. Also with BFT consensus mechanisms we present Hyperledger Fabric
and later define the differences between permissioned and permissionless blockchains as well as the
differences between private and public blockchains. Finally we mention some applications currently us-
ing blockchain technology, how they are configured and compare the various infrastructures mentioned
in this chapter.
2.1 Current car registration system
A car registration system, as implemented by most government entities around the world, is usually a
centralized information system. This information system handles every information related to car regis-
tration and is managed by a national registry entity, although other governmental and non-governmental
entities have access to services handling car registration information.
Citizens are able to ask for information related to vehicles, as most of the information stored in the
car registration system is publicly available. Government entities responsible for controlling motorized
vehicles are able to interact with the car registration system to issue and cancel registration plates and
to change the official characteristics of a vehicle.
Tax authorities within the country have system access to declare imported and exported vehicles,
as well as to get information about vehicle ownership changes. Regarding seizure orders, lawyers,
5
courts and solicitors are allowed to interact with the car registration system to issue those orders. Finally
external entities, such as leasing companies, are also allowed to connect to the car registration system
to consult car records.
A car registration system may be composed of several servers responsible for different operations,
such as having some servers responsible for providing web services to external entities relying on car
registration information, as tax authorities, vehicle regulation authorities or even some companies di-
rectly related to vehicle registrations, such as leasing companies. Another component of such a system
is the use of a client interface for employees handling car registry data, which can be presented in a client
side application or a website providing a mean to execute the existing operations over a car registry.
All of the system components described interact with the core of the information system which in
most of the cases is a relational database hosted on a different server, responsible for managing and
storing the information required to handle car registries. Each of the components described might vary
on its complexity by having backup servers to tolerate system fault or attacks from malicious parties,
preventing data losses and system failures on each of the components constituting the car registration
system.
As within European Union (EU) there is a cooperation among member states to exchange car reg-
istration information, as to issue transit violations or simply consult registry information regarding a
vehicle in a different EU country. Thus, some of the described system components are exposed to
cross-borders access to provide vehicle information to different state members. However, as opposed
to using blockchain technology state members rely on the variability of each other’s car registration
systems to read cross-borders vehicle’s information.
2.2 Bitcoin
Bitcoin is the first decentralized digital currency and works based on blockchain technology, not rely-
ing on any central authority to manage currency. Bitcoin was introduced by Satoshi Nakamoto [1] and
presents a peer-to-peer network where transactions are executed between users without any intermedi-
ary. Bitcoin’s transactions are verified by network peers and recorded in the blockchain.
A blockchain is a distributed ledger that works as a collection of transactions grouped in blocks. Data
within the blocks can not be modified and changes or new data must be appended to the chain. This
provides an immutable log of every transaction ever made in the blockchain. A distributed ledger is a
database that can be shared in a network by multiple locations, as each network participant has a local
copy of the ledger [2].
The way blockchain works also solves a big problem about digital currency: double spending. Double
spending is an attack on which the same set of coins is spent in more than one transaction. The double
spending attack is mitigated as a transaction with the intent of double spending is rejected by any peer
of the network as conflicting transactions are not registered in a new block.
6
2.3 Consensus
In order for the blockchain network to agree on the next block to add to the blockchain there is a need to
decide who should be the author of the block. Bitcoin uses a proof-of-work to decide this matter [1], but
as this is a computational intensive task there are alternatives such as proof-of-stake. Those methods
are both used in order to ensure the integrity of the blockchain. Given the concurrency between nodes
it is possible that two nodes can broadcast different verisons of the next block at the same time. In this
situation, other nodes start working over the first block they reveive but still save the other branch, this
represents a fork. A fork is removed once the next proof-of-work is found. As the new block is added to
one of the branches, the branch becomes longer and the shorter branch is removed [1].
2.3.1 Proof-of-work
A proof-of-work is hard to produce and easy to verify, created by nodes in the blockchain network. This
implies the need for a computational intensive problem to be solved. The node responsible for solving
the problem is the potential author of the next block to be added to the blockchain [6]. In case of Bitcoin,
a node needs to scan for a nonce value for a block so that the hash of the block starts with a defined
number of zero bits. The computational effort to solve this problem is exponential to the number of zero
bits required [1].
However, this type of proof has the potential side effect of slowing the transaction processing within
the network as major computational work is wasted in the proof-of-work to create a block instead of
transaction processing. The approach used by proof-of-work increases the difficulty of successful at-
tacks, given the need for a great computational power to create a proof-of-work and use it to tamper
blockchain data.
2.3.2 Proof-of-stake
As the proof-of-work solution requires a great amount of energy to produce, an alternative is proof-of-
stake. Proof-of-stake aims to reach network consensus, therefore determine the creator of the next
block, based on a combination of factors, as the account balance or age of the node.
Peercoin [7], an example on a proof-of-stake based cryptocurrency. In Peercoin, if a node receives

for example 10 coins and does not perform any transaction with them for 10 days, it will have 100 coin-
days, which is the age of the node. To determine the creator of the next block, Peercoin requires nodes
to pay themselves, consuming their coin age in order to generate a block [7]. This process is executed
such that the coin age is consumed to achieve a certain hash target and the hash target is easier to
meet the more coin age is consumed. Therefore if a node with 100 coin-years meets the hash target in
2 days, a node with twice the coin-years meets the hash target in 1 day.
7
2.4 Ethereum and Smart Contracts
Bitcoin blockchain already provides a scripting language, as well as the ability to create colored coins
and metacoins enabeling the use of custom protocols on top of Bitcoin with added benefits, like running
decentralized applications. However those sub-protocols do not inherit the simplified payment verifica-
tion. This occurs as Bitcoin network validates correct transactions within the network respecting the rules
of Bitcoin transactions but also accepts invalid transactions from the perspective of some meta protocol
built on top of Bitcoin as long as those are valid transactions in Bitcoin [3]. A totally secure simplified
payment verification would need to perform a backward scan to the beginning of the blockchain to verify
if a certain transaction, relying on a meta protocol, is valid [3].
Furthermore, Bitcoin’s scripts do not support loops so the underlying programming language is not
a Turing-complete scripting language. Bitcoin’s scripting language also does not provide a way to limit
the withdraw value and transactions only have two states, either they are spent or unspent, not provid-
ing multi-stage contracts or any other transaction states. Finally, Bitcoin transactions are blind to the
blockchain as transactions can not access block data, such as the nonce or the hash of the previous
block. This kind of information could be used as source of randomness [3].
Ethereum [3] was created to improve the initial blockchains and provides a blockchain infrastruc-
ture able to execute fully distributed applications and smart contracts. This improvements are partially
achieved by providing a Turing-complete scripting language. The Ethereum infrastructure uses a proof-
of-work approach as a consensus mechanism, although Ethereum is expected to support proof-of-stake
in the future through an implementation of Casper proof-of-stake [8].
2.4.1 Smart contracts
Smart Contracts are programs written to form agreements between users in the blockchain. Using
smart contracts it is possible to ensure the clauses of a contract are accomplished and that breaching
the contract is expensive or even prohibitive [9].
Blockchain establishes a consensus based on minimal trust between network nodes to execute smart
contracts. When a node receives a transaction, contract functions are ran to ensure the validity of
the transaction and the conditions stated in the contract are met. In case of failure the transaction is
discarded by the network nodes.
Extending the capabilities of smart contracts, it is possible to run decentralized applications based on
the blockchain technology. Therefore, we can create applications such a car registry platform completely
based on smart contracts. In this example there is a need to create smart contracts to define what is a
car ownership entry in the blockchain as well as what is the information needed to transfer the ownership
of a vehicle from one node to another and register it on the blockchain.
Ethereum’s states are stored as a set of accounts. An Ethereum account has four fields, a nounce
ensuring each transactions is unique and the transaction is not processed twice; current ether balance
of the account; contract code, if present and storage [3]. Ether is a cryptocurrency used inside the
Ethereum infrastructure to pay transaction fees. Also Ethereum accounts can be external accounts,
8
controlled by private keys and having no contract code, or contract accounts, controlled by contract
code. Contract code is executed in a contract account each time this account receives a message.
During contract execution it is also possible for the contract code to read and write on the account’s
storage, as well as to send messages or even create other contracts [3].
Ethereum’s messages are similar to Bitcoin’s transactions but have crucial differences to support
smart contracts. Messages support responses and can be created by internal accounts such as contract
accounts. Ethereum’s transactions are defined as signed data packages storing a message to be sent
from an external account [3].
Ethereum’s transactions (sent from external accounts) contain the destination of the message, a
signature of the sender, the amount of ether, the data being sent, startgas and gasprice fields. In order
to avoid infinite loops in contract code, each transaction needs to set a limit (startgas) on how many
computational steps the code execution can take. The gasprice field is used to define the amount of
ether to be paid to the miner for each computational step.
The computational unit used by Ethereum is gas; normally a computational step costs 1 gas and the
network charges 5 gas for every byte used in a transaction. A possible attacker would need to pay a gas
amount proportional to the resources used to perform the attack, discouraging attacks requiring great
computational power [3].
2.5 BFT approach
Initial blockchains such as Bitcoin’s and even the improved version implemented in Ethereum still have
some disadvantages related to the methods used for node consensus, as distributed consensus algo-
rithms have some scalability constraints.
Considering distributed consensus, it is important to compare traditional Byzantine Fault Tolerant
(BFT) algorithms [10–12] to consensus mechanisms implemented in traditional blockchains, namely
proof-of-work approaches. Considering a BFT based blockchain is expected to follow the path of
standard BFT algorithms, this kind of blockchain would have poor scalability compared with standard
blochains using proof-of-work approach. However, BFT algorithms have a performance advantage [13],
as shown in Figure 2.1. On the other hand, proof-of-work is easier to implement in public blockchains as
nodes only need to know about one other node to perform the proof-of-work and this approach enables
decentralized identity management. BFT algorithms require each node to know every other node in
the network so that consensus is reached, normally requires a trusted central authority, therefore this
approaches are more likely to be implemented in permissioned or private blockchains [13].
Regarding consensus conflicts, such as the creation of temporary forks in the blockchain, BFT based
algorithms manage them with greater efficiency compared with proof-of-work. BFT algorithms, contrary
to proof-of-work, achieve this as they grant the property of consensus finality, as in Definition 1. Consid-
ering the realization of this property, block addition to the blockchain is immediately confirmed.
Definition 1. (Consensus Finality) If a correct node p appends block b to its copy of the blockchain
before appending block b0 , then no correct node q appends block b0 before b to its copy of the blockchain
9
Figure 2.1: Comparison of BFT protocols with blockachain protocols regarding scalability and perfor-
mance. (Adapted from Vukolic̀ [13])
[13].
Resilience to attacks is also a matter of analysis as one of the key advantages of blockchain is
assurance of immutable data, once the data is stored in the blockchain. Proof-of-work approach in
fact supports up to 50% of faulty nodes in the network, however regarding Bitcoin’s approach to fault
n
mitigation, tolerance drops to 25% [14], contrasting with BFT algorithms that support up to 3 faulty
nodes, where n is the number of nodes on a totally asynchronous network.
Given the possibility of forks, Bitcoin network nodes only take a block as final once 6 or more blocks
have been appended to the block. On the other hand, this approach can be circumvented by timestamp
manipulation [13]. BFT algorithms, as complying with Definition 1, support long asynchronous periods
and global outages. Latency in BFT algorithms usually matches network latency, contrary to proof-
of-work approach where rising block size translates in higher throughput with the downside of higher
latency. As latency of the system increases the number of possible blockchain forks increases as well,
resulting in more opportunities to perform double spending attacks and successfully executing them, as
mentioned by Vukolic̀ [13].
2.5.1 Tendermint
Presented as a blockchain implementation based upon BFT algorithms to reach consensus. Tendermint
provides a transparent, accountable and higher performance infrastructure, when compared with non-
BFT solutions. This infrastructure aims to be optimized for consortia and inter-organizational logic with
enough flexibility to support the development of a wide variety of applications, useful in areas ranging
from eletronic voting to finance [4]. A big advantage of Tendermint when compared to other platforms
is the availability of evolution and governance mechanisms, enabling infrastructure management and
10
control by organizations. Compared with other blockchain infrastructures, Tendermint was developed in
an academic environment and relies on signing, hashing and authentication algorithms designed in such
environment, instead of NIST standards, hopping the strenghtening of its infrasctuture [4]. Tendermint
uses a state-machine replication algorithm implementing Byzantine Fault Tolerant Atomic Broadcast
ensuring accountability. If safety of the system is violated it is possible to identify the responsible.
Each block integrated in Tendermint’s blockchain has a certain height or index such that there are
no two blocks with the same index in the blockchain, preventing any blockchain forks as it happens on
Bitcoin network. Validators are nodes used in Tendermint with the duty of keeping a complete copy of
every state replicated in the blockchain, ability of proposing new blocks to the blockchain and voting
on block proposals. At each height validators take turns proposing the next block to be added to the
blockchain and verify that only one block is being proposed in each round.
Before transactions are grouped in blocks and later added to the blockchain, Mempool works as a
temporary storage for unprocessed transactions. Therefore, as a new transaction arrives to network
nodes, they add the new transaction to a list of unprocessed transactions which is called a Mempool.
As transactions are validated, batched in blocks and added to the blockchain they are removed from
the Mempool [4]. Blockchains normally rely on taxing transactions as a mitigation of denial of services
attacks. For example, Bitcoin network nodes select transaction to create blocks based on transaction
fees and when the Mempool is full one of the rules to free up space from the Mempool is by removing
transactions with lower transaction fees [15]. Tendermint, on the other hand, relies on a filtering system
to ignore transactions with the intent of disrupting system’s service and hopes legitimate clients are
capable of resubmitting transactions if those are ignored by the system [4]. As a transaction is created
and the network nodes receive it, the transaction is verified by application’s logic, added to the Mempool
and sent to other network nodes using the ordered multicast algorithm. Each node is responsible for
ensuring that transactions are processed in the same order as it receives them.
As Tendermint implements a BFT algorithm, the system needs at least 4 validators (to tolerate 1 fault
n
the system must have 3f + 1 nodes given f < 3 ), as well as 1 leader or proposer per round, to reach
consensus. In each round a proposer within the available validators is selected through a round robin,
proposing a new block to add to the blockchain. Once a validator receives a block proposal it verifies
the block and signs a pre-vote which is broadcasted to the network, noting that pre-vote can be nil and
in that case the validator is voting to skip the round and select another proposer [4]. Through this voting
mechanism only one step is needed to ensure all voters know the other voters’ intents.
Definition 2. (Polka) A set of more than two-thirds of pre-votes for a single block at a given round [4].
In the secound step of the voting mechanism the system ensures enough validators know the pre-
voting results. Once a validator receives a polka (see Definition 2), he signs and broadcasts a pre-
commit vote over the proposed block. After the pre-commit vote, if a validator receives a polka of pre-
commit votes it commits the proposed block to his blockchain and moves to the next round increasing
the height for which the next block will be proposed.
During the voting process, the proposed block is locked with a Pre-vote lock before the pre-vote
phase begins. Assuring any locked block is unlocked in case of any system failure or in case consensus
11
is not reached, Tendermint also implements Unlock-on-Polka resulting in block unlock if a polka for a
higher round or height is received.
Separating the phase of voting or electing the next block of the blockchain from the actual addition
of the block to the blockchain also presents an advantage. During voting process it is required a polka
in the pre-voting step, as well as in the pre-commit step, so the system needs at least 3f + 1 validators
to agree in committing a given block to the blockchain, being f the number of faults tolerated by the
system. However, after the voting process , the actual addition of the agreed block to the blockchain
only needs the majority of replicas to do it, specifically 2f + 1 validators [4].
Tendermint has a dedicated module called Governmint to manage the governance of the infrastruc-
ture, able to be used by a group of entities. Each group responsible is capable of internal voting for
proposals whichever can lead to new actions being executed in Tendermint [4]. In a crisis recovery sce-
nario, not only Tendermint ensures the identification of safety violating nodes but a client only needs to
have access to one correct validator to understand who are the wrong validators and what is the correct
blockchain.
2.5.2 Hyperledger Fabric
Hyperledger Fabric is a blockchain infrastructure sponsored by Linux Foundation and IBM. Hyperledger
Fabric, as a private blockchain, restricts the nodes participating in the system to trusted and identifi-
able ones. Restricting the nodes of the system enables performance improvements over consensus
mechanisms and can reduce the power consumption of such system. As the nodes are known to every
element in the system, Byzantine Fault Tolerant (BFT) algorithms can replace the typical power hungry
mechanism of Proof-of-Work. Permissioned blockchains can usually be implemented within a group of
entities who may not completely trust each other [16].
Analyzing Byzantine Fault Tolerant State Machine Replication (BFT-SMaRt), it is noticeable that they
differ from blockchain networks as: Multiple applications can run concurrently; Applications can be in-
stalled on demand by anyone and application code is untrusted code. Thus, most blockchain systems
use an hard coded consensus mechanism and a Order-Execute architecture, requiring transactions
to be ordered, propagated and later sequentially executed by the nodes. Hyperledger Fabric uses a
Execute-order-validate architecture [5, 16], based on a modular consensus mechanism that can be ad-
justed to the specific need of smart contracts running on the blockchain.
Through Execute-order-validate architecture, a transaction is divided into three different phases. Dur-
ing execution phase, each transaction is executed and its correctness verified by a restricted set of peers
called endorsement peers. During this phase it is possible for transactions to be executed in parallel.
The second phase is assigned to an ordering service, responsible for establishing total order of trans-
actions received and already signed by endorsement peers, using the consensus mechanism defined
and fabricating blocks accordingly. Ordering service nodes are also responsible for updating the state
of the blockchain to all peers using atomic broadcast. For any of the operations, ordering service nodes
do not need to execute smart contracts, know about the current application state nor validate the smart
12
contracts. On validate phase, transactions are validated by the remaining peers of the network, check-
ing against the trust assumptions considered for each specific application and endorsement policies are
verified. If there is no issue in this last step, the block is then appended to the blockchain on each peer’s
local copy.
Regarding Ordering Services’ operations related to consensus mechanisms, Hyperledger Fabric
currently has three consensus mechanisms implemented [16]. A one node consensus, requiring only
one node to establish total order of transactions, a method normally used to speed up the development
environment of smart contracts, a CFT based ordering service ran on cluster, and a BFT-SMaRt [5]
consensus mechanism tolerating at most 1/3 of faults. On the matter of block formation by the Ordering
Service, a block is formed when one of the following conditions occurs: (1) the maximum number of
transactions per block is reached, (2) the maximum block size is reached or (3) a certain time has
passed since the first transaction was added to the block.
2.6 Permissionless versus Permissioned Blockchains
In this section we will define what are public and private blockchains and also what are the differences
between permissioned and permissionless blockchains. Considering the blockchain infrastructures an-
alyzed we will also classify their configurations as public, private, permissionless and permissioned
blockchains.
Public blockchains rely on public nodes, meaning that any node can contribute to the network by
running a program designed to keep a local blockchain copy, contribute to network consensus, contribute
to process transactions and create blocks. As public blockchains enable any node to contribute to the
network, information stored in this type of blockchain setup needs to be public. Public blockchains rely
on public nodes without restricting their access and actions in the blockchain.
Permissioned blockchains emerged as a necessity to restrict blockchain network participants to iden-
tifiable and explicitly authorized nodes with specific permissions[5]. Thus it is possible to have public
permissioned blockchains. In this scenario any node can still join the network however certain actions
and information may need special authorizations to be executed or accessed. Even further it is possible
to maintain various blockchains using this setting depending on the level of permissions of the network
nodes.
On the other hand, private blockchains restrict even further the blockchain by requiring all the nodes
to be authorized before joining the network. Therefore private blockchains provide mechanisms, for
the organizations managing the blockchain, to restrict the nodes accessing and contributing to the
blockchain. As a result, private blockchains increase the confidentiality of the data they store. How-
ever,the fact of relying on a central authority and a restrict number of nodes may provide less resilience
and sturdiness.
Considering public blockchains, the requirement of making public any data stored in the blockchain
has definitely the advantage of increasing data transparency but sacrifices privacy [2]. Trading off trans-
parency with privacy needs to be considered as in case of Bitcoin it has been proved the ability to
13
disclose ownership information. However Zero Cash uses signing algorithms through zero-knowledge
proof and makes it harder to disclose such information [2].
Private blockchains partialy solve this problem and have the potential for holding data outside the
blockchain, using the blockchain only to store metadata of the data stored off chain, circumventing one
of the problems of public blockchain related to the amount of data stored on the blockchain. In case
of Bitcoin, which is a public permissionless blockchain , each transaction can store up to 40 bytes of
arbitrary data [6]. As private blockchains have identified owners such as companies, they have the
ability to store information about real assets such as land registry [17]. Furthermore, private blockchains
are controlled and maintained by organizations, who are able to implement Know Your Customer (KYC)
policy and remove the anonymity associated with blockchain in case of legal issue resolutions [6].
Regarding scalability private blockchain networks do have advantages comparing to public block-
chains. Considering the use of Ethereum infrastructure [3], as benchmarked by Xu et al. [6], running a
public blockchain results in 3 to 20 transactions per second with an average mining time of 17 seconds.
Using a private blockchain with the same infrastructure the mining time was around 41 seconds but
resulted in a rate of 366 transactions per second.
Given the fact that permissioned blockchains have evolved from permissionless blockchains, Vukolic̀
[5] reflects over the limitations of developing permissioned blockchains based on permissionless block-
chains. Vucolić mentions that throughput of the system comes inversely proportional to latency as nodes
have to execute the smart contracts before validating transactions and creating blocks. Thus, Vucolić
mentions the possibility of a denial of service attack by executing a long and exaustive smart contract [5].
However, Ethereum [3] already implements a solution to prevent exhaustive execution of smart contracts,
by charging transaction size and computational time spent on the network processing transactions and
smart contracts.
Separating the execution of smart contracts from the addition of new blocks to the blockchain is also
presented in [5]. This separation is logic regarding confidentiality and improves the infrastructure per-
formance by breaking the relation between latency and throughput. Vucolić states that smart contracts
only require to be executed by endorsement peers [5]. Following this line of thought, endorsement peers
return to clients transaction verification results in conjunction with endorsement peers signatures and
blockchain state version on which those transactions were verified. As clients receive those results, they
send a transaction proposal, containing all the information returned earlier, to consensus nodes, respon-
sible for the ordering service. As consensus nodes receive and process those transactions they perform
endorsement validation (by verifying endorsement peers’ signatures with no need to re-execute smart
contracts) and output a sequence of blocks containing the new transactions to update the blockchain [5].
Once more it should be sufficient and safer to have a restricted group of nodes executing and veri-
fying smart contracts and simply have the remaining nodes getting state updates, given consensus and
blockchain syncrony doesn’t require that all nodes execute smart contracts. In the context of car regis-
tration with multiple entities it makes sense to execute smart contracts over a restricted group of nodes
controlled by the national registry institution and the consensus mechanism for block addition open to
every node controlled by entities relying on this system.
14
Applying the method suggested by Vucolić [5] has its advantages as it eliminates the need for se-
quential execution. Thus consensus nodes improve their performance by avoiding the re-execution of
smart contracts and also contribute to improved confidentiality, as only endorsement nodes need to be
aware of the smart contracts logic. The solution proposed by Vucolić [5] is based on Hyperledger Fabric.
As presented on Table 2.2, Bitcoin is a public permissionless blockchain as well as Ethereum. How-
ever, Ethereum also presents the option of creating a private and permissioned blockchain. Tendermint
and Hyperledger Fabric are private and permissioned blockchains only allowing authorized nodes to join
the network and having permissions defined for each node on the network.
2.7 Applications
Although cryptocurrencies, as Bitcoin, are the most popular application of blockchain technology, there is
a large set of applications based on blockchain backed by governments, banks and private companies.
The use of blockchain and smart contracts may improve the government relationship with citizens and
also help government initiatives to take part of the digital world. As stated [2], this technology also
improves the privacy of citizens and transparency of government work.
Applying blockchain technology to business may lower operations costs and coordination efforts, as
the system automaticaly handles possible conflicts [2]. This technology also has the potential for fraud
reduction. Distributed ledgers can be used to better secure data itself contained in the blockchain and
easily share citizen’s data between government entities as well as secure critical infrastructures [2], such
as the country’s electrical grid.
Blockchain technology can also contribute as a method to certify the origin of products. A blockchain
is being developed with this objective applied to diamonds by Everledger [18]. The project should result
in a system where every diamond in the world would be registered and at any given point it would be
possible to check the origin of a diamond. This presents an effort to reduce the usage of diamonds
originated from war zones, as currently this kind of diamonds are mixed with legal diamonds and then
sold in the industry, losing its trace.
NASDAQ was one of the first entities implementing blockchain based technology to register secu-
rities. Linq, refered by Underwood [18], reduces operation costs of securities registers and ensures
real time monitoring and transaction integrity. Linq relies on the Chain infrastructure [19]. Chain Core
provides a Turing-complete programming language to create smart contracts and allows any network
participant to issue assets through issuance programs [20]. Chain also provides no blockchain forks
as long as block signing nodes reach a quorum. Chain delegates to a single node the block creation
process but any network node can validate blocks and submit transactions [20].
The Estonian government implemented a blockchain solution in 2012 applied to registries of national
health system (e-Health Records [21]), judicial and citizen registry system. A concrete application of the
blockchain technology by the Estonian government is e-Residence [22]. Through e-Residence applica-
tion, the Republic of Estonia issues digital identities (together with a digital ID smart card) for people and
organizations around the world who want to develop a location independent business. Using this appli-
15
Name Blockchain Type Smart Contracts consensus finality Fault Tolerance
Hyperledger / permissioned / Yes Yes (Hyperledger) f < n3 (HyperLedger) /
Everledger
Ethereum permissionless 50% (Ethereum)
Linq Chain Core permissioned yes Yes -
Estonian e-services KSI blockchain permissioned No - -
Chromaway Bitcoin permissionless Yes (Colored Coins) No 25%
Table 2.1: Blockchain applications comparison
cation, e-Residents can start a company, access business banking, sign and securely send documents
and declare taxes online [22]. The Estonian government uses blockchain technology in order for any
data registered in their systems and subsequent changes to have a timestamp, identity and authenticity
associated, ensuring data integrity [18].
Considering the objective of this thesis, some companies have researched and implemented property
registration infrastructures through the blockchain technology. ChromaWay is implementing property
purchase through smart contracts and colored coins in the Bitcoin network, as proposed by Mizrahi
[17]. In conjunction with the Sweden government, ChromaWay finished the second stage of this project
in March 2017, modeling a property transaction and including every interested party from buyers and
sellers to the banks involved in the necessary loans.
Comparing each application mentioned regarding technical decisions on the blockchain configuration
we can understand diferent options avaliable to implement a car registration system (see Table 2.1).
Detailed comparison of each blockchain infrastructure analysed so far will be discussed in the next
section. As a side note, Chain Core and KSI blockchain [23] infrastructures will not be discussed as
their documentation is limited when compared with the other infrastructures considered.
2.8 Discussion
Analyzing the implementation of the similar problem related to property registration [17] through blockchain
technology, based on the Bitcoin network, it is clear that the Bitcoin network is not the best infrastructure
to implement such system for car registration. Firstly, the Bitcoin network is a public network with no
permissioned nodes. This presents a liability as nodes are not controlled of the entity responsible for
car registration maintenance. A better solution should consider a permissioned and private blockchain,
enabling the responsible entity for authorizing new nodes to join the network. Though this approach it
is also ensured that network nodes are identifiable. As we have seen in Section 2.4, one of the key
points of using Ethereum over Bitcoin infrastructure was the lack of simple payment verification over
sub-protocols built on top of Bitcoin network. Moreover the capacity of storing contract states and the
use of a Turing-complete language for contract definition makes it easier to implement a more sturdy
system based on Ethereum [3].
In relation to consensus protocols, it is also crucial to identify which one seams more adequate for a
car registering system, assuming a permissioned and private blockchain. The car registering system is
most likely to be implemented in a hardware infrastructure own by the government. Therefore, the use of
proof-of-stake is not adequate to the system as one of the key factors of this kind of consensus protocol
16
is relying on nodes owning a great stake in the system. In this system however, stored data refers to
ownership of cars and network nodes do not possess goods, as cars are owned by citizens who do not
participate in this blockchain network.
A second consensus protocol mentioned is the proof-of-work. This method does make sense to
be used by the car registering blockchain however has its downsides. As the problems presented by
proof-of-work require a great effort to solve [1] they are directly translated into huge processing power
spent. Proof-of-work demands high electricity costs, as a matter of fact Bitcoin network, which uses this
consensus mechanism, consumed more electricity in 2017 than Ireland in this same year [24]. Thus the
use of proof-of-work is not an option given the costs of maintaining such system.
At last we consider the use of a BFT based consensus mechanism such as the one presented by
Tendermint or the consensus mechanism presented by Hyperledger. BFT based consensus accom-
plishes consensus finality as presented by Vucolic [13] and mentioned in Section 2.5. Compared to
proof-of-work also demands less processing power and presents a fault tolerance system based on the
number of existing nodes on the network. This consensus algorithms also present an higher throughput
network compared with proof-of-work (see Table 2.2) and achieve block latencies or average mining
times approaching the usual network latencies, in the order of secound or even milliseconds [4, 25].
Considering the existing infrastructures for implementing this system, it should be able to deliver
an high performance, so the best way is also favoring the use of a private ledger, improving the trans-
action speed to around hundreds of transactions per secound using Ethereum or even thousands of
transactions per second using Tendermint infrastructure [4, 6].
Tendermint is an infrastructure based on Bysantine Fault Tolerant Systems so it supports faults acord-
n−1
ing with f = 3 where n is the number of nodes and f the number of faults tolerated, roughly 33% of
faulty nodes when n aproaches infinity. Compared with the 25% of Bitcoin network [14] and theoretically
50% of nodes failing on Ethereum.
Performance wise, Bitcoin is limited by 7 transactions per second as the consensus mechanism
requires a great node effort to process transactions and as consequence requires around 9 minutes to
create a block and add it to the blockchain. On the other hand, Ethereum not only provides the choice
of using either a public or a private blockchain but also provide major performance improvements as this
infrastructure can process around 20 transactions per second in a public blockchain with a latency of
17 seconds or around 366 transactions per second in a private blockchain and latency of 41 seconds
as presented by Xu et al. [6] and shown in Table 2.2. Tendermint provides around 104 transactions
per second when 32 nodes are connected to the network and more than 104 transactions per block.
n
Furthermore provides tolerance to 10 faults according to f < 3 with a latency of around 1.1 seconds [4].
Hyperledger Fabric (HLF) is also a great infrastructure, based on BFT algorithms, to analyse as it
is backed by big industry players such as IBM. Considering the use of HLF with BFT-SMaRt [25] and
even the work of Vucolić [5] by separating the smart contract execution from block addition seams to be
adequate to our solution.
Mentioned as a weak factor for most blockchain infrastructures, consensus protocols are usually
implemented as hard coded [5]. Except HLF, both infrastructures mentioned, as Bitcoin network [1],
17
Bitcoin Ethereum Tendermint Hyperledger Fabric
Blockchain Type Permissionless Permissionless or Permissioned Permissioned Permissioned
Consensus Protocol proof-of-work proof-of-work BFT Algorithm modular (PBFT, BFT-SMaRt, WHEAT)
Smart Contracts Yes (Colored Coins) Yes Yes Yes
Simple payment verification No Yes Yes Yes
Consensus Finality No No Yes Yes
n
Fault Tolerance 25% 50% f< 3
Throughput (transactions/second) 7 20(public)/ 366(private) around 104 around 22000

Average Mining Time 9m 17s(public)/ 41s(private) 1.1s 0.6s (BFT-SMaRt) /0.32s (WHEAT)
Table 2.2: Blockchain infrastructure comparison
Ethereum [3] and even Tendermint [4], suffer from this weakness. Changing consensus protocols of
those infrastructures depends upon major code transformations [5]. Although we tend to suggest a
consensus mechanism based upon BFT protocols, the ability to easily change the underlying consen-
sus mechanism of the infrastructure is a strong advantage if we want a system allowing for scalability,
durability and maintainability.
18
Chapter 3
Business Processes of Car

Registration
In this chapter we take an overview of the business processes involved in the operation of the current
car registration system. A new car registration system based on blockchain technology, as proposed
in this thesis, may bring innovation over a centralized car registration system and change some of the
business processes currently in place. An analysis of the current business processes, of the Portuguese
national registry entity, will be conducted. The information to model the presented business processes
was obtained through public domain information. Finally, we will go over a scenario using a blockchain
based car registration system and model some of the business processes associated with this new
system.
3.1 Current Business Processes
Analyzing the current car registration system, a user can interact with the system mainly through two
methods. A user can interact, directly or indirectly, with the system by going to a national registry
office and require information regarding a vehicle or require to change a vehicle’s registry. Then a
national registry employee consults the car registration system and provide the information to the user
or update the vehicle’s registry. Information changes, for registered vehicles, mostly require the owner
or an authorized party to fill in a form, such as [26].
On the other hand, a vehicle owner can have a narrower but more direct access to the car registration
system by using an online platform, although most of the information updates still require approval from
a registry employee. In both methods described, most of the operations available require some sort of
payment to be executed, although online operations can have a discounted price when compared with
the ”over the counter” operations. A simplified version of the required actions to interact with the current
car registration system, is shown as a business process model diagram in Figure 3.1 and Figure 3.3.
19
Figure 3.1: Over the counter (or front-office) operations
3.1.1 National registry office operations
Considering ”over the counter” operations (Figure 3.1), a citizen can require a car registry change by
filling the appropriate form [26] and handing over this document to a registry employee. A registry
employee receiving the form will proceed to introduce the information in the car registration system
to fulfill the citizen’s request. Thus, he needs to select the correct request type and the shareholders
involved in the requested operation. Available request types are the following:
• Certificate issuance - When a ownership change occurs,thus a new certificate of ownership is

required or when requesting information about a certain vehicle.
• Register vehicle as guarantee for a loan
• Vehicle lease - Considering operations such as creating, changing or canceling, associated with a
certain vehicle.
• Pending seizure issuance - When a judicial order requires the vehicle to be kept as property of the
current owner until a judicial case is solved.
• Seizure issuance - When an order as proceeding from a court decision is made so the vehicle’s
ownership is changed to another entity such as a creditor of the current vehicle owner.
• Judicial activity - Execution of a decision issued by a court concerning the ownership of a vehicle.
• Judicial sale - Transfer of vehicle ownership from a debtor’s property to another in exchange for a
certain amount pointed under judicial order.
The next step is to register all documentation provided by the citizen to execute the request. A
payment order is issued so the request can be processed after the citizen provides such payment. Finally
a temporary certificate is issued when considering a information update operation, such as ownership
changes or leases. This process ends for the citizen as soon as he hands over the information request
change to a registry employee.
However, a back-office process, as modeled on Figure 3.3, is still needed to fully process the citizen’s
request. The back-office process starts when a registry employee looks for the list of pending requests in
20
Figure 3.2: Verify documentation sub process
the car registration system. As a registry employee selects a pending request, he can reject the request
and provide a brief textual explanation on the reason leading to that rejection. On the other hand, the
registry employee can complete the pending request by inserting the necessary documentation for the
request to proceed. After this step, the list of shareholders to the processing request is inserted into the
car registration system and a document’s verification is executed by the registry employee.
Resulting from the document verification performed (sub-process described in Figure 3.2), the reg-
istry employee can add missing documents available to him but not yet inserted into the car registration
system, if needed, and proceed to the next phase of the back-office process or the registry employee can
reject the request and provide a justification. In the request qualification phase, the employee selects if
the request result is considered to be a definitive result or it should be issued as a temporary. Consid-
ering the available qualifications, a new vehicle ownership certificate might be issued as temporary until
certain issues are solved.
After selecting the request qualification, the employee is asked to confirm if the payment for the
request was already executed by the citizen requesting it. It is mandatory that the payment confirmation
is verified, so the request can proceed to the next phase. Finally, the request result is issued and the
process is finished. A request result may vary with the type of request specified in the form by the citizen.
In case of a vehicle ownership change, this process results in a final ownership certificate being issued
registered after the new owner.
3.1.2 Online operations
A vehicle owner can request some of the operations available in the car registry system by using a online
platform 1 . Using this platform it is possible to issue a set of operations which will latter be verified by a
registry employee, in a similar process to the one described in Figure 3.3.
The operations available online require personal identification through a digital signature present
in the citizen’s personal identification document. Using the online platform it is possible to issue the
following operations:
• Request the registration of a new vehicle in the car registration system

1 Automóvel Online - https://www.automovelonline.mj.pt/AutoOnline/
21
Figure 3.3: Back-office operations
22
• Request a vehicle registry cancellation based on a certificate issued by the Department of Motor
Vehicles
• Request a cancellation for a previously issued seizure
• Request a change of ownership
• Request to register a vehicle as guarantee for a loan
• Request to remove a vehicle as guarantee for a loan
• Request a change of ownership followed by registering the vehicle as guarantee for a loan
• Request the issuance of a new ownership certificate
• Request a lease related operation
• Request to register a judicial order
Each of the above mentioned operations enable the submission of required documentations for the
specific operation, as well as the input of the information similar to the form used in ”over the counter”
operations. Most of the operations available through a national registry office are also available through
the online platform. However, certain operations such as getting ownership information about a certain
vehicle are possible, yet not available online. Operations regarding information about a certain vehicle,
when not performed by a owner or by a involved third party, as a leaser or a creditor, need to be
requested through a national registry office.
3.2 Business Processes on a blockchain based system
As blockchain technology presents a decentralized system without need for complete trust in a central-
ized third-party, business processes can be critically modified. A blockchain based information system
presents unchangeable logs for every operation ever made within a blockchain system, thus it is not
possible to delete any information already registered in the system. The only operations available are
the creation of registries, read methods for those registries and possible updates on existing registries.
However, the update of registered information in a blockchain based information system does not hide
the previous state of the registries, simply a new version of the registry is created according to the newly
updated information.
Given the properties of a blockchain based car registration system, business processes presented in
Section 3.1 can be modified to benefit from blockchain properties. Thus we propose a blockchain based
car registration system on which change requests over vehicle information, can be firstly registered to
the system, as soon as the request is issued by the respective participant and the request’s payment is
verified. There are multiple alternatives to outsource payment verification through automatic solutions,
as IfThenPay2 or EuPago3 . A blockchain based car registration system would then work following the
2 https://ifthenpay.com
3 https://www.eupago.pt
23
principle that information updates over vehicle’s data are correct unless this information is latter proven to
be wrong. This approach to updates in a information system takes advantage of blockchain technology
and its immutability to simplify business processes.
Considering the proposed principle over centralized information systems, the principle would present
several problems. One of the most sever problems is that, once a vehicle information update is registered
in a database, the previously registered information is not preserved. Thus, every information update
over a traditional information system, is required to be strictly verified, as malicious actors can delete or
destroy important information.
One of the main points behind the proposed principle is the fact that, currently every vehicle informa-
tion’s request, as presented in Section 3.1, is registered in the car registration system, regardless of its
outcome. Through the current car registration system, when a request is correctly formulated and all re-
quired documents are provided, the request is registered in the system. Latter the information system is
update regarding vehicle registries, once a registry employee approves the request. On the other hand,
when a request is submitted but has incorrect information or the required documents are not provided,
the request is registered in the system, analyzed by a registry employee and latter rejected.
We propose that, in a blockchain based system, any request regardless of its outcome is directly
registered as a vehicle information update, on the vehicle’s registry. Thus, a registry employee is only
required to verify the executed updates. Taking into account every information and document in the
request is correct, no further action is required by the registry employee. Otherwise, if there is a lack of
information or documentation, the registry employee issues an update to the vehicle’s registry, reverting
the vehicle’s information to its correct state. However, every request and information update remains
registered in the blockchain.
3.2.1 Register a new vehicle
Taking into account, the registration of a newly fabricated vehicle into a blockchain based car registration
system, we assume the intervention of a registry employee is recommended. This recommendation is
based on the fact that this operation might require several authorizations from authorities, such as the
Department of Motor Vehicles. On the other hand, the operation to register a new vehicle is a create
operation, thus allowing user’s requests to directly create entities in the system can lead to a system
bloated with malformed asset registries.
We propose a registration process for a new vehicle in the car registration system as presented in
Figure 3.4. A request is made through a front-office process or through a online portal and it is latter
processed by a national registry employee. The employee will verify the information available in the
request and possibly complete some of the information. On a second step, the employee will verify
that all request’s information is according to the documents provided and might add new documentation
before completing the process.
As every information and documentation is correct and verified by a national registry employee, the
request is fulfilled. Therefore, a new vehicle is registered in the blockchain registration system and a
24
ownership certificate is issued to the citizen specified in the request.
3.2.2 Update vehicle’s state
Vehicle state updates are usually issued by government entities. Therefore require documentation certi-
fying the new vehicle’s state and possibly some explanation. Given this fact, we could consider a process
for each responsible entity to follow when issuing a vehicle’s state update that should latter be executed
in the car registration system.
Updating a vehicle’s state by an external entity could be done by allowing every responsible entity
to introduce its updates into the blockchain system. This operation could also be implemented trough
web services provided by either the entity responsible for the vehicle’s state update or by the registry
entity. However, a numerous set of entities would be entitled to issue this updates, with various different
properties each.
As simplification, we consider every request regarding vehicle’s state updates are handled by na-
tional registry employees, according with the documentation received by competent government entities.
Thus, once a registry employee receives the necessary documentation, he is required to introduce this
documentation in the system and latter issues a vehicle state update to the blockchain in order to effec-
tively change the vehicle’s state in the system. A business process model for the suggested process is
presented in Figure 3.5.
3.2.3 Request a change of ownership
Regarding ownership change process we propose a two phase process, based on the principle stated
in the beginning of this section. The current owner of a vehicle wishing to pass his ownership position
to another entity is required to fill a online form with all necessary information and documentation. Once
this form is submitted and the necessary payment is confirmed by the system, a pending ownership
change is submitted to the blockchain based car registration system, as modeled in Figure 3.6, which is
latter confirmed by the prospect owner.
As the vehicle’s owner issues a change of ownership request, with information about the new owner
and its share of ownership, the vehicle ownership is registered as a pending ownership and the prospect
new owners is required to take action. The prospect owner is then informed of this pending operation
and is able to accept or reject the ownership change (Figure 3.6). Only after the prospect owner confirms
the ownership change, the new owner is effectively registered as owner of the vehicle in the blockchain
and the old owner is removed as owner of the vehicle. Taking into account the new prospect owner of the
vehicle rejects the ownership change, the process of changing ownership is reverted. Thus, the vehicle
ownership information in the blockchain is updated so that the old ownership settings remain valid and
the prospect owner is no longer tied to the vehicle.
From the moment the request’s payment is made, a national registry employee is able to verify the
correct execution of the process. In any point, the registry employee can verify that all correct documents
are registered and the registry employee can add documentation if needed, to correctly register the
25
Figure 3.4: Proposed process for creating a vehicle in a blockchain based system
26
Figure 3.5: Proposed process for updating vehicle’s state in a blockchain based system
operation. On the other hand, the registry employee is able to cancel and revert the operation either
after the change of ownership process is started by the current owner or after the prospect owner takes
action and accepts or rejects the new ownership.
The proposed process aims to simplify the back-office process performed by a national registry
employee. Thus, use blockchain technology to improve overall efficiency of the process by considering
a national registry employee is only required to intervene when the process is incorrectly executed.
3.2.4 Register as guarantee
When registering a vehicle as loan guarantee, the process can be modified as modeled in Figure 3.7.
Thus, when a vehicle owner wants to register a vehicle as guarantee for a loan, he issues a request
with the intended documentation. During the issuance of this request, the vehicle owner is required
to specify who is the creditor entitled for this guarantee, the total value to which the vehicle is given
as guarantee and the penalty for missing payments. Once the payment for the request is confirmed,
the blockchain is updated with new information regarding the guarantee tied to the vehicle. As the
information is registered in the blockchain, a national registry employee is able to verify every information
and documentation submitted for the request. If any request is data is missing, he is able to revert the
guarantee registration.
Sometimes, a guarantee registration is tied to a change of ownership, as when buying a car. For
this situation the process is slightly changed and includes the change of ownership process described
in Section 3.2.3. Thus, a vehicle’s ownership is changed to the new owner followed by a Register as
guarantee request presented in Figure 3.7. On the other hand, the ownership could firstly changed to
the creditor, which would register the vehicle as guarantee to the loan and lastly the vehicle’s ownership
would be changed to the new owner, preserving the guarantee created earlier.
27
Figure 3.6: Proposed process for changing ownership information of a vehicle in a blockchain based
system
Figure 3.7: Proposed process for registering a vehicle as guarantee for a loan in a blockchain based
system
28
Figure 3.8: Proposed process (started by the owner) for removing a vehicle as guarantee for a loan in a
blockchain based system
3.2.5 Remove vehicle as guarantee
Considering a vehicle already tied to a guarantee, we propose a process for removing a vehicle as
guarantee for a loan where a registry employee, in the usual flow of the process, is only required to
supervise the process. As proposed on the above mentioned processes, a registry employee is required
to check if all information, given by the involved parties of the process, is correct and complete missing
information or documents. The registry employee can revert request’s changes on the few cases that
incorrect information is given or there is a lack of documentation.
In order to remove a vehicle from being a guarantee for a loan, the vehicle owner must issue a
request to cancel the guarantee. Therefore, the vehicle’s owner is suppose to fill in a request online
providing information about the loan guarantee currently in place. Thus he must specify the creditor
currently associated with the loan, as well as some loan characteristics, such as the vehicle tied to the
loan and the total value of the credit. Once the required documents are submitted and the payment for
processing the request is done, the request’s information is submitted to the blockchain car registration
system. The next step to confirm the guarantee cancellation is executed by the creditor registered in
the loan guarantee. A creditor with this characteristics is able to accept or reject the owner’s request, as
presented in Figure 3.8.
On the other hand, the removal of a vehicle as a loan guarantee can also be started by the creditor
tied to the loan. As the party most affected in a vehicle’s guarantee removal is the creditor, he is able
issue a guarantee removal to a loan with a simplified process (Figure 3.9). Thought this simplified
process, once the creditor issues the guarantee removal and the necessary payments are confirmed,
the information is automatically updated in the proposed car registration system.
In case a conflict arises and the processes presented in Figures 3.8 and 3.9, a national registry
29
Figure 3.9: Proposed process (started by the creditor) for removing a vehicle as guarantee for a loan in
a blockchain based system
employee is able to solve any of those issues. Whenever a major conflict arises, Judicial officers are
able to take control of the issue, after a court order is issued.
3.2.6 Associate lease contract
When owning a vehicle, the owner is able to issue a lease contract signed by the owner, as a lessor and
a third-party, as a lessee, with a specific duration. A lease contract expects the lessee to make regular
payments for a specified number of months. In exchange, the lessor gives permissions for the lessee to
use the asset, in this case the vehicle, for the duration specified on the contract. In case the terms of the
contract are not respected, both the lessor and the lessee can be penalized.
Taking into account this operation, we suggest the registration of a lease depends on the two parties
involved in the contract. As follows the role of a national registry employee can be minimized in this
process, turning it into a overall leaner process,. Therefor we propose the lease contract association
in a blockchain based car registration system is divided into two phases. The issuance of the lease
registration by the lessor and owner, followed by the confirmation of the lease contract registration by
the lessee.
The lease registration process is then started by a vehicle owner, submitting lease information, as
well as, a copy of the lease contract in digital form, as shown in Figure 3.10. Once the request’s
payment is completed, the lease details are associated with the vehicle’s information in the blockchain
based system. However, as this operation implies responsibility being handed over to a third party, the
prospect lessee, the lease information remains in a waiting state. Then the lessee implied in the lease
contract is required to confirm or deny his involvement in the contract. Considering the lessee accepts
the lease contract, through the proposed process of Figure 3.10, the contract is validated in the system.
Otherwise, the lease operation is reverted once the prospect lessee rejects the pending proposal.
Throughout this process a national registry employee is able to supervise the information and doc-
umentation provided. Once any operation is submitted to the blockchain, the registry employee has
30
Figure 3.10: Proposed process for registering a lease in a blockchain based system
permissions to revert it, if the request does not comply with the defined rules.
3.2.7 Cancel lease contract
As a lease contract is required to be registered in the car registration system, any update over the
lease contract implies the update of the vehicle’s information details associated with the contract. Thus,
canceling an active or pending lease contracts is an operation to take into consideration.
Similarly to the operation for registering a lease contract into the blockchain based system, a lease
cancellation update can be issued by the lessor. On the other hand, as the lease contract is a bilateral
agreement, the lessor can also take initiative to start a lease contract cancellation. As mentioned in the
proposed processes, a national registry employee is entitled to supervise the process and able to issue
a lease cancellation, when provided with the necessary documentation.
Once a lease contract cancellation is issued by the lessee, by submitting a request with lease contract
reference information, the blockchain is updated. However, the lease contract cancellation is required
to be approved or rejected by the lessor, as shown in Figure 3.11. On the other hand, considering the
lessor is the one firstly issuing a lease cancellation request, the contract remains valid until the lessor
confirms or rejects the cancellation request, as in Figure 3.12.
The two step process suggested, is designed so that both parties are aware of the contract’s termi-
nation. Sudden cancellation of a lease contract without the notice to one of the parties could lead to
numerous complications. The proposed process is not perfect, therefore any issue can be resolved by
a supervising registry employee. Further complications may be decided through court orders, however
we focus on the main processes intended to perform operations over the car registration system.
31
Figure 3.11: Proposed process (started by the lessee) for canceling a lease in a blockchain based
system
Figure 3.12: Proposed process (started by the lessor) for canceling a lease in a blockchain based system
32
Figure 3.13: Proposed process to issue a pending seizure over a vehicle in a blockchain based system
3.2.8 Lock a vehicle to a pending seizure
Whenever an entity is implied in a judicial case, some of its assets might be locked by a court. This
measure is usually taken to ensure the entity’s assets are still available to be seized by the end of
the judicial case, if a judge decides so. Locking an asset implies issuing a pending seizure order to
the national registry entity, so that the owner is no longer entitled to issue certain vehicle’s information
updates, as ownership changes.
Regarding a blockchain based car registration system, we propose this operation can be mostly
managed by a judicial officer. Thus, a judicial officer is entitled to issue a pending seizure request, as
modeled in Figure 3.13. The judicial officer is required to fill in information about the judicial order issuing
the pending seizure request and its documentation. Once this information is submitted to the blockchain
based car registration system, the operations available to the original owner are immediately limited.
The pending seizure remains in place until a posterior order is issued by a judicial officer.
3.2.9 Cancel a pending seizure
As soon as a vehicle is submitted to a pending seizure order, depending on the judicial decision there
are two possible results. Either a vehicle seizure is executed (process explained in the next subsection)
or a cancellation of the previously ordered pending seizure is issued. Furthermore, regarding a pending
seizure cancellation, it results in unlocking operations that might have been locked once a pending
seizure order was in place.
The cancellation of a pending seizure can be executed by a judicial officer, when a judicial decision
is issued. Thus, the judicial officer is required to issue a request with information and documentation
regarding the judicial decision. As soon as the request is issued, an update on the vehicle’s information
is registered on the blockchain and the vehicle returns to its original state before the pending seizure.
This process is modeled in Figure 3.14.
33
Figure 3.14: Proposed process to cancel a pending seizure over a vehicle in a blockchain based system
3.2.10 Execute a vehicle seizure
A vehicle seizure occurs when, by judicial order, the ownership of an asset, in this case a vehicle, is
forcibly changed in order to liquidate owner’s debt. A vehicle seizure request is currently made by a
judicial officer and latter executed by national registry employees. The principle of updating the vehi-
cle’s information, as soon as the request is submitted, also applies to this operation. On a blockchain
based car registration system, we propose the process to be executed by a judicial officer, providing the
supervision role to a registry employee.
Once a vehicle’s seizure order is emitted, a judicial officer must fill in a seizure request with the
required information and documentation, as the judicial order number issuing the seizure. As soon as a
judicial officer submits the required information for seizure of the vehicle, the action is submitted to the
blockchain. Thus, the ownership of the vehicle is changed, so that the owner of the vehicle implied in the
seizure loses the ownership right of the vehicle. On the other hand, the entity specified in the seizure
order becomes the new owner of the vehicle.
3.2.11 Supervision and issuance of new documents
As proposed, it is intended to use blockchain technology to enhance business processes for car registra-
tion. This might be achieved by implementing the business processes proposed in Section 3.2. On the
other hand, the process executed by a registry employee is recommended to be simplified further, taking
advantage of a blockchain information system. Thus, a registry employee is proposed to supervise the
processes suggested in Section 3.2.
Suggested business processes, Sections 3.2.1 to 3.2.10, provide changes to the registered vehicle’s
information. A certificate of ownership retains information about leasing contracts such as the start and
end dates for the lease contract as well as the information about the lessee. On the other hand, the
certificate of ownership must be changed when the vehicle is associated as guarantee for a loan. In
34
Figure 3.15: Proposed process to execute a seizure over a vehicle in a blockchain based system
the latter case, information about the creditor entitled for the loan guarantee, such as the name and
the official address of the creditor must be present in the certificate of ownership. A new certificate of
ownership is required once a change of ownership is made completed, given the new owner is entitled
to have a certificate.
On the other hand, certificates of ownership register relevant information for authorities regarding
vehicle characteristic, as color, engine displacement or weight of the vehicle. This information is usually
registered and controlled outside of the vehicle registry information system, by other government entities
such as the Department of Motor Vehicles. However, the entity responsible for issuing a new certificate
of ownership is usually the National Registry Entity.
Considering a blockchain based car registration system, we propose a registry employee to exe-
cute a supervision and issuance process, presented in Figure 3.16. Whenever a request interacts with
the car registration system, a registry employee is required to verify the information submitted to the
blockchain. Thus in case of non-compliance, the request can be reverted by issuing a new information
update replacing the vehicle’s information to the values registered before the request was made. As
the request’s information stored in the blockchain is approved by a registry employee, he is required to
verify the off-chain submitted documentation. Taking into account every document submitted is valid, no
further action is required if the request is part of a two step request, as in Section 3.2.3 or Section 3.2.7.
Otherwise, a new ownership certificate is issued and no change is made to the blockcain.
35
Figure 3.16: Proposed process for supervision and document issuance in a blockchain based system
36
Chapter 4
BCar System
In this chapter we propose a car registration system based on blockchain technology. At first we consider
the requirements of a car registration system, starting from the currently centralized system and its
properties. Based on this analysis we propose to implement a blockchain based information system
with granular access control, considering the different types of blockchain infrastructures analyzed in
Section 2.6. A set of use cases is defined as part of the requirements for the proposed system.
Considering the requirement constrains we go over a detailed definition of the proposed system. A
set of system participants is defined and which information is required to be stored for each participant
type. A light consideration on the permissions of each participant is presented. Taking into account
vehicle information required by European law, a data model is presented. When describing the data
model, a detailed explanation over each component required to be stored in the system for each vehicle
is shown, as well as, why some of the data model design decisions where made.
Concluding this chapter, we present a detailed exposition over the available operations in the pro-
posed car registration system, based on the business processes suggested in Chapter 3. Transactions
are grouped into the different operations available, ranging from creating a vehicle to issuing a seizure.
For complex operation flows, a state machine is presented and each state explained, as well as which
participants are entitled to execute each transaction of the system. Finally, a system overview is pre-
sented.
4.1 Requirements
Currently, car registration systems in Europe are controlled and maintained by each member state. As
blockchain technology relies on distributed nodes, the control detained by government entities should be
adapted. Therefore, a car registration system based on blockchain technology can distribute most of the
maintenance effort and even some of the system’s control by network nodes. However the government
entities of each European member state could still detain most of the control over the registered cars in
that state. The European member states or even the European Commission should also be able to have
the role of a supervising authority.
37
Car registration system
Seller National Registry Employee
Sell car
Buyer
Figure 4.1: Use case for a simple car sale.
The judicial entities of each state member should also have enough control to override ownership
when executing a judicial order. Considering non-functional requirements, the system should be de-
signed for high availability and fault tolerance as well as to guarantee safety of the data. Furthermore
the system should also be resilient to attacks. All of this non-functional requirements may be achieved
using the blockchain technology.
As part of a car registration system’s requirements, at least the following use case scenarios:
A. Main use cases:
1. A car seller wishes to transfer car ownership to a car buyer. (see Figure 4.1)
2. A leasing company provides a contract to a client with the clauses of the client using the car
for a defined period of time on which the leasing company is responsible for paying mainte-
nance and insurance expenses in exchange for a defined monthly payment by the client. As
the contract reaches its ending, the client can buy the car from the leasing company for a
previously defined amount. (see Figure 4.2)
3. A car owner submits a request to give the car ownership as a guarantee to a creditor in case
the car owner does not fulfill the contract. (see Figure 4.3)
B. Secondary use cases:
1. A car manufacturer submits a request to create a car registry entry for a newly produced car.
(see Figure 4.4)
2. An authority, such as the police, wants to verify the ownership of a car. (see Figure 4.5)
3. Given a judicial order and in order to liquidate a car owner debt, the car ownership is trans-
ferred to the entity responsible for collecting the debt payments. This use case should be
executed by a judicial officer. (see Figure 4.6)
4. In event of a crash or other misfortune a car is considered totaled and its state on the car
registration system should be updated to officially be considered out of circulation. This order
is executed based on information given by the Department of Motor Vehicles. (see Figure
4.7)
38
Leasing company National Registry Employee
Lease car
extend
Lessee
Sell car
after lease
Figure 4.2: Use case for a car lease.

Set the
Owner car as a National Registry Employee
guarantee
for a loan
Creditor
Figure 4.3: Use case for registering a vehicle as guarantee for a loan.

Manufacturer Register National Registry Employee

new car
Figure 4.4: Use case for registering a new vehicle in the Bcar System

Authority Verify car

ownership
Figure 4.5: Use case for verifying vehicle’s ownership information.
39
Judge Override car

ownership
National Registry Employee
Figure 4.6: Use case for overriding a vehicle’s ownership in BCar system

National Registry Employee Update car

information
extend
Update car
condition
Figure 4.7: Use case for updating vehicle’s information on BCar system.
4.2 Solution
Considering the granular access control required for a government service, such as the car registration
system, it was necessary to select a permissioned blockchain. As we intend to provide most of the
blockchain control to a set of entities such as the national registry institution of each European state
member.
In this scenario we can have nodes restricted to accessing system records, therefore this nodes do
not participate in the consensus mechanisms and can not submit car registration transactions. Other
nodes such as the nodes controlled by governments may have higher permissions to the system and
may validate and execute smart contracts and transactions.
This configuration ensures the safety and confidentiality of data. As a private blockchain, only au-
thorized nodes detained by the government entities or by trusted external entities related to the car
registration system, such as leasing companies or the government entities responsible for car registra-
tion within the European Union, can join the network. Hyperledger Fabric provides a set of configurations
enabling the specification of strict rules for access control for each participant defined in the system. This
enables that a search by registration number is available to any entity interested in the characteristic of
the vehicle associated, as this information is public domain. However requires that a search for the set
of vehicles owned by a specific entity, must be done by government entities.
40
4.2.1 Participant definition
As the car registration system requires access control to registry information, a set of participants were
defined and their specific permissions. Considering main and secondary use cases specified in Section
4.1, five concrete participants were defined. A class diagram as an overview of the informations stored
for each participant of the car registration system can be consulted in Figure 4.8.
Person
A Person type participant encompasses the simplest entity able to take ownership of a vehicle. As
other singular entities are represented in the system, a person inherits from an abstract Singular Entity
participant A Singular Entity participant type is defined by, a name, an address which represents the
official residence of the entity and its fiscal number. Optionally the personal identification document
number can be stored with the remaining information, although only a fiscal number is required to identify
a person in the car registration system. A person is able to execute the following operations, when
owning a vehicle:
• Start a change of ownership of a vehicle
• Start a lease contract
• Request a lease contract cancellation
• Reject a lease contract cancellation
• Accept a lease contract cancellation
• Add the vehicle as guarantee for a loan
• Request for a vehicle guarantee to be canceled
Company
A collective entity, thus a registered collective of entities, is represented as a Company type participant
on the proposed car registration system. Similarly to a Person type participant, it is identified by a name,
a official fiscal address and a fiscal number which are all encoded as strings on the data model. A
fiscal number is the primary identifier of a company in this car registration system. A Company type
participant, requires not only the above mentioned data, but also a list of entities which are Person
type participants. This entities, identified in a Company participant, are the Company owners or entities
responsible for this Company’s actions on the car registration system.
As a Company does not represent a singular entity, car registry operations can not be performed by
a Company type participant. Car registry operations on behalf of a Company participant are required
to be performed by the singular entities identified as Company owners or Person type participants in
charge of the Company’s actions on the car registration system. Participants in charge of Company’s
actions can perform the same operations as described earlier in the Person type participant description.
41
Car registry operations performed in behalf of a Company are complex when considering a Company
with multiple owners or manager and even considering companies can also be owners of other compa-
nies or that multiple owners can each have different percentage ownership over a Company. However,
complex operations performed in behalf of Companies with multiple owners or managers deviate from
the principal scope of this thesis. Thus, for the scope of this thesis we consider a Company can only
be owned or managed by singular entities (Person type participant) and it only requires a single owner
or manager entity to issue a request to the blockchain based car registration system in order to execute
the request.
Judicial Officer
Certain operations within the car registration system can only be performed by certified participants.
Within the set of this operations are the ones executed as fulfillment of a judicial order issued. Thus,
judicial entities need to have permission to execute those operations, judicial entities are represented in
the proposed car registration system by Judicial Officer type participants.
There is a range of different courts with specific responsibilities and some courts can overrule pre-
viously issued decisions by lower instance courts. The Judicial system is itself a complex system and
it is required to follow a strict set of rules according to different court cases. The complete mapping of
powers from Judicial authorities to the available car registration operations is outside the scope of this
thesis.
As simplification of the judicial entities responsible to execute car registry operation within this infor-
mation system we define the Judicial Officer participant type with no hierarchical permissions, so any
Judicial Officer is able to override another’s Judicial Officer decision. A Judicial Officer participant type
is extended from a Singular Entity participant type, thus includes the same data required to identify a
Person type participant already described. On the other hand a Judicial Officer is also required to have
an additional field called court, which is encoded as a string, and registers the judicial entity in which the
Judicial Officer works and identifies the entity from which the car registry operations were issued.
Registry Employee
A registry employee is defined as an extension to a Singular Entity type participant. A registry employee
is required to be associated with a employee number, in order to uniquely identify each registry em-
ployee and the registry entities they work for. A Registry Employee type is destined to users of the car
registration system, working for national registry entities. When compared to the other participant types,
registry employees have unrestricted permissions to car registries in the information system. Thus, can
update car registries and change vehicle states in the registry when considering leases, judicial orders,
ownership changes or other operations performed within the car registration system.
Although a blockchain car registration system aims to decentralize the car registration information
system, when compared to centralized information systems, there are other advantages to opting for a
car registration system based on blockchain technology. This issue was lightly discussed on Chapter
42
Entity
+ name : String
+ address : String
+ fiscal number : String
Singular Entitiy Company
+ surname : String
+ idNumber : String [0..1]
1..*
Person
Registry Employee External Entity Judicial Officer
+ employeeNr : String + court : String
Figure 4.8: Proposed car registry system’s participant types
2, regarding the advantages and disadvantages of such system. As mentioned blockchain technology
is capable of completely removing centralized authorities as national registry entities. However the car
registration system proposed is able to maintain some of the characteristics of a centralized information
system, as granular access control. Therefore the existence of a Registry Employee participant type in
the car registration system based on blockchain also enables for easier maintenance of car registration
information. Registry Employee participants are able to solve conflicts if they arise on the system and
are still accountable for their actions given the nature and architecture of the blockchain technology.
External Entity
An additional participant was required to be defined in order to include operation’s permissions within
the car registration system which were executed by external entities to the national registry and were
not included in the above mentioned participant types. It is the case of a secondary use case described
in Section 4.1 of this chapter, an authority needs to verify the ownership of a car. Other cases are
also required to be included in the External Entity participant type, such as, searching for cars owned
by a specific person or entity. The latter case requires fine tuned access control rules, as the informa-
tion regarding who is the owner of a specific vehicle is public domain. However, information regarding
which vehicles are owned by a specific entity are not classified as public domain information, but this
type of information is still required to perform certain operations and are allowed to a restrict group of
participants.
43
State Description
Active Vehicle in circulation
Vehicle no longer
Inactive in circulation
(e.g. exported vehicle)
Vehicle with
Destructed a destruction
order issued
Vehicle reported
Suspended as not proper
for circulation
Vehicle reported
Stolen as stolen
by authorities
Table 4.1: VehicleState object possible states.
4.2.2 Data model
Based on European regulations for motorized vehicles [27] and the vehicle registration modification
form [26], a simplified data model was built. The resulting data model was also based on the use cases
specified in Section 4.1 and also identifies the set of participants described on Section 4.2.1.
A vehicle is registered in the car registration system with the following information, a registration
number, a make, a Vehicle Identification Number (VIN) and category. Vehicle owners are identified and
their shares are registered in a Ownership object. A Ownership object for each owner is associated with
the vehicle, as presented on Figure 4.9. A share is represented as percentage such that the total shares
registered to a vehicle always sum to 1.00 or 100%. Given the available operations for car registries, a
state will be registered to the Ownership object, as well as the expected new Owner when a change of
ownership operation is being processed. Further explanation on the design of the Ownership object will
be given in Section 4.2.3.
Considering vehicle category’s classification [28], a vehicle can be categorized as able to carry pas-
sengers (M), able to carry goods (N), 2 or 3 wheel vehicle or a quadricycle (L) and agricultural and
forestry tractors and their trailers (T). Further classification is required when a vehicle is categorized
with type M or N. In case of vehicles carrying passengers (M) or goods (N), they are also categorized
in classes by their weight as light duty vehicles when under 3500 Kg and heavy duty vehicles when
equal or above 3500 Kg. A vehicle can be registered in the car registration system in several conditions,
this information is stored as a VehicleState type in state variable presented in the proposed data model
of Figure 4.9. Different available states a vehicle can belong to are presented in Table 4.1. Initially, a
vehicle is registered as belonging to an Active state.
Analyzing special conditions possible for a vehicle, information regarding leases, loans or in extreme
cases seizures are also stored in the car registration system. Lease information related to a certain
vehicle is registered, on the blockchain based car registration system, when a vehicle is subject to a
lease contract. This information,as presented in Figure 4.9, is stored in the Lease Info object associated
with the vehicle. The start and end dates of the lease contract and the total value agreed to be paid by
the lessee to the lessor during the contract’s specified dates are stored in the Lease Info object. Lease
44
Info object also registers the entity assign as the lessee of the contract, as well as the entity who issued
the last operation, in the system, related to this lease contract. Specific details on the information stored
by the car registration system for lease contracts will be provided, in Section 4.2.3, on the context of the
lease operations available in the system.
A vehicle can be submitted as collateral for loans, therefore the entity responsible for the loan and
possible penalties are registered, as well as the total value of the loan and its type. An asset registered
as loan guarantee, in this case a vehicle, can assure a certain loan according to different degrees of
liability which varies with the existing loan types. A loan can either be classified as a mortgage or as a
collateral loan. The different loan types lead to different procedures in case of bankruptcy of the owner
or seizure of the vehicle for various other reasons.
A mortgage loan does not separate the asset, in this case a vehicle, from the remaining assets
owned by the vehicle owner in event of bankruptcy. Thus, the vehicle will be included in the available
assets to be liquidated in order to rebate debt. The creditor associated with the mortgage loan will have
to be included on the set of creditors who require liquidation of assets in order to remove the vehicle’s
owner debt. On the other hand, considering a vehicle tied to a collateral loan, in event of the owner
declaring bankruptcy, the vehicle will not be included in the set of assets available to pay off the debts
that lead to owner’s bankruptcy. The only entity entitled to liquidate the vehicle, so the owner can pay
off his debts, is the entity to which the vehicle’s loan is associated with. A loan guarantee is intended to
provide a guarantee for loan payment, in this case the vehicle. Thus, we consider each vehicle must be
tied to a maximum of one loan at a time.
Lastly, we consider the case of vehicle seizures resulted from court orders or other judicial entity’s
decisions. As part of a judicial decision, an asset can be secured by court until the judicial case is
solved, this situation leads to the issue of a pending seizure order. A seizure is the action of forcible
taking a property from a person who is suspected of violating the law or is known to have violated the
law. A pending seizure (”Arresto”) could be put in place to ensure an asset subject to it will not change
ownership before the matter which led to the pending seizure order is solved.
4.2.3 Car registry operations
Create a Vehicle
Registering a vehicle on the car registrations system is usually an operation done by a national registry
entity. However most of the vehicle information is given by an external entity responsible for managing
motorized vehicle regulation.
In order to simplify interactions over the blockchain-based car registration system we assume this
information is registered manually by national registry personal. Therefor when a vehicle needs to be
registered, the following information is required: registration number (number plate), VIN, make, model,
vehicle category and the owners information along with their respective shares.
A vehicle creation transaction can only be issued by registry employee participant thus internal per-
sonal of each national registry institution of each state member. During the execution of a create Vehicle
45
Vehicle
+ registration number : String

+ make : String
+ vin : String
+ category : VehicleCategory
+ class : VehicleClass [0..1]
+ state : VehicleState
0..1
0..1 0..1
Loan 1..* Lease Info
Seizure Ownership
+ type : LoanType + start Date : DateTime
+ total Value : Double + total Value : Double + share : Double + end Date : DateTime
+ penalty : Double + status : State + state : State + total Value : Double
+ waiting Cancelation : Bool [0..1] + state : State
2
Entity
+ name : String
+ address : String
+ fiscal number : String
Figure 4.9: Proposed vehicle data model
46
Class Description
Light weight Vehicle not exceeding 3.5 tonnes
Heavy weight Vehicle over 3.5 tonnes
Table 4.2: Vehicle class for vehicles within categories M and N.
transaction, it is required that the information about the vehicle complies to a set of rules. We will go
over each of the rules encoded in the smart contracts to ensure a vehicle is correctly registered in the
proposed car registration system.
As a requirement, the Vehicle Identification Number (VIN) given to a registered vehicle needs to be
unique in the system as this number is composed by a serial number used by the automotive industry
to identify individual vehicles. Therefore each VIN is unique to each motorized vehicle produced in the
world. As the VIN is calculated based on different standards such as ISO 3779 [29] (Used in Europe)
or FMVSS 115, Part 565 [30] (Used in United States and Canada) and vehicles can be imported from
every part of the world, this identifier is registered as a string and no further validation on its constitution
is made, as long as it is unique in the car registration system.
A similar rule is applied to the registration number associated with a vehicle. A registration number
is associated with a motor vehicle or trailer for official identification purpose. The registration plate is a
numeric or alphanumeric identifier and its constitution varies according to the country and some times
the region issuing the vehicle register. This identifier is unique within the entire country and considering
EU member states, unique across the state members. Thus, the vehicles registered in the blockchain
based car registration system must have unique registration numbers. No further validation on the format
of the registration number is made, as across member states there is a wide variety of registration
numbers. Registration number formats may be specific to each country or to vehicles dedicated to
special forces or entities such as diplomatic plates.
As stated in Section 4.2.2, vehicles registered within categories M (passengers) and N (goods) must
be associated with a vehicle class acording to Table 4.2. On the other hand, vehicles identified as
belonging to categories L (quadricycles) or T (trailers) must not be associated with any vehicle class.
Therefore, the Create Vehicle operation ensures this rules are applied.
Change Ownership
Changing ownership of a vehicles is separated in two steps and is specific for each owner, as vehicles
can have multiple owners with different shares each. As expected, this operation is only allowed to be
executed by the owners of the vehicle subject to ownership change.
Usually when executing a vehicle ownership change it is required for the current owner and the future
owner to fill a form [26] and sign it, as discussed in Chapter 3. Latter this form is handled by national
registry institution personal or this hole process can also be started online, still requiring verification by
a national registry employee. However this process can be exploited by the new owner or the old owner
if the form submission is delayed. This can lead to judicial complications as infractions and crimes can
be committed involving the vehicle, thus latter involving the registered owner of the vehicle at the time of
47
Cancel Ownership Change
Valid Ownership Waiting Ownership

(Old Owner) Change Owner Change
Confirm Ownership
Valid Ownership
(New Owner)
Figure 4.10: Change Ownership transaction flow
the wrongdoing.
Considering the different pitfalls for the ownership change and as a suggestion to improve the pro-
cess, a confirmation step was created. Thus the hole ownership change needs to be initialized by the
current owner wishing to give up his position on a certain vehicle, as proposed in Section 3.2.3. This step
requires the owner to issue a Change Owner transaction, specifying the Vehicle Identification Number
(VIN), the registration number and make of the vehicle as well as the list of new owners to which the
current owner will give his share of the vehicle. To execute a Change Owner transaction, it is required
that the owner of the vehicle issuing the transaction specifies the share percentage he wants to transfer
to the new owner. Thus, the owner can transfer the totality of his ownership share to a new owner or a
partial share of his ownership share. On the other hand, the owner is not allowed to transfer to a new
owner a share representing more that the share of the vehicle he owns initial.
As the first step is concluded, the vehicle ownership changes to the new owners. However the
new ownership is still required to be approved by the new owners, ensuring the old owner and new
owners are registered and associated with the vehicle, providing the necessary information in case of
a judicial dispute. This state is represented in Figure 4.10 as Waiting Ownership Change state. In
order to complete the ownership change, only the new owner registered in the initial Change Owner
transaction is able to confirm this operation issuing a Confirm Ownership transaction specifying the
vehicle’s VIN, registration number and make as well as the ownership share intended to be given to
him. Only after this step the ownership information is considered valid, regarding judicial obligations
and the new owners are considered legitimate owners. During the Waiting Ownership Change state,
the vehicle ownership change can be reverted to its initial ownership state in case the entity issuing a
Change Owner transaction, the new proposed owner or a national registry employee issues a Cancel
Ownership Change transaction specifying the vehicle’s VIN, registration number and make.
48
Lease
As proposed in the business process presented in Section 3.2.6, the process for registering a lease con-
tract is separate into a two steps operation. The owner is proposed to issue a Create Lease transaction
which can be canceled through a Cancel Lease transaction by the lessor, the lessee or by a registry
employee. On the other hand, the lease registration can be accepted either by a registry employee or
by the prospect lessee issuing a Confirm Lease transaction. The lease transaction flow on the proposed
car registration system is presented in Figure 4.11.
As part of the Create Lease transaction, the Vehicle Identification Number (VIN), registration number
as well as the make of the vehicle are required. Considering lease contract information, the Create
Lease transaction will also refer the start and end dates of the contract, the expected total value of
the lease and the third-party to which the permission to use the vehicle is given. The Create Lease
transaction can only be issued by the owner of the vehicle. During the execution of the Create Lease
transaction, the smart contract’s function ensures that the lease contract’s end date is a future date, thus
does not allow to register a lease contract that is already expired. Further along the same logic, it is not
possible to execute a Create Lease transaction specifying a end date earlier than a start date.
Once the Create Lease transaction is correctly executed, the vehicle enters the Waiting lease confir-
mation state as presented in Figure 4.11. In order to successfully register a lease contract, the lessee
registered in the initial Create Lease transaction is required to issue a Confirm Lease transaction con-
taining the Vehicle Identification Number (VIN), the vehicle’s make and registration number as well as
the total value accorded in the lease contract. If any of this information required is provided to be wrong,
based on the information already available in the system, the transaction is canceled and the vehicle
remains in Waiting lease confirmation state. In case the transaction issued by the lessee matches with
the information passed by the lessor, in the Create Lease transaction, the system registers the lease as
associated with the vehicle and the vehicle enters the Active lease state.
In few cases, it is necessary to revert a Create Lease transaction when the vehicle is in Waiting
lease confirmation state. Considering this scenario, it is possible to cancel a pending lease by issuing a
Cancel Lease transaction. A Cancel Lease transaction can be executed by any of the parties involved,
either the lessor, the lessee or a national registry employee. Cancel Lease transaction must contain the
Vehicle Identification Number (VIN), registration number, make, the total value contracted on the lease,
as well as the respective parties involved, the lessee and the lessor.
Each vehicle can be owned by multiple owners and each owner can have different shares of own-
ership associated with the vehicle. Therefore it is also necessary to consider the lease transaction flow
of Figure 4.11 on a multiple owners’ vehicle. A voting system could be engineered to approve this op-
erations, however a simplified version was implemented. As long as the Create Lease transaction is
issued to a vehicle by one of its owners, the transaction is valid. No further mechanisms need to be
implemented as any other owner of the vehicle can be notified if this action is issued. In case any of the
owners does not agree with the lease action imposed, he can issue a Cancel Lease transaction. As the
Cancel Lease transaction is executed, the vehicle returns to a No lease state.
At any time an active lease can be canceled as long as the two parties agree on termination or if
49
a judicial officer takes action to cancel the contract. For a lease contract termination to happen, it is
necessary to issue a Cancel Lease transaction. Considering the Cancel Lease operation is issued by a
judicial officer, this action takes effect immediately, thus the lease contract is revoked.
In case the Cancel Lease transaction is issued by a lessee or a lessor and the vehicle is in Active
lease state, the process takes two steps, as both parties need to agree on canceling the contract. To
this extent, the first transaction to be issued will be the Cancel Lease transaction, thus the lease contract
state is changed to Waiting lease cancellation. As a contract enters the state of Waiting lease cancel-
lation, any of the parties can revert the cancellation process by issuing a Cancel Lease Termination,
specifying the Vehicle Identification Number (VIN), the vehicle’s make and registration number. For the
lease contract to be actually terminated, after the vehicle is in Waiting cancellation state, it is necessary
for the other party to issue a Confirm Lease Termination transaction with the same arguments as Cancel
Lease transaction. Thus, admitting the lessor issues a Cancel Lease transaction, it is required for the
lessee to issue a Confirm Lease Termination and the other way around in case Cancel Lease is issued
by the lessee.
On the other hand, it is possible for the lessor or the lessee to reject or cancel the lease termination
process by issuing Cancel Lease Termination transaction. A Cancel Lease Termination transaction
is required to specify the Vehicle Identification Number (VIN), the vehicle’s make and its registration
number. As this transaction is executed, the vehicle returns to the Active lease state. When a vehicle is
in Waiting Lease Cancellation state it is possible for a national registry employee to take action and issue
either a Confirm Lease Termination or a Cancel Lease Termination in order to solve possible conflicts
that may arise during this transaction flow.
As it should be expected, the proposed car registration system only allows the issuance of a Create
Lease transaction when no lease is associated with the vehicle. As presented in Figure 4.11, a Confirm
Lease transaction is only allowed to be executed when the vehicle is in Waiting lease confirmation
state and the Cancel Lease transaction is only allowed when the vehicle is either in Waiting lease
confirmation state or in Active lease state. Finally, it is only possible to execute the Confirm Lease
Termination transaction or the Cancel Lease Termination transaction when the vehicle is in Waiting
lease cancellation state.
Seize Vehicle
Given a process on which a vehicle owner is subject to a court to liquidate his debts, judicial officers
can seize a vehicle or issue a pending seizure. Thus, if a pending seizure is in place, the asset can not
be sold or change ownership until the process is solved. Latter the same process can also result in a
seizure and the ownership of the asset can only be changed according to court order.
In order to issue a pending seizure for a vehicle, a judicial officer is required to submit a Issue
Pending Seizure transaction. A Issue Pending Seizure transaction should contain information about the
owner of the vehicle, the total value in debt, the creditor and information about the vehicle as the Vehicle
Identification Number (VIN), registration number and make. As a Issue Pending Seizure transaction is
successfully executed, the vehicle enters a Pending seizure state. This transaction can only be issued
50
Waiting vehicle
No lease
lease cancellation
Confirm Lease
Termination
Create Lease Cancel Lease

Cancel Lease Cancel Lease
Termination
Waiting vehicle Vehicle with

lease confirmation active lease
Confirm Lease
Figure 4.11: Lease transaction flow
by a judicial officer in order to take effect. Considering a vehicle tied to a loan as collateral (Registering a
vehicle as guarantee will be specified in the next section), a Issue Pending Seizure transaction will only
be accepted, by the proposed system, if the creditor registered in this transaction is the same creditor
tied to the loan to which the vehicle is registered as guarantee. However, if the vehicle is registered
as guarantee for a mortgage loan, it is possible for a judicial officer to order a Issue Pending Seizure
transaction referring to any creditor.
Considering a case on which the Pending seizure state needs to be reverted, a Cancel Seizure trans-
action should be emitted. A Cancel Seizure transaction should contain the same information required for
the Issue Pending Seizure transaction. Thus, this transaction is required to contain information regard-
ing the owner of the vehicle, the total value in debt, the registration number, make, Vehicle Identification
Number (VIN) and the creditor to which the pending seizure was tied to. The Cancel Seizure transaction
can only be issued by a judicial officer.
As a vehicle enters Pending Seizure state, it is possible to latter seize the asset once the judicial
process is concluded. In order to effectively seize the asset, a Issue Seizure transaction is required to
be issued. A Issue Seizure transaction requires the same information used by Issue Pending Seizure
transaction, but also requires to refer the date on which the seizure order was emitted and the court
order number supporting this decision. When a vehicle is in its initial state, no seizure nor pending
seizure associated, it is possible for the judicial officer to directly emit a Issue Seizure transaction.
Once a Issue Seizure transaction is called by a judicial officer, the vehicle directly enters New owner
state, as long as the vehicle is not registered as guarantee for a collateral loan. Regarding the case
when a vehicle is registered as guarantee for a collateral loan, the same principle described for Issue
Pending Seizure transaction applies, thus the Issue Seizure transaction only succeeds if the creditor
implied in the seizure order is the same creditor entitled to take the vehicle as guarantee for the loan. On
the other hand, the car registration system proposed only allows to execute a Issue Seizure transaction
as long as the creditor and the total value of the debt complies with the information registered during
the Issue Pending Seizure transaction. During Issue Seizure transaction execution, the ownership of
51
Cancel Seizure
Vehicle with
no seizure nor Vehicle with
pending seizure Issue Pending Seizure pending seizure
Issue Seizure
Issue Seizure
Vehicle with
new owner
Figure 4.12: Vehicle seizure flow
the vehicle is changed so the owner implied in the seizure is removed as owner. As replacement, the
creditor specified in the Issue Seizure transaction is assigned as an owner of the vehicle, attaining the
same share previously attributed to the replaced owner.
A vehicle is able to have simultaneous owners. Thus it is possible to execute the complete vehicle
seizure flow presented in Figure 4.12, regardless the number or owners tied to the vehicle. Nonethe-
less, as simplification of the seizure process implementation, only a single process can occur at time.
Therefore, it is not possible to issue a Issue Pending Seizure transaction or a Issue Seizure transaction
to another owner nor creditor if a vehicle is in Pending Seizure state.
Register as Guarantee
A secondary operation available on the a vehicle registration system is the possibility to register a vehicle
as a guarantee for a loan issued to the vehicle owner. Analyzing the process of registering an asset as
guarantee for a loan, there are two different types of guarantee. Assets subject to loan guarantees can
be registered for mortgage loans or collateral loans, as presented in Chapter 3.
In order to register a vehicle as guarantee, the vehicle’s owner is required to order a Register Guar-
antee transaction mentioning the creditor, the type of loan (Collateral or Mortgage), total value of the
loan given to the vehicle owner and the penalty to which the debtor needs to pay in case the loan is paid
ahead of time. Vehicle information is also registered on the Register Guarantee transaction, such as
the registration number, make and Vehicle Identification Number (VIN). During the Register Guarantee
transaction execution, a set of rules is verified in order for the transaction to be successful. The trans-
action can only be issued by the owner and it is not possible to register a vehicle as a guarantee to a
loan if the vehicle is already tied as a guarantee to a previously issued loan. The Register Guarantee
transaction will not succeed if the vehicle is subject to a seizure or a pending seizure by a judicial order.
Considering the Register Guarantee transaction is successfully executed, the vehicle enters Vehicle as
52
Vehicle with Pending guarantee
no loan guarantee cancelation
Confirm Cancelation
Reject Cancela-
Cancel Guarantee
Cancel Guarantee tion
Vehicle as
Register as Guarantee loan guarantee
Figure 4.13: Register vehicle as guarantee flow
loan guarantee state.
As defined in section 4.2.2, a vehicle can be associated with multiple owners. However registering a
vehicle as guarantee for a loan, we assume it is only possible to successfully issue a Register Guarantee
transaction if the vehicle is possession of a single owner. This requirement is based on the fact that, in
case of bankruptcy of the owner, it will require a long process for the creditor to rescue a multiple owner’s
vehicle in order to liquidate debt. Based on this factor we also assume most of the creditors would not
accept a vehicle with multiple owners as guarantee for a loan.
It is possible to cancel the guarantee by issuing a Cancel Guarantee transaction. In this situation,
a similar flow to the one presented for cancelling a lease, in Figure 4.11, is executed. A creditor can
issue a Cancel Guarantee transaction with immediate effects, requiring to identify the vehicle though
the Vehicle Identification Number (VIN), registration number and make. As the Cancel Guarantee trans-
action is issued by the creditor or a national registry employee and successfully executed, the vehicle
enters No loan guarantee state, as presented in Figure 4.13. On the other hand, if Cancel Guaran-
tee transaction is issued by the vehicle owner it requires the creditor to confirm or deny the operation
using accordingly the transactions Confirm Guarantee Cancellation or Reject Guarantee Cancellation.
Both Confirm Guarantee Cancellation and Reject Guarantee Cancellation transactions are required to
include the Vehicle Identification Number (VIN), registration number and make. As a vehicle is subject
to a Cancel Guarantee transaction, the vehicle guarantee enters the state of Pending guarantee cancel-
lation and the guarantee is removed once a Confirm Cancellation transaction is executed successfully.
The Confirm Cancellation transaction is required to be issued by the creditor associated with the loan
guarantee or by a national registry employee. On the other hand, as a Reject Guarantee Cancellation
transaction is issued by the creditor or by a registry employee, the vehicle enters No loan guarantee
state.
53
Change Vehicle State
As presented in vehicle data model of Figure 4.9 and explained in Section 4.2.2, a vehicle can be
registered in the proposed car registration system according to different states. A change in a registered
vehicle’s state is usually presented by an external entity such as the Department of Motor Vehicles,
however as simplification, the national registry employee is in charge of this update on the car registration
system. Thus, as a national registry employee receives a request for updating the state of a vehicle in
the system, he issues a Change State transaction.
A Change State transaction is required to specify the vehicle’s make and registration number to which
the state update is necessary. This transaction is also required to include the new state to which the
vehicle will transit to and the Vehicle Identification Number (VIN). The vehicle states which a vehicle can
have were already described in Section 4.2.2.
A Change State transaction can change a vehicle state to any available state. Furthermore, a vehicle
can transit from any vehicle state to any other available state. However, participants in the system, other
than Registry employee type participants, are not allowed to execute the Change State transaction.
4.3 System Overview
As of the distributed nature of a blockchain infrastructure, the transaction flows defined in Section 4.2.3
are issued by a client application with the responsibility to communicate with the Hyperledger Fabric
infrastructure in place. Further in Chapter 5 we will go over some of the implementation details of the
proposed system. A high-level system overview is presented in Figure 4.14.
Let us consider a system composed by three organizations. In the particular scenario of the BCar
System we can consider a National Registry Entity of a country (as an Endorsement Organization in
Figure 4.14). The remaining two organizations (Organization 1 and Organization 2 in Figure 4.14) can
be attributed to entities interested in maintaining a record of the system but unauthorized to validate
transactions, for instance a tax authority and the police. As presented in Chapter 2, Hyperledger Fabric
requires a Ordering Service responsible for ensuring transactions submitted to the system are correctly
endorsed by the corresponding peers and blocks are unanimously elected and added to the blockchain.
Considering a transaction issued by a client, firstly the transaction should be submitted to the en-
dorsement peers so the validity of the transaction can be verified. Once this step is completed, the
client is responsible for submitting the transaction to the ordering service. The ordering service is re-
sponsible for creating a block containing a batch of transactions, which is latter broadcast to the existing
organizations.
54
Figure 4.14: Block diagram of the BCar System
55
56
Chapter 5
Implementation
Based on the data model described on Section 4.2.2 a similar data model was created using a domain
specific language of Hyperledger Composer (see Appendix A) which latter was deployed to a Hyper-
ledger Fabric version 1.1 based network. Hyperledger Composer Modeling Language is an object-
oriented modeling language designed to define the domain model for a business network defined for
the Hyperledger Fabric. Each transaction described through out Section 4.2.3 was also modeled in
Hyperledger Composer Modeling Language (see Appendix A). Every information regarding the created
data model was stored on the Hyperledger Fabric’s blockchain with no off-chain database handling car
registry records.
Hyperledger Composer Modeling Language is composed by a defined namespace, where all re-
source declarations within a file should take place and a set of resource definitions declaring assets,
transactions, participants and events. This modeling language can also define enumerated types and
concepts which can be used as part of participant, asset or transaction data and can be used to bundle
sets of related information. Optionally super-types can also be defined and other resource definitions
can extend from this super-types, inheriting super-types’ data fields. Abstract resources can also be
defined, requiring more specific resource definitions to extend from them.
Transactions tied to smart contracts were also defined as resources using the domain specific model-
ing language. Furthermore, all the developed smart contract functions where developed using Javascript
and Hyperledger Composer API version 0.19.7. Hyperledger Composer API is available in a set of lan-
guages and is built based on the idea that smart contracts should not require a domain specific program-
ming language for their development. Thus, Hyperledger Composer provides an interface adaptable to
any language to interact with Hyperledger Fabric blockchain, currently there is also an implementation
of this API for Golang.
Specific access control rules where defined using Hyperledger Composer access control language.
Hyperledger Composer access control is define trough a set of rules which can detail CRUD access
control considering the participant executing the transaction or reading asset information. Access control
is fine grained with the ability to restrict access to certain participants only through specific pieces of
data of an asset and through specific transactions. Therefor a set of rules where created to enforce
57
Operation Description
Permission to create
Create
the resource
Permission to read
Read
the resource
Permission to update
Update
the resource
Permission to delete
Delete
the resource
Permission to perform all the above
All
mentioned operations to the resource
Table 5.1: Operation types for resource access control.
permissions for each participant and each transaction.

Considering the access control mechanism embedded in Hyperledger Composer, we modeled most
of the access control rules through an access control language specific to the platform. Each rule is
identified with a name and description. A rule identifies the participant and the resource to which its
applied. Furthermore, the operations to which the rule applies are specified and multiple operations can
be associated with the rule. The available operations are described in Table 5.1. The action intended
to be performed by the rule is also specified. Thus an action can be defined as ALLOW, allowing the
participant to perform the specified operations to the resource, or as DENY, requiring the access control
system to block any attempt from the specified participant to execute rule’s operations to the resource.
Regarding access control rules, two more specifications can be embedded in them. One of which
is the transaction field, this enables to block unlimited access to a resource by some participant types.
Therefore, it is possible to ensure by access control rules that a participant can only update a specific
asset’s information if this update is done through a specific transaction defined in the smart contract.
Furthermore an optional condition field can ensure certain boolean conditions are met in order for the
participant to be allowed to execute the actions specified in the access control rule.
5.1 Implemented access control rules
The Hyperledger Composer’s access control mechanism is defined such that any operation to all re-
sources available is blocked by default, unless a defined access control rule allows that operation. Thus,
in this section we will present the access control rules in place for the proposed car registration sys-
tem. The access control rules implemented were defined based on the business processes discussed
in Chapter 3 and the requirements specified in Chapter 4.
Regarding the vehicle creation, as presented in Section 3.2.1 and latter described in Section 4.2.3,
this operation can only be executed by a Registry Employee participant type. Thus, a rule allowing
Registry Employee type participants to issue Create Vehicle transactions was created. As of this fact,
a rule allowing Regisry Employee type participants to perform all operations, specified in Table 5.1, to
vehicle registries through Create Vehicle transaction.
Considering Change Ownership transactions, all Entity participants, thus all participants of the sys-
58
tem are entitled to issue this transaction. Access control rules for this transaction could be tighter by
asserting the participant issuing the transaction is a Registry Entity participant or a Person participant
who is the owner or is part of a Company who owns the vehicle. However, the verification of this rules
is done through the smart contract’s code, as verifying this rules through the access control mechanism
leads to performance issues. As Change Ownership transactions change ownership properties of a
vehicle, an additional rule is defined in order to allow any Entity type participant to read and update
vehicle’s information. However this rule only allows to read and update vehicle’s information through the
Change Ownership transactions.
As the change of ownership flow described in Section 4.2.3 includes a second step, through Confirm
Ownership or Cancel Ownership transactions, a set of rules where also modeled for this transactions.
Therefor both transactions have rules defined in the access control mechanism such that any Entity
participant is able to create Confirm Ownership or Cancel Ownership transactions. However, this trans-
actions only have allowance to update the vehicle specified in the issued transaction. As in Change
Ownership transactions, specific rules on verifying that only the owner, owner of the Company owning
the vehicle or a registry employee have permissions to issue Confirm Ownership and Cancel Ownership
transactions.
In the process of creating a lease, as issuing a Create Lease transaction, only the Registry Em-
ployee participants and vehicle owners are entitled to execute this transaction. As presented earlier
in this Section, given performance issues, the access control verification when issuing a Create Lease
transaction is provided through the smart contract. While creating a lease, vehicle’s information needs
to be updated, thus rules providing permissions to Entity participants to update vehicle’s information are
defined in the access control mechanism in place for Hyperledger Composer. Regarding lease transac-
tion flow, as mentioned in Section 4.2.3, the same rules, as described for Create Lease transaction, are
defined for Confirm Lease, Cancel Lease, Confirm Lease Termination and Cancel Lease Termination
transactions.
Access control rules are also defined for vehicle seizure flow, described in Section 4.2.3. All transac-
tions regarding seizure flow, thus Issue Pending Seizure , Issue Seizure and Cancel Seizure transactions
will have the same rules as following. Hyperledger Composer access control mechanism will have a rule
defined allowing Judicial Officer and Registry Employee participant types to create each of the vehicle
seizure flow transactions. Thus an additional rule is created for each of those transactions to allow
the update of vehicle’s information through the transactions by Judicial Officer and Registry Employee
participant types.
Registering a vehicle as guarantee (Register as Guarante and Cancel Guarantee transactions),

through the flow described in Section 4.2.3, requires that only vehicle owners or registry employees
are allowed to execute the transaction. As this rule requires the verification of ownership to cases
where a vehicle owner can be a Company. This verification presents performance issues when modeled
through the access control mechanism of Hyperledger Composer. Thus, the verification of ownership
and verifying that the transaction issuer is a registry employee is made trough the smart contract’s code.
On the other hand, rules allowing the update of vehicle’s information by Register as Guarnatee, Cancel
59
Guarantee, Confirm Cancellation and Reject Cancelation transactions are defined through Hyperledger
Composer’s access control mechanism. Regarding Cancel Guarnatee, Confirm Cancelation and Reject
Cancelation transactions, when issued by a creditor, a verification that the issuer is a creditor for the
loan is also made through the smart contract’s code.
Finally, Change Vehicle State transaction, two rules are defined in the Hyperledger Composer access
control mechanism. This mechanisms only allows Registry Employee participant types to create Change
Vehicle State transaction. A second rule encodes that a Registry Employee is able to update vehicle’s
information through Change Vehicle State transaction.
5.2 Hyperledger Fabric configuration
As mentioned in Section 2.5.2, Hyperledger Fabric presents multiple configuration setups. A one node
ordering service, used mostly for development environments and for production grade infrastructure
a Crash Fault Tolerant (CFT) based ordering service supported by a Kafka cluster 1 . In this section
we will go over each system’s components, explaining their contribution for the an Hyperledger Fabric
infrastructure. Then we present how a client is able to interact with the Hyperledger Fabric’s blockchain
and describe each step required to execute a transaction, from the moment the transaction is issued to
the final steps taken to add the transaction’s updates to the blockchain.
5.2.1 System components
As part of the Hyperledger Fabric infrastructure, a network peer can be a endorsement peer, an anchor
peer or a normal peer. As each peer type is not mutually exclusive, it is possible for a peer to be both a
endorsement peer and an anchor peer, as in Figure 5.1. Aside from the blockchain, every peer maintains
a state database to keep track of the blockchain state. The state database is responsible for storing the
latest key values known, thus a state database provides an indexed view of the blockchain’s transaction
logs. Each peer uses by default LevelDB2 as a state database embedded in the peer process. Smart
contracts’ data is stored as key-value pairs in this database. Thus, when executing a transaction, the
state database is used to make chaincode execution more efficient. As alternative, CouchDB3 can
be used as an external state database, providing additional query support and richer queries when
compared with the default state database.
Regarding the different peer types, an endorsement peer is responsible for validating transactions
by executing transactions’ chaincode (functions of the smart contract required by the transaction). Once
a transaction is correctly executed by the endorsement peer, the transaction is signed. On the other
hand an anchor peer is responsible for communicating with the Hyperledger Fabric network exterior to
the organization on which it belongs. Thus, an anchor peer acts as a bridge between organization’s
peers and all Hyperledger Fabric components outside of the organization. Finally, a normal peer is only
1 Kafka- https://kafka.apache.org
2 LevelDB - http://leveldb.org
3 CouchDB - http://couchdb.apache.org
60
responsible for receiving a block of transactions issued by the ordering service and updating its local
blockchain with the corresponding block, this operation is not exclusive to this type of peers as every
peer is responsible for maintaining a local blockchain.
The ordering service is a core component of any Hyperledger Fabric infrastructure. The service is
composed by ordering nodes (see Figure 5.1), responsible for reaching a consensus on building a block
of transactions to update the blockchain. As part of the infrastructure, ordering nodes gather transactions
submitted by clients, verify the endorsement signatures of those transactions and build a block containing
a batch of signed and verified transactions. The endorsement policies in place may vary according to
the configuration setup for a specific Hyperledger Fabric network, defined by network’s administrators.
Let us assume as example, for the BCar System (as in Figure 5.1) a single endorsement signature is
required in order for the transaction to be valid. Considering a network composed by an higher number
of organizations, such as Registry Entities from various European member states, a policy requiring ten
out of twenty seven endorsement peers to validate and sign a transaction could be applied.
As in Figure 5.1, three organizations are presented and each of them is composed by four peers.
An endorsement organization (which can be a National Registry Entity) is responsible for endorsing
transactions, thus is composed by two endorsement peers and two normal peers. In addition, an en-
dorsement peer and a normal peer also act as anchor peers, handling Fabric’s communications outside
of the organization. The remaining organizations, presented in Figure 5.1, are composed by four peers
each and two of those peers act as anchor peers for the organizations.
An ordering service is presented, composed by three orderers in order for the infrastructure to be fault
tolerant. Those orderers are responsible for handling all correctly endorsed transactions and provide a
block with a batch of transactions to all peers of the network, in order to update the blockchain.
Finally we consider a client application which is responsible for providing a platform for the end-users
to use the BCar system proposed. The client application interacts with the blockchain infrastructure
through an API provided by Hyperledger Fabric.
In order for the different components to interact and to maintain access control to information stored
in the blockchain, Hyperledger Fabric provides channels. Thus, a channel enables the access to in-
formation on the blockchain as well as to issue updates to the blockchain. The access to a channel is
provided though certificate authorities, who issue certificates to every participant with access to a certain
channel. In case of the BCar system, a unique channel is used in the Hyperledger Fabric infrastructure.
5.2.2 System behavior
In order to use the proposed system, a client connects to an Hyperledger Fabric network running the
described smart contract functions. This connection is established using Hyperledger Fabric API. Con-
sidering the client requires to access information stored in the blockchain, without changing blockchain’s
state, the client invokes smart contract’s functions to read the required information. This operation only
required the client to have permissions to access this information and to contact a network peer.
On the other hand, transactions with intent to update blockchain’s state require to be submitted
61
Figure 5.1: Component diagram of Hyperledger Fabric infrastructure
62
:Client :Endorsement Peer :Peer :Orderer
connect()
connection established
invokeChainCode(proposal)
generateResponse(proposal)
proposal response
requestOrdering(proposal + Responses)
generateBlock(proposal)
block
updateLedger(block)
updateLedger(block)
Figure 5.2: Block proposal and addition mechanism for Hyperledger Fabric.
through Fabric’s consensus mechanism, as shown in Figure 5.2. A client submitting an action implying
new information to be added to the blockchain firstly establishes a connection with a network peer. Then
he submits the blockchain’s update proposal to a sub-set of peers responsible for verifying and signing
transaction proposals, named endorsement peers. According to a customizable policy, a specific number
of valid proposal signatures are required in order for the transaction proposal to be accepted as valid by
the network peers.
As the client collects the required proposal signatures, the list of signatures along with the proposal
are sent to a ordering peer (or orderer), responsible for grouping signed transactions into a block, order-
ing them. Once transactions are ordered into a block, the block is sent to every peer on the network and
the blockchain is updated with the newly proposed block.
63
64
Chapter 6
Results
In this chapter we go over the environment used to perform Bcar registration system’s tests, analyze
some of the metrics retrived and provide a reflection over the test results. We start by describing the
experimental setup on which the tests where performed, specifying the characteristics of the servers
used as well as their software versions and configuration. Then we present the methodology defined
to perform the system load tests, as well as the various configurations regarding blocks size and send
rate. Later we provide the information collected during the performance tests related to latency and
throughput results, discussing the results aiming to provide the best configuration for the setup. Finally,
we go over the system’s resource usage during the performance tests in attempt to identify bottlenecks.
6.1 Experimental Setup
To assess the performance of the blockchain based car registration system proposed we had at our
disposal a single Virtual Machine (VM) with 8vCPU, 32 GB of RAM and 40 GB of HDD space, running
Ubuntu Xenial (16.04.5 LTS). Regarding the software setup, tests were performed on top of Docker
containers running over Docker v18.06.0-ce. Each peer, certified authority node and orderer was running
on the base image of Hyperledger Fabric x86 64 v1.1.0. As state database, instances of Hyperledger
Fabric CouchDB image version x86 64 v0.4.6 were used.
As Bcar registration system was created based on Hyperledger Composer tools, version 0.19.0 was
used to compile the smart contracts and communicate with the Hyperledger Fabric network setup. In
order to measure system’s performance, Hyperledger Caliper 1 software was used. Given Hyperledger
Caliper is still in development phase, a version based on commit c37860b042 2 was adapted for the Bcar
registration system to be tested.
Hyperledger Caliper is a blockchain benchmark tool developed within the Hyperledger projects.
Caliper allows to measure the performance of multiple blockchain implementations, one of them is Hy-
perledger Fabric, given a set of use cases. This tool can produce reports containing various performance
indicators, such as transactions per second,transaction latency and resource utilization.
1 Hyperledger Caliper - https://www.hyperledger.org/projects/caliper
2 Hyperledger Caliper Repository - https://github.com/hyperledger/caliper/tree/c37860b042497c24733946f01ca24d8819fe1c3f
65
Figure 6.1: Component diagram for the Hyperledger Fabric Infrastructure setup for evaluation.
Considering Hyperledger Fabric nodes setup, we configured the system with a total of 9 containers
with a total of 2 Hyperledger Fabric peers. The system was configured using solo consensus mecha-
nism, thus a single orderer container was setup for the experiments. Each Hyperledger peer was tied
to a different organization, so 2 organizations where configured in total, requiring a certified authority
running on a separate container for each organization. As stated, a CouchDB3 instance was setup in a
separate container for each Fabric peer.
An overview of the Hyperledger Fabric Infrastructure setup is presented in Figure 6.1. Organization’s
peers used in the experimental setup were configured as endorsement peers. Both peers are able to
execute, verify and sign issued transactions, thus an additional container (Chaincode Peer) is used to ex-
ecute the transaction’s required chaincode. The use of an additional container ensures process isolation
from endorsement peer process. Considering endorsement policy configuration, the Hyperledger Fabric
infrastructure was setup to ensure a single transaction signature for a endorsement peer is enough for
the ordering service to accept the operation.
6.2 Methodology
In order to evaluate the performance of the Bcar registration system, we performed a set of tests varying
blockchain’s block size and maximum time for block creation. A set of functions were selected to sample
the system’s overall performance, based on the principal transaction flows described in Chapter 4. Thus,
we evaluated the performance of Create Vehicle, Change Vehicle State, Change Ownership, Issue
3 CouchDB - http://couchdb.apache.org
66
Seizure and Register as Guarantee functions.
Each function was tested three times with a varying number of fixed throughput issued by the testing
software, for each block size configuration. Firstly, a set of 100 vehicles were created and a set of 100
transactions where issued against the BCar registration system with a fixed send rate of 50 Transactions
Per Second (TPS). Then, a set of 200 vehicles were created and a set of 200 transactions where issued
with a fixed send rate of 100 Transactions Per Second (TPS). Finally, a set of 400 vehicles were created
and 400 transactions where issued with a fixed send rate of 200 Transactions Per Second (TPS) against
the Bcar registration system. As each set of transactions was sent, the time taken for the system to fulfill
the requests was measured, then the throughput was calculated dividing the number of transactions
successfully executed by the time taken to execute such transactions.
As each component of the Hyperledger Fabric system is running on a single Virtual Machine, we took
advantage of Hyperledger Caliper functionalities by tracking the RAM and CPU usage of each Docker
container. As a remark it is expected for the CPU usage percentage to surpass 100% usage as docker
statistics aggregate CPU usage as the sum of each core’s percentage of use. Thus, the 8vCPU cores
could theoretically have a statistical use of 800%.
Regarding block size and maximum time for block formation, three experiments were conducted.
Each function’s throughput and latency information was measured against a block size of 1MB, with
250ms timeout configuration. Then the block size and timeout was doubled to 2MB block size with
500ms timeout. Finally the BCar system was tested considering a 4MB block size and a 1 second
timeout.
6.3 Evaluation
Considering the five functions selected to evaluate the system we averaged the throughput of each
function given a certain block size, based on the information of Table 6.1. Thus, we can conclude on
average a block size of 2 MB or a block size of 4 MB can achieve higher throughput that a 1 MB block
size. As we analyzed on Chapter 2, a higher block size is expected to provide an higher throughput to a
block chain based system. On the other hand, as an higher number of transactions can be batched into
a block, an higher latency is expected. As we can see by analyzing the throughput and latency graphics
for the same function, as in Figures 6.2 and 6.3.
Regarding the various functions used to test the Bcar registration system, we can conclude that the
proposed car registration system should be configured taking into account the most frequently used
functions. The maximum throughput achieved in the tests was around 7.67 transactions per second,
1MB 2MB 4MB

Send Rate 50 TPS 100 TPS 200 TPS 50 TPS 100 TPS 200 TPS 50 TPS 100 TPS 200 TPS
Create Vehicle 5 6 timeout 6 6 5 6 6 5
Change Ownership 6 7 7 7 7 7 7 8 7
Issue Seizure 6 8 8 7 8 7 8 8 7
Register as Guarantee 6 7 6 7 8 6 7 8 6
Change State 7 7 8 6 8 8 7 8 8
Table 6.1: Throughput (Transactions Per Second (TPS)) considering the variation of block size.
67
5.8 35
Transactions per second
30
5.6
Latency (s)
25
5.4
20
5.2 15
0 1 2 4 0 1 2 4
Block Size (MB) Block Size (MB)
Figure 6.2: Throughput of Create Vehicle function Figure 6.3: Latency of Create Vehicle function
1MB 2MB 4MB

Send Rate 50 TPS 100 TPS 200 TPS 50 TPS 100 TPS 200 TPS 50 TPS 100 TPS 200 TPS
Create Vehicle 13.74 25.68 timeout 12.68 25.62 57.87 11.65 24.15 64.25
Change Ownership 12.28 21.04 40.37 11.43 21.29 42.24 10.05 19.26 47.03
Issue Seizure 12.05 11.09 19.61 11.35 19.82 36.82 9.15 18.9 42.54
Register as Guarantee 39.73 11.75 20.74 9.75 18.66 46.85 10.05 20.63 45.36
Change State 10.79 20.29 35.38 11.56 18.32 36.85 11.18 19.73 36.39
Table 6.2: Latency (seconds) considering the variation of block size
8
26
7.5
25.5
Latency (s)
7
25
6.5
24.5
6
0 1 2 4 24
0 1 2 4
Block Size (MB)
Block Size (MB)
Figure 6.4: Throughput of Change Ownership func-
tion Figure 6.5: Latency of Change Ownership function
68
Transactions per second 8 25
7.5
20
Latency (s)
7
15
6.5
6 10
0 1 2 4 0 1 2 4
Figure 6.6: Throughput of Issue Seizure function Figure 6.7: Latency of Issue Seizure function
8 30
28
7.5
Latency (s)
26
7
24
6.5
22
6 20
0 1 2 4 0 1 2 4
Figure 6.8: Throughput of Register as Guarantee Figure 6.9: Latency of Register as Guarantee func-
function tion
8 25
24
7.5
Latency (s)
23
7
22
6.5
21
6 20
0 1 2 4 0 1 2 4
Figure 6.10: Throughput of Change State function Figure 6.11: Latency of Change State function
69
when the system was configured to a block size of 4 MB and a maximum timeout of 1 second, when
issuing either a Issue Seizure or a Change State transaction. However this same transactions presented
a latency of 23.53 seconds for Issue Seizure and 22.42 seconds for Change State transaction.
As expected, lower latency transactions are related to a smaller block size, thus lower throughput.
Transactions Issue Seizure and Create Vehicle, registered the lowest latency when the system was
tested with a 1 MB block size and a maximum timeout for block creation of 250 milliseconds. Analizing
the graphics (Figures 6.2 to 6.11), it seams the best compromise to optimize both throughput perfor-
mance and lower latency is achieved using a 2 MB block size.
6.4 System bottlenecks
One might think the low throughput and high latency achieved by the Bcar registration system is due to
the test setup being based on a single VM or even due to the fact that a single orderer node is in place.
Thus, in this section we will go over the system’s resources statistics collected throughout the system’s
evaluation, in order to understand the system’s performance results.
Considering Table 6.2, we notice that across all tested block sizes, the latency suffers a major in-
crease when comparing a 100 tps send rate with the 200 TPS send rate. The overall latency is roughly
doubled when the send rate is around 200 TPS, with no major increase in throughput. Raising the thesis
that such performance is due to the single orderer setup used for the Bcar registration system tests,
we expect an overload of CPU usage or RAM consumption. However, analyzing the system statistics
for 1 MB block size during a 100 TPS send rate test, as in Table 6.3, it is clear the ordering peer (or-
derer.example.com) is not requiring above average CPU or memory usage. Furthermore, the ordering
peer presents low memory and CPU usage during the test. Regarding all components used in the test,
CouchDB instances reveal to be the most resource hungry containers.
Analyzing the component statistics for 1 MB block size during 200 TPS send rate test for Register
Guarantee function, the same pattern arises. As in Table 6.4, an higher average CPU load is registered
for the ordering peer node as well as for all components of the system. As for memory consumption,
an higher average RAM consumption is registered for every component. However, CouchDB instances
remain the system’s components requiring an higher load of resources, either considering RAM or CPU
usage levels.
Name Memory(max) Memory(avg) CPU(max) CPU(avg)

dev-peer0.org2.example.co...0.0.1 124.7MB 116.8MB 90.68% 25.30%
peer0.org2.example.com 77.5MB 65.9MB 96.47% 38.99%
orderer.example.com 23.2MB 19.1MB 22.63% 3.91%
couchdb.org2.example.com 134.4MB 124.7MB 195.93% 82.82%
ca.org1.example.com 7.2MB 7.2MB 0.00% 0.00%
Table 6.3: Register Guarantee function with 100.0 TPS send rate (1MB block size)
70
Table 6.4: Register Guarantee function with 200.0 TPS send rate (1MB block size)
Thus, considering the collected data (further statistics on Annex B), it is possible to conclude one of
the possible bottlenecks of this system is related to the state database used, in this case CouchDB. This
constrain is an identified bottlenecks of the Hyperledger Fabric infrastructure, as pointed in [31].
On the other hand, the use of Hyperledger Composer framework might have a significant impact on
Hyperledger Fabric overall performance. It is possible that the use of native Hyperledger Fabric chain-
code to develop the car registration system’s smart contracts may lead to performance improvements,
however the use of such approach could imply an higher effort to develop such complex system as a car
registration system. Considering the complexity of a car registration system, as the BCar system, it is
plausible the quantity of information stored in the blockchain and the complexity of available operations
might provide a reason for such latency and throughput results.
As stated in Section 4, some of the operations regarding access control rules and business logic rules
embedded in the smart contracts provided an high latency even when running in a development setup
through unit testing. Thus, the implementation of access control rules embedded in the smart contact, as
opposed to using solely the Hyperledger Composer’s access control mechanisms, improved the latency
of such transaction’s execution. However, it is still noticeable that the access control mechanisms used
in BCar system contribute to lower performance regarding throughput and latency.
71
72
Chapter 7
Conclusions
Through this thesis, we present a use case for blockchain technology in public registry. Furthermore,
we take an overview of various blockchain infrastructures available in attempt to understand the current
capabilities and limitations of this technology. Blockchain technology as of its decentralized nature can
provide a different approach to registry storage. As of this fact, we presented a blockchain based car
registration system taking advantage of decentralization capabilities of the technology.
On the other hand, the use of a permissioned blockchain infrastructure, as proposed, enables for
easier access to car registration data across multiple entities, maintaining strict access control. Thus,
we propose the Bcar registration system as able to be extended to a Europe wide car registration system,
enabling for easier information exchange across EU member states.
As blockchain technology provides unique characteristics, such as immutability of information, busi-

ness processes can be adapted to this new paradigm. Therefor, we presented an analysis of the current
business processes for car registration operations, followed by improvements on some of those pro-
cesses. Then, we propose a new set of business processes based on the current ones, considering a
blockchain car registration system.
Based on the described business processes and public information about the car registration systems
currently in place, we have defined a set of requirements for the blockchain based system proposed. A
data model was build considering the operations identified for a car registration system as well as the
participants of the system. The set of available operations for the Bcar registration system was then
described according to their effects on a car registry.
Considering the defined the Bcar system participants, 5 participant types where defined with different
permissions over the vehicle registration operations. A person type participant was defined as a singular
entity able to own a vehicle. A company type participant was presented as a collective of persons
participants representing a collective entity owning a vehicle. A judicial officer participant was defined as
the entity entitled to execute judicial orders in the system, as seizure orders. Then, a registry employee
participant was presented as a supervisor of the system and as able to perform all operations on the
system if required to maintain a correct vehicle registry. Finally, an external entity type was presented in
order to allow external entities, such as tax authorities to read vehicle registry information.
73
Regarding vehicle registry’s operations we presented a set of operations, such as the initial vehicle’s
registration, with few modifications when compared with a centralized system. However, we presented
two step transaction flows as Change Ownership or Create Lease transaction flow, allowing to take ad-
vantage of a blockchain based car registration system. Those operations enabled for registry employees
to lower their intervention in those transaction flow.
Finally we conducted a set of performance tests over a simple configuration of the Hyperledger
Fabric system and conducted an analysis over the data collected from those tests. As of the test results
we analyzed the throughput and latency results over a set of system’s functions varying the block size
of the system. Concluding the evaluation of the Bcar registration system we analyzed the resource
consumption of each component of the system, considering the average and maximum values registered
for RAM and CPU usage over the different tests conducted.
Analyzing the performance test results and the overall result of this work, we can conclude the lower
performance test results might have been due to the use of Hyperledger Composer framework instead
of Hyperledger Fabric’s chaincode, as discussed in Chapter 6. Considering the results it is plausible that
this system could be used as a nation wide system and better system performance might be achieved in
a production environment as in [16, 31]. However, the proposed system can deliver better latency and
throughput results, the use of the proposed system as an Europe wide car registration system is unable
to fully replace the current car registration systems.
7.1 Future Work
As the Bcar registration system was designed, it encompasses most of the operations over car registries.
However, the system focuses only on car registry data. A broader system could be built based on
the proposed Bcar system, including information regarding vehicle characteristics and legal inspection
registries. Considering such a system, blockchain technology could be used to unify the car registry
system with the vehicle registry maintained by the Department of Motor Vehicles. Furthermore the
unified system could be designed as a unique system for all European Union state members.
Regarding registry information, the proposed system is applied to car registration, nonetheless na-
tional registry entities keep track of civil registries, from commercial to criminal record. Thus, future work
can be developed to consider the implications of blockchain based registration systems as replacement
for currently centralized registries. A wide range of blockchain based information systems can be de-
veloped and implemented to various government entities, as tax authorities or the police. Furthermore,
each of those government information systems present different requirements, regarding the information
handled by such systems as well as the level of disclosure of the stored information.
Still considering Bcar registration system, a more robust testing environment, with various machines,
can provide higher accuracy of the system’s performance on a production level configuration. On the
other hand the same proposal for a blockchain based car registration system or even other govern-
ment registration systems, as mentioned earlier, could be developed as research for the impact of such
systems as premissionless blockchains.
74
Bibliography
[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. Www.Bitcoin.Org, page 9, 2008.
ISSN 09254560. doi: 10.1007/s10838-008-9062-0. URL https://bitcoin.org/bitcoin.pdf.
[2] M. Walport. Distributed ledger technology: Beyond block chain. Government Office for Science,
pages 1–88, 2015.
[3] V. Buterin. Ethereum: A Next-Generation Cryptocurrency and Decentralized Application Platform.

Bitcoin Magazine, 2014. URL https://github.com/ethereum/wiki/wiki/White-Paper.
[4] E. Buchman. Tendermint: Byzantine Fault Tolerance in the Age of Blockchains (Master’s thesis).
2016. URL http://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769.
[5] M. Vukolić. Rethinking Permissioned Blockchains. Proceedings of the ACM Workshop on

Blockchain, Cryptocurrencies and Contracts - BCC ’17, pages 3–7, 2017. doi: 10.1145/3055518.
3055526. URL http://dl.acm.org/citation.cfm?doid=3055518.3055526.
[6] X. Xu, C. Pautasso, L. Zhu, V. Gramoli, A. Ponomarev, A. B. Tran, and S. Chen. The blockchain
as a software connector. Proceedings - 2016 13th Working IEEE/IFIP Conference on Software
Architecture, WICSA 2016, pages 182–191, 2016. ISSN 9781509021314. doi: 10.1109/WICSA.
2016.21.
[7] S. King and S. Nadal. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake. Ppcoin.Org,
2012. URL http://ppcoin.org/static/ppcoin-paper.pdf.
[8] V. Buterin and V. Griffith. Casper the Friendly Finality Gadget. ArXiv e-prints, Oct. 2017.
[9] N. Szabo. The idea of smart contracts. Nick Szabo’s Papers and Concise Tutorials, 1997.
[10] M. Castro and B. Liskov. Practical Byzantine fault tolerance. In Proceedings of the 3rd USENIX
Symposium on Operating Systems Design and Implementation, pages 173–186, Feb. 1999.
[11] M. Correia, G. S. Veronese, N. F. Neves, and P. Verı́ssimo. Byzantine consensus in asynchronous

message-passing systems: a survey. International Journal of Critical Computer-Based Systems, 2
(2):141–161, 2011.
[12] G. S. Veronese, M. Correia, A. N. Bessani, L. C. Lung, and P. Verissimo. Efficient Byzantine fault
tolerance. IEEE Transactions on Computers, 62(1):16–30, 2013.
75
[13] M. Vukolić. The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication. Lecture
Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture
Notes in Bioinformatics), 9591:112–125, 2016. ISSN 16113349. doi: 10.1007/978-3-319-39028-4
9.
[14] I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin mining is vulnerable. Lecture Notes in
Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in
Bioinformatics), 8437:436–454, 2014. ISSN 16113349. doi: 10.1007/978-3-662-45472-5 28.
[15] D. A. Harding and P. Todd. Opt-in full replace-by-fee signaling, Dec 2015. URL https://github.
com/bitcoin/bips/blob/master/bip-0125.mediawiki.
[16] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris,

G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith,
A. Sorniotti, C. Stathakopoulou, M. Vukolić, S. W. Cocco, and J. Yellick. Hyperledger Fabric: A
Distributed Operating System for Permissioned Blockchains. 2018. ISBN 9781450355841. doi:
10.1145/3190508.3190538. URL http://arxiv.org/abs/1801.10228.
[17] A. Mizrahi. A blockchain-based Property Ownership Recording System. ChromaWay, 2015.
[18] S. Underwood. Blockchain beyond bitcoin. Communications of the ACM, 59(11):15–17, 2016.
ISSN 00010782. doi: 10.1145/2994581. URL http://dl.acm.org/citation.cfm?doid=3013530.
2994581.
[19] Nasdaq linq enables first-ever private securities issuance documented with blockchain technology,
Dec 2015. URL http://ir.nasdaq.com/releasedetail.cfm?ReleaseID=948326.
[20] Chain protocol whitepaper. URL https://chain.com/docs/1.1/protocol/papers/whitepaper.
[21] e-health records. URL https://e-estonia.com/solutions/healthcare/e-health-record.
[22] e-residency. URL https://e-resident.gov.ee/.
[23] Guardtime’s ksi technology stack. URL https://guardtime.com/technology.
[24] Bitcoin mining now consuming more electricity than 159 countries including ireland most countries
in africa, Nov 2017. URL https://powercompare.co.uk/bitcoin/.
[25] J. Sousa, A. Bessani, and M. Vukolić. A Byzantine Fault-Tolerant Ordering Service for the Hyper-
ledger Fabric Blockchain Platform. (Section 4), 2017. URL http://arxiv.org/abs/1709.06921.
[26] Documento Único automóvel. Oct 2005. URL http://www.irn.mj.pt/sections/irn/a_

registral/servicos-externos-docs/impressos/automovel/requerimento-de-registo/
downloadFile/file/DUA_modelo_unico.pdf?nocache=1217232046.45.
[27] Council directive 1999/37/ec of 29 april 1999 on the registration documents for vehicles. OJ, L 138:
57–65, 1999-06-01.
76
[28] UN-ECE. Consolidated resolution on the construction of vehicles (r.e.3), ece/trans/wp.29/78/rev.6,
July 2017. URL https://www.unece.org/fileadmin/DAM/trans/main/wp29/wp29resolutions/
ECE-TRANS-WP.29-78r6e.pdf.
[29] ISO 3779:2009. Road vehicles – Vehicle identification number (VIN) – Content and structure.
Standard, International Organization for Standardization, Geneva, CH, 2009.
[30] FMVSS115. Vehicle Identification Number Requirements; Technical Amendment. Standard, Na-
tional Highway Traffic Safety Administration, Washington, US, May 2005.
[31] P. Thakkar, S. Nathan, and B. Vishwanathan. Performance benchmarking and optimizing hyper-
ledger fabric blockchain platform. CoRR, abs/1805.11390, 2018. URL http://arxiv.org/abs/
1805.11390.
77
78
Appendix A
Hyperledger Composer Data Model
namespace p t . bcar
enum V e h i c l e C a t e g o r y {
o M / / C a r r y i n g passengers
o N / / C a r r y i n g goods
o L / / 2/3−wheel v e h i c l e s and q u a d r i c y c l e s
o T / / a g r i c u l t u r a l and f o r e s t r y t r a c t o r s and t h e i r t r a i l e r s
}
/ / For V e h i c l e C a t e g o r y M o r N
enum V e h i c l e C l a s s {
o LIGHT / / passenger c a r s and vans
o HEAVY / / t r u c k s , buses and coaches
}
enum V e h i c l e S t a t e {
o STOLEN
o DESTRUCTED
o INACTIVE
o SUSPENDED
o ACTIVE
}
enum LoanType{
o COLLATERAL
o MORTGAGE
}
enum S t a t e {
79
o VALID
o WAITING
o WAITINGCANCELATION
}
a s s e t V e h i c l e i d e n t i f i e d by v i n {
o S t r i n g r e g i s t r a t i o n N u m b e r / / Number p l a t e
o Ownership [ ] owners
o L e a s e I nf o l e a s e o p t i o n a l
o Loan l o a n o p t i o n a l
o Seizure seizure o p t i o n a l
o S t r i n g make
o S t r i n g v i n / / V e h i c l e I d e n t i f i c a t i o n Number
o VehicleCategory category
o V e h i c l e C l a s s vClass o p t i o n a l / / r e s t r i c t e d t o M o r N
o VehicleState state
}
/∗
∗ Concepts
∗/
concept Ownership {
−−> E n t i t y owner
−−> E n t i t y newOwner o p t i o n a l
o Double share
o State state
}
concept L e a s e In f o {
−−> E n t i t y i s s u e r
−−> E n t i t y l e s s e e
o DateTime s t a r t D a t e
o DateTime endDate
o Double t o t a l V a l u e
o State state
}
concept Loan {
−−> E n t i t y c r e d i t o r
o LoanType t y p e
o Double p e n a l t y
80
o Boolean w a i t i n g C a n c e l a t i o n o p t i o n a l
}
concept S e i z u r e {
o State status
}
/∗
∗ Participants
∗/
a b s t r a c t p a r t i c i p a n t E n t i t y i d e n t i f i e d by f n {
o S t r i n g name
o S t r i n g address
o S t r i n g f n / / f i s c a l Number
}
a b s t r a c t p a r t i c i p a n t S i n g u l a r E n t i t y extends E n t i t y {
o S t r i n g surname
o S t r i n g idNumber o p t i o n a l
}
p a r t i c i p a n t Person extends S i n g u l a r E n t i t y {
}
p a r t i c i p a n t Company extends E n t i t y {
−−> Person [ ] owners
}
p a r t i c i p a n t J u d i c i a l O f f i c e r extends S i n g u l a r E n t i t y {
o String court
}
p a r t i c i p a n t E x t e r n a l E n t i t y extends S i n g u l a r E n t i t y {
}
p a r t i c i p a n t RegistryEmployee extends S i n g u l a r E n t i t y {
o S t r i n g employeeNr
}
81
/∗
∗ Transactions
∗/
t r a n s a c t i o n CreateVehicle {
o Vehicle vehicle
}
t r a n s a c t i o n ChangeOwner {
o String vin
o String registrationNumber
o S t r i n g make
o Ownership [ ] newOwners
}
t r a n s a c t i o n ConfirmOwnership {
o String vin
o S t r i n g make
−−> E n t i t y newOwner
}
t r a n s a c t i o n CancelOwnership extends ConfirmOwnership {

}
t r a n s a c t i o n CreateLease {
o String vin
o S t r i n g make
o DateTime s t a r t D a t e
o DateTime endDate
}
t r a n s a c t i o n ConfirmLease {
o String vin
o S t r i n g make
−−> E n t i t y l e s s o r
}
82
t r a n s a c t i o n CancelLease extends ConfirmLease {
}
t r a n s a c t i o n ConfirmLeaseTermination {
o String vin
o S t r i n g make
}
t r a n s a c t i o n CancelLeaseTermination extends ConfirmLeaseTermination {

}
t r a n s a c t i o n RegisterAsGuarantee {
o LoanType t y p e
o String vin
o S t r i n g make
o Double p e n a l t y
}
t r a n s a c t i o n CancelGuarantee {
o String vin
o S t r i n g make
}
t r a n s a c t i o n ConfirmGuaranteeCancelation extends CancelGuarantee {

}
t r a n s a c t i o n R e j e c t G u a r a n t e e C a n c e l a t i o n extends CancelGuarantee {
}
t r a n s a c t i o n IssuePendingSeizure {
o String vin
o S t r i n g make
83
}
t r a n s a c t i o n I s s u e S e i z u r e extends IssuePendingSeizure {
o DateTime date
o S t r i n g orderNumber
}
t r a n s a c t i o n CancelSeizure extends IssuePendingSeizure {

}
t r a n s a c t i o n ChangeState {
o String vin
o S t r i n g make
o V e h i c l e S t a t e newState
}
84
Appendix B
System resources’ statistics
B.1 1 MB block size with 250 millisecond timeout

Table B.1: CreateVehicle function with 50.0 tps send rate

85
Table B.3: ChangeState function with 50.0 tps send rate



Table B.6: ChangeOwnership function with 50.0 tps send rate
86


node bench-client.js(avg) - - NaN% NaN%
Table B.9: IssueSeizure function with 50.0 tps send rate

87

Table B.12: RegisterGuarantee function with 50.0 tps send rate
88
B.2 2 MB block size with 500 millisecond timeout




89



90



91


92
B.3 4 MB block size with 1 second timeout

dev-peer0.org2.example.co...0.0.1 109.9MB 10 8.3MB 57.84% 18.57%



93



94



95


96

Thesis

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Thesis

Enviado por

Direitos autorais:

Formatos disponíveis

BCaR: Blockchain in Car Registration

Tiago António Baptista Cabrita Arriegas Rosado

Thesis to obtain the Master of Science Degree in

Information Systems and Computer Engineering

Supervisor(s): Prof. André Ferreira Ferrão Couto e Vasconcelos

A tecnologia blockchain permite o desenvolvimento de modelos de negócio descentralizados. No en-

Palavras-chave: blockchain, registo automóvel, sistema de informação crı́tica

Keywords: blockchain, car registration, critical data storage, distributed ledger

3 Business Processes of Car Registration 19

A Hyperledger Composer Data Model 79

B System resources’ statistics 85

2.1 Blockchain applications comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 VehicleState object possible states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1 Operation types for resource access control. . . . . . . . . . . . . . . . . . . . . . . . . . 58

B.1 CreateVehicle function with 50.0 tps send rate . . . . . . . . . . . . . . . . . . . . . . . . . 85

1.1 Context diagram for the car registration system . . . . . . . . . . . . . . . . . . . . . . . . 2

3.1 Over the counter (or front-office) operations . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Use case for a simple car sale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1 Component diagram of Hyperledger Fabric infrastructure . . . . . . . . . . . . . . . . . . 62

centralized authority to partially manage and control the system.

1.2 Thesis Outline

2.1 Current car registration system

Peercoin [7], an example on a proof-of-stake based cryptocurrency. In Peercoin, if a node receives

2.4.1 Smart contracts

2.5 BFT approach

2.5.2 Hyperledger Fabric

2.6 Permissionless versus Permissioned Blockchains

Table 2.1: Blockchain applications comparison

Throughput (transactions/second) 7 20(public)/ 366(private) around 104 around 22000

Table 2.2: Blockchain infrastructure comparison

Business Processes of Car

3.1 Current Business Processes

3.1.1 National registry office operations

• Certificate issuance - When a ownership change occurs,thus a new certificate of ownership is

• Register vehicle as guarantee for a loan

3.1.2 Online operations

• Request the registration of a new vehicle in the car registration system

• Request a cancellation for a previously issued seizure

• Request a change of ownership

• Request to register a vehicle as guarantee for a loan

• Request to remove a vehicle as guarantee for a loan

• Request the issuance of a new ownership certificate

• Request a lease related operation

• Request to register a judicial order

3.2 Business Processes on a blockchain based system

3.2.1 Register a new vehicle

3.2.2 Update vehicle’s state

3.2.3 Request a change of ownership

3.2.4 Register as guarantee

3.2.5 Remove vehicle as guarantee

3.2.6 Associate lease contract

3.2.7 Cancel lease contract

3.2.8 Lock a vehicle to a pending seizure

3.2.9 Cancel a pending seizure

3.2.10 Execute a vehicle seizure

3.2.11 Supervision and issuance of new documents

Figure 4.1: Use case for a simple car sale.

A. Main use cases:

B. Secondary use cases:

Figure 4.2: Use case for a car lease.

Car registration system

Car registration system

Manufacturer Register National Registry Employee

Car registration system