Thesis

UNIVERSITY OF PORTO • FACULTY OF ENGINEERING
Supply Chain Management with

Blockchain Technologies
Pedro Miguel Lourenço Costa
June 2018
Scientific Supervision by
Filipe Alexandre Pais de Figueiredo Correia, Assistant Professor

Department of Informatics Engineering
In partial fulfillment of requirements for the degree of

Master in Informatics and Computing Engineering
by the EUR-ACE Programme
Contact Information:
Pedro Miguel Lourenço Costa

Faculdade de Engenharia da Universidade do Porto
Departamento de Engenharia Informática
Rua Dr. Roberto Frias, s/n

4200-465 Porto
Portugal
Tel.: +351 968 203 386

Email: [email protected]
URL: https://www.linkedin.com/in/pedro-costa-3279996b
This page was intentionally left blank.
Abstract
Supply chain refers to the flow of products and associated information which are
exchanged between companies. The direction of this flow goes from supplier to
consumer, with complex exchanges and transformations happening between the origin
and delivery of a product. Thus, supply chain management (SCM) is essential in the
coordination of a supply chain.
A supply chain faces many difficulties: traceability and provenance of the products,
inventory management, quality control and schedules to follow are some. Delays are
common, affecting a company’s finances, growth and reputation. This is aggravated by
the fact that the needed information is not always accurate or available, a consequence,
in part, of the manual processes for inserting information into the companies’ systems
and of the non-existence of reliable technologies which can integrate the information
in a secure and fast manner.
One way to approach these problems of supply chains is to prioritize them and up-
date the supporting technologies. A technology that seems adequate is the blockchain
distributed architecture, which allows for the immutable and secure storage of data,
making any piece of information be accessible anytime, anywhere. As such, blockchains
might be the adequate mean to achieve traceability of a supply chain, possibly leading
the way to turning the chain fully digital and automated.
This dissertation focuses on researching the extent of the issues of supply chains,
and whether blockchain can be used to solve these issues. Therefore, the hypothesis is
that blockchain architectures can be a good fit for supply chain management.
To validate the issues of SCM and elicit requirements for a supply chain software
system, a survey was conducted. By using these requirements, it was possible to
propose and iteratively build a blockchain architectural solution, aiming to test whether
the gathered requirements are feasible to be implemented.
In the end, the solution was analyzed against the elicited requirements, in order to
verify the degree to which it was possible to implement them. From this verification, it
was possible to draw some conclusions. The fact is that the designed architecture could
ii abstract
prove to handle most of the requirements for a supply chain, but the implementation
of other requirements remains to be achieved. The expectation is that the contributions,
both of the successes and failures, might help pave the way for future work and
research in integrating blockchain architecture into SCM software systems.
Keywords: Supply Chain, Supply Chain Management, Requirements Engineering,
Blockchain, Distributed Architecture, Security, Traceability, Information Integration,
Interoperability
Resumo
Empresas de qualquer indústria trocam informação e recursos entre elas, criando um

fluxo comummente chamado de cadeia de logística. A direção deste fluxo vai do
fornecedor até ao consumidor, com trocas e transformações complexas a acontecer
desde a origem até à entrega final do produto. Assim, a gestão da cadeia de logística é
essential para coordenar esta cadeia.
A cadeia de logística enfrenta muitas dificuldades: rastreabilidade de produtos,
gestão de inventário, controlo de qualidade e de prazos são apenas algumas. Atrasos
são comuns e podem afetar as finanças, crescimentoe reputação de uma empresa. A
adicionar a estas dificuldades, muitas vezes a informação necessária a certos processos
não está disponível ou não é exata, consequencia, em parte, dos processos manuais
usados para inserir informação nos sistemas, o que é lento e pode levar a erros. Isto
poderá ser causado pela não existencia de tecnologias de confiança que possam integrar
toda a informação de forma segura e rápida.
Uma forma de abordar estes problemas da cadeia de logística é priorizá-los e
atualizar as tecnologias de suporte da cadeia de logística. Uma tecnologia que parece
adequada é a arquitetura distribuída de blockchain. Esta é uma tecnologia distribuida
que permite o armazenamento seguro e imutável de dados, levando a que a informação
esteja acessível em qualquer lugar, a qualquer hora. Assim, as blockchains podem
ser o meio mais adequado de atingir a rastreabilidadede uma cadeia de logística,
possivelmente levando a que esta se torne completamente digital.
Esta dissertação foca-se em pesquisar os problemas da gestão de cadeias de logística
e a que nível poderão ser aplicadas blockchains de forma benéfica para resolver esses
problemas. A hipótese é que as blockchain possam ser uma arquitetura adequada para
sistemas de gestão das cadeias de logística.
Para validar estes problemas e levantar requisitos para um sistema de software de
logística, foi realizado um inquérito. Usando estes requisitos, foi possível propor e
iterativamente construir uma arquitetura de blockchain, para testar se os requisitos
eram possíveis de ser implementados.
iv resumo
No final, o sistema proposto foi analisado e comparado com os requisitos, para

verificar se a implementação foi possível. Daqui foi possível tirar algumas conclusões,
nomeadamente que esta arquitetura provou conseguir cumprir a maior parte dos
requisitos, mas a implementação de outros não foi conseguida e permanece por
provar que consiga ser feita. Assim, espera-se que as contribuições do trabalho aqui
realizado possam ser uma base para trabalhos futuros de investigação em integrar
esta arquitetura com sistemas reais de gestão de cadeias de logística, nomeadamente a
partir dos requisitos implementados.
Contents
Abstract i
Resumo iii
List of Figures ix
List of Tables xi
1 Introduction 1
1.1 Supply Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 From Blockchain Technologies to Supply Chains . . . . . . . . . . . . . . 4
1.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Dissertation Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Blockchain Technologies 9
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Core Concepts and Features . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Immutability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Private, Public and Hybrid Blockchains . . . . . . . . . . . . . . . 12
2.2.4 Types of Consensus Mechanisms and Algorithms . . . . . . . . . 13
2.2.5 Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Blockchain Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Hyperledger Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.3 Hyperledger Composer . . . . . . . . . . . . . . . . . . . . . . . . 24
vi CONTENTS
2.4.4 Corda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.5 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Blockchain in the Industry 33

3.1 Advantages of Blockchain in Supply Chain . . . . . . . . . . . . . . . . . 33
3.2 Challenges of Blockchain Application to Supply Chain . . . . . . . . . . 35
3.2.1 Technical Limitations and Scalability Concerns . . . . . . . . . . 35
3.2.2 Lack of Interoperability Standards . . . . . . . . . . . . . . . . . . 36
3.3 Similar existing applications . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 CargoX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Eximchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3 OriginTrail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.4 Ambrosus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.5 IBM and Maersk’s Demo . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Designing a Blockchain-based Supply Chain . . . . . . . . . . . . . . . . 41
3.4.1 Integration Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.2 Key Implementation Components and Features . . . . . . . . . . 41
4 Problem Statement 43
4.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1 Main Points of Focus . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.2 Possible Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.3 Thesis Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Supply Chain Issues Validation And Requirements Elicitation . . 47
4.2.2 Solution Design and Implementation . . . . . . . . . . . . . . . . 48
5 Supply Chain Issues Validation and Requirements Elicitation 51

5.1 Purpose and Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.1 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.2 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.1 Question Group 1 - General Information and Participant Classifi-
cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.2 Question Group 2 - Blockchain Knowledge and Opinions . . . . 56
5.3.3 Question Group 3 - Supply Chain Points of Focus and Problems 59
CONTENTS vii
5.3.4 Question Group 4 - Supply Chain Standalone Points of Improve-

ment and Blockchain points of Applicability and Improvement
for Supply Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Comparison to the state-of-the-art projects . . . . . . . . . . . . . . . . . 74
5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6 Solution Design and Implementation 77

6.1 Framework Comparison and Choice . . . . . . . . . . . . . . . . . . . . . 77
6.1.1 Framework Requirements Elicited from the Survey . . . . . . . . 78
6.1.2 Framework Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2 Requirements Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2.1 Introduction - Project Drivers . . . . . . . . . . . . . . . . . . . . . 81
6.2.2 Functional Requirements Drivers . . . . . . . . . . . . . . . . . . . 83
6.2.3 Non-Functional Requirements Drivers . . . . . . . . . . . . . . . 88
6.3 Design and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.3.1 Composer Business Network - Model Design . . . . . . . . . . . 92
6.3.2 Composer Business Network - Identity Management and Access
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.3.3 Network Topology and Deployment . . . . . . . . . . . . . . . . . 101
6.3.4 Integrating Existing Systems and Building External Applications 102
6.4 Results and Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4.1 Requirements Validation . . . . . . . . . . . . . . . . . . . . . . . 103
6.4.2 Development Limitations . . . . . . . . . . . . . . . . . . . . . . . 106
6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7 Conclusions 109
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.3 Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Appendices 113
A Statistical Analysis Methodology 115
B Composer Model Class Diagram 117

viii CONTENTS
References 119
List of Figures
1.1 Representation of a garment supply chain and all the relationships it

involves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Representation of a blockchain’s structure . . . . . . . . . . . . . . . . . . 11

2.2 Consensus workflow in Hyperledger Fabric . . . . . . . . . . . . . . . . 24
2.3 Hyperledger Composer abstraction over Fabric . . . . . . . . . . . . . . 26
2.4 Corda’s vision on a Shared Ledger . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Comparison of average latency between Ethereum and Hyperledger,
with growing number of transactions . . . . . . . . . . . . . . . . . . . . 31
3.1 Overview of the OriginTrail network. . . . . . . . . . . . . . . . . . . . . 39
5.1 Questions about the respondent’s Role, Industry, Years of Experience

and Company Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Question about Blockchain knowledge. . . . . . . . . . . . . . . . . . . . 56
5.3 Question to rate affirmations about the use of cryptocurrencies in the
blockchain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 Questions to rank inventory management importance and relationship
between absence of information and delays. . . . . . . . . . . . . . . . . 60
5.5 Questions to rate affirmations about the effects of information gaps, the
reliability of management planning and lack of a system with good
integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6 Questions about quality assurance issues. . . . . . . . . . . . . . . . . . . 64
5.7 Question: "Rank the importance of some aspects which Supply Chains
aim to improve." . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.8 Question: "Rank the importance of some functionalities in a supply
chain based information system." . . . . . . . . . . . . . . . . . . . . . . . 68
5.9 Question about the Blockchain use cases for the supply chain. . . . . . . 71
5.10 Question about the Blockchain benefits for the supply chain. . . . . . . 71
x LIST OF FIGURES
6.1 Class Diagram for the relationships between assets and participants. . . 94
6.2 Exemplification of the non-relational model problem in the Hyperledger
Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.3 Example fabric topology for 3 organizations. . . . . . . . . . . . . . . . . 101
6.4 Architectural layer representation of Blockchain Integration with other
systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.1 Full class diagram for the designed Hyperledger Composer model . . . 118
List of Tables
2.1 Comparison between different consensus mechanisms. . . . . . . . . . . 14

2.2 Comparison between traditional PoW consensus and Hyperledger’s BFT
consensus mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 Question results metrics for the affirmations about the use of cryptocur-
rencies in the blockchain. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Question results metrics for the affirmations about the effects of informa-
tion gaps, the reliability of management planning and lack of a system
with good integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Question results metrics for the question to rank the importance of
improvement aspects of the supply chain. . . . . . . . . . . . . . . . . . . 66
5.4 Question results metrics for the question to rank the importance of
functionalities in an information system for supply chain. . . . . . . . . 69
5.5 Elicited requirements grouped by improvement area of focus. . . . . . . 76
6.1 Summary of the framework requirements for each improvement area. . 79

6.2 List of designed and implemented queries, with their parameters. . . . 96
6.3 Validation of the functional requirements, according to the possibility of
their implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.4 Validation of the non-functional or quality requirements. . . . . . . . . . 106
6.5 Validation of the survey elicited requirements. . . . . . . . . . . . . . . . 107
A.1 Data analysis metrics used in the survey results analysis . . . . . . . . . 116
xii LIST OF TABLES
Chapter 1 1
Introduction 2
Our society is turning more consumerist, with most people in developed countries 3
having high consumer power and standards of life. Consumers goods, from the essen- 4
tials up until the entertainment goods, are manufactured and ordered continuously in 5
high quantities. 6
Modern supply chains feel the pressure of this growth, leading to the demand for 7
an efficient management. Most companies are making efforts towards this end, and, 8
even though part of the answer to an efficient management lies in having efficient 9
processes, a good management is also based in using the right technologies. Thus, the 10
development of technologies that can satisfy the demands of supply chain management, 11
for any industry, is in high demand. 12
1.1 Supply Chains 13
Supply Chains can be found, in some form, in nearly every business, spanning many 14
different areas of operation. Traditionally, a supply chain encompasses all the processes 15
and activities that lead from the initial raw materials to the final finished product, 16
as well as all the functions and services within and outside a company. A supply 17
chain can also be defined as the network of entities through which material flows. 18
These entities can be identified as suppliers, carriers, manufacturing sites, distribution 19
centers, retailers, and customers [25]. Naturally, with the upstream and downstream 20
flow of these materials and resources, comes a lot of information on them and on the 21
processes, people and organizations they are associated with. Realistically, the flow is 22
not always arborescent, as there are many considerations to be taken and decisions 23
to be made. Supply chains have multiple end products with shared components, 24
2 introduction
1 facilities and capacities [13]. As a consequence, the paths taken by the resources and
2 information are not straightforward, but interlace, diverge and converge at different
3 points, go back and forth, as exemplified in Figure 1.1.
Figure 1.1: Representation of a garment supply chain and all the relationships it involves. Taken
from the International Training Centre of the International Labour Organization
briefing on global supply chains [20].
4 The activities and processes a supply chain encompasses include: sourcing raw
5 materials and parts, manufacturing and assembly, warehousing and inventory tracking,
6 order entry and order management, distribution across all channels, delivery to the
7 customer, and managing the information systems necessary to monitor all of these
8 activities. As Lummus [25] describes, these activities can be roughly mapped to the 4
9 essential processes: plan, source, make, deliver.
10 Coordinating all of these is no easy task, and so the discipline of SCM comes into
11 life. According to Ballou [3], the Council of SCM Professionals (CSCMP) defines SCM
12 as “the planning and management of all activities involved in sourcing and procurement,
13 conversion, and all Logistics Management activities. Importantly, it also includes coordination
14 and collaboration with channel partners, which can be suppliers, intermediaries, third-party
15 service providers, and customers. In essence, SCM integrates supply and demand management
16 within and across companies”.
17 From this definition follows that SCM deals a lot with both coordination and
18 collaboration between entities, and so, the management of the flow of information
19 and resources between them is very important. The objective is always, of course, to
20 minimize the total cost of these flows between and among stages [? ]. In the end, the
21 creation of value (products and services) in a supply chain stems from the relationships
challenges 3
that different entities build between themselves, and not from the work of a single 1
entity. As such, supply chains, not firms, compete and those which have the best 2
integration and management processes win. 3
And this is where SCM shines and shows just how useful it can be. Managing 4
all the processes in a supply chain, while maintaining safety, quality and keeping to 5
schedule is difficult. An event on one side of the world, large or small, be it from 6
human or natural causes, can easily disrupt the links in the supply chain. For instance, 7
it might disrupt the supply of a critical component or service. Delays are, therefore, 8
common, and the consequences of such disruptions might have a severe impact in the 9
finances, growth and reputation of the companies involved [32]. 10
SCM diminishes the impact of such disruptions, and actively works to avoid or 11
diminish them, while optimizing the way the supply chain works. This is why SCM is 12
such an important discipline, that we have to better understand and improve, with all 13
the means that we can, and this includes, of course, research into technologies like the 14
blockchain. 15
1.2 Challenges 16
Having already introduced the concepts of Supply Chain and SCM, it is now possible 17
to briefly introduce some of the problems that affect them. 18
The first, and most generalist problem of a supply chain, is the ease with which an 19
unexpected event might cause delays. These events, already mentioned in Section 1.1 20
are not always predictable and must be contained as fast as possible. One event in 21
particular which, often, causes delays are synchronization problems in the processes 22
and information systems of a company [31]. 23
Another problem is that, often, there are difficulties in sharing information between 24
companies. This is caused both by the fact that companies value their privacy and the 25
security of their information, which means they might not want to share too much 26
information, or that they might only share it through secure channels, and by the 27
lack of standards for sending information and communicating [22]. The issue with 28
non-existing standards is that companies are left to discuss what details to share or 29
not, wasting time and resources. 30
Most important of all, in the industry, the use of traditional tools and manual 31
work is still too prevalent. Emails are sent, documents are printed and mailed, instead 32
of transmitting the information in a more automatic, direct and secure way through the 33
4 introduction
1 network. This point also brings the next problem of supply chains to light: the apparent
2 lack of interoperability between certain softwares (which might be a byproduct of by
3 the lack of standards).
4 Finally, provenance and traceability of the products on a supply chain are a big
5 objective for companies. But the current technologies used in supply chain only
6 accomplish provenance and traceability in a limited scope, as the information a
7 certain entity possesses is usually also limited. And so, it is very hard for anyone to
8 have a global overview of the supply chain.
9 Though it is not proven, it is be possible that some, if not most, of these issues in
10 supply chain might be caused by the use of software architectures that do not allow for
11 full data integration. An optimal supply chain should be as efficient and effective as
12 possible, while being secure and satisfying all the traceability requirements. Perhaps,
13 it is time to try out new solutions which replace or augment the existing ones, in such
14 a way that supply chain management can better satisfy the needed requirements.
15 1.3 From Blockchain Technologies to Supply Chains

16 Blockchain technology allows for secure, public, distributed and decentralized sys-
17 tems. Though it was first proposed in its actual form by Satoshi Nakamoto [26],
18 an anonymous group which published a white paper in 2008, this was not the first
19 reference to such a technology. The first work on a cryptographically secured chain of
20 blocks was described in 1991 by Stuart Haber and W. Scott Stornetta [14], and further
21 refined in 1992 by Bayer & Haber, by incorporating Merkle trees [4]. Since then, it has
22 come a long way, sprouting multiple different uses and applications of the technology.
23 Its characteristics make the development of distributed and permanently, globally
24 available systems possible, which is a paradigm that is attracting the interest of various
25 industries.
26 One area in particular where we believe blockchain could bring about great improve-
27 ments is Supply Chain Management (SCM). SCM has seen an increase in complexity in
28 the last few decades, due to the globalization of the market, with businesses interlacing
29 in many different ways, their relations extending way beyond what they used to, as
30 found by Filiz Isik [21]. This increase in complexity is somewhat hard to manage
31 and some supply chains stretch and encompass so many businesses that, due to their
32 software not being prepared for this, the information is not always transmitted from
33 end to end, leaving holes of information in between the links that join each business,
motivation 5
thus leading to a lot of chaos and uncertainty as to the state of the key items in the 1
chain [41]. 2
This dissertation work will focus on supply chain management, and on how 3
blockchains can possibly be applied to improve this area, leading to positive impacts 4
in the logistics industry and eventually finding benefits for the consumer as well. 5
1.4 Motivation 6
As described in section 1.2, a possible cause of these problems might be the use of 7
software that can not keep up with the evolution of the requirements of modern supply 8
chains. Today’s supply chains have high standards for their requirements and even 9
when the software works just fine, maybe it is not recent enough or it was not specified 10
and built to satisfy these requirements. For instance, product falsification might be 11
a huge issue nowadays in the supply chain, but maybe it was not rated as a high 12
importance problem 15 years ago. Therefore, the software from 15 years ago complied 13
with different requirements than the ones from today and was not built to handle that 14
specific problem well. 15
Requirements evolve, and so should the technology, in order to support them. 16
There is an immediate need for solutions, which might either completely replace the 17
previous ones, or augment them. 18
One way to approach these specific problems is to research what would a modern 19
requirements specification for supply chain look like, and develop new technologies 20
that are more accurately specified for the supply problem challenges in question. 21
The characteristics of blockchain architectures seem to be a good solution for 22
many of the identified problems in supply chain to be reduced or neutralized. These 23
architectures are the perfect means to achieve traceability of a supply chain, and so, 24
they are good to achieve provenance as well. At the same time they are a secure, 25
incorruptible and immutable way to store information, with a fast synchronization 26
time, being perpetually available to anyone who has permission, anywhere within the 27
network. It would also be the way to close the analog gaps, turning the chain fully 28
digital, leading to the possibility of a global overview. 29

6 introduction
1 1.5 Objectives
2 The main objective of this dissertation is to find whether blockchain technology is a
3 good fit to solve the most common problems of supply chain management, and also
4 to find out the technological requirements of a modern supply chain. There are a
5 multitude of small tasks that blockchain could automatize in supply chain, so this
6 thesis will try to figure out which ones blockchain applies to better.
7 The primary objective of this dissertation is determining if blockchain architectures
8 can be successfully applied to supply chain management as an improvement towards
9 the technologies that are already being used. For this purpose, it is necessary to
10 conduct research on the supply chain issues and validate these, in order to propose a
11 blockchain design that can target these issues successfully.
12 1.6 Dissertation Structure

13 Besides the introduction, this dissertation has 6 more chapters, divided into 2 parts.
14 Part 1: Background and State of the Art - Provides the needed concepts to under-
15 standing the work, as well as explanations about the existing tools and projects related
16 to the blockchain and to its application to supply chain management domain. The
17 state of the art is divided into 2 chapters: 2 and 3.
18 • Chapter 2, "Blockchain Technologies", some important concepts from the

19 blockchain architecture are presented and discussed, followed by an analysis of
20 the existing blockchain networks and frameworks and their comparison.
21 • Chapter 3, "Blockchain in the Industry", the application of blockchain to supply

22 chain is discussed in more detail, including the possible advantages, challenges,
23 and following it up with an analysis of the existing blockchain applications that
24 also focus on supply chain.
25 Part 2: Problem, Research and Solution - Provides a thorough explanation of the

26 problem, objectives and the proposed methodology to approach them. Follows up with
27 a survey and requirements analysis, which serves as a base to propose a blockchain
28 solution design.
29 • Chapter 4, "Problem Statement", specifies the thesis statement and the questions
30 that need to be answered in order to reach a conclusion.
dissertation structure 7
• Chapter 5, "Supply Chain Issues Validation and Requirements Elicitation", fea- 1
tures a survey and the analysis of its results, such as to gather the requirements 2
for a supply chain system, so that a blockchain-based solution can be proposed. 3
• Chapter 6, "Solution Design and Implementation", features the choice of a 4
blockchain framework and the proposal of a solution, which consists in building 5
a proof of concept (PoC) project that implements the requirements elicited from 6
the survey. 7
Part 3: Conclusion - Gathers all the information from the results of the solution to 8
make a statement, also listing contributions, difficulties and future work. 9
• Chapter 7, "Conclusions", features an overview of the work done in the disserta- 10
tion, providing an answer to the previously defined problem, and following it up 11
with possibilities of future work in this area. 12

8 introduction
Chapter 2 1
Blockchain Technologies 2
This chapter introduces the most important concepts of blockchain which are essen- 3
tial for its applications. It interleaves the features of blockchain with its applicability to 4
supply chain, by highlighting both the disadvantages and disadvantages, of blockchain 5
in general and in particular to SCM, as well as any existing models for the integration 6
of blockchain with SCM. 7
2.1 Introduction 8
“The Byzantine Generals’ Problem” is a classical problem faced by distributed systems, 9
which, in simple terms, states that consistency in a distributed system can never be 10
fully guaranteed [23]. This is derived from a lack of general consensus as to what the 11
state of the system is at any given time. 12
Nakamoto’s implementation of a blockchain seems to be, at present, the most 13
practical way to approach this problem (though with its limitations), even earning 14
the term "Practical Byzantine Fault Tolerance (PBFT) Algorithm", because of how 15
it handles the consensus issue. The fact that many kinds of applications rely on 16
distributed architectures, which might face these problems, turns blockchain all the 17
more appealing. 18
Some improvements have been built upon the traditional blockchain, such as smart 19
contracts, which further enhance its use and allow for a wider variety of applications. 20
Some areas where blockchain is starting to see some use include insurance, finance, 21
Internet-of-Things, health care, identity management, to name a few. 22
In each of these areas, there are many ways in which blockchain can be used, be it 23
to store information, process information, process payments or provide services. The 24

10 blockchain technologies
1 versatility is what makes it so popular and what allows for the possibility of many
2 other applications to be proposed.
3 2.2 Core Concepts and Features

4 The original blockchain, Bitcoin, was developed with the purpose of creating a dis-
5 tributed online payment system without the need for a financial institution or any
6 other centralized trusted third party to verify the transactions. It even has its own
7 currency, made up from digital tokens that represent real money, a concept which is
8 now commonly known as a cryptocurrency.
9 Eventually, this concept evolved into something more, and new uses, other than
10 online transactions, emerged from the blockchain technology. As described by Marc
11 Pilkington [28], "the essence of the blockchain is informational before being economic or
12 monetary, conducive to many emerging and increasingly popular token-free blockchains".
13 Therefore, the algorithms used by Bitcoin are not a defining feature of the blockchain
14 technology, but merely one of the many possible applications.
15 The blockchain itself consists of a peer-to-peer network which continually stores and
16 updates a chronological chain of blocks, where each block stores whatever information
17 is relevant to the system in question, as well as the hash of the previous block. In the
18 original blockchain, each block stored information about transactions between people,
19 where there was a set of rules to check whether the transactions were valid or not. We
20 will get to how a blockchain can be built in a moment.
21 One important and defining property of the blockchain is that the hash of the
22 previous block also serves as an address. Therefore, each block has a pointer to the
23 previous block, which is known as an hash pointer. This concept is illustrated in
24 Figure 2.1.
25 2.2.1 Immutability
26 This hash thus guarantees that the blocks are linked to each other, but it also guarantees
27 the integrity of the block chain. If one block is altered, the hash on the block that
28 follows it stops matching the block’s. If we really wanted to change something on this
29 first block, we would have to alter the hash on the following block to match. But then,
30 that second block would also have been altered, and we would have to change the hash
31 on the third block to match, and so on. This means that the blockchain is immutable,
32 as it is not possible to alter a single block without manually altering all the others.
core concepts and features 11
Figure 2.1: Representation of a blockchain’s structure
2.2.2 Consensus 1
The blockchain and its data exists only in a peer-to-peer network, and as such, it is 2
stored and extended by the nodes of the network, which form a topology between 3
them. The nodes are machines that have the core code of the blockchain system and 4
which receive and share among themselves the incoming information, in the form of 5
blocks, validating it according to the established rule set. All the nodes, if they are 6
not malicious and actively attempting to change the contents of the chain, contain the 7
same blockchain structure and information, as they all agree on its contents through a 8
consensus algorithm. 9
Some nodes are open to the internet and the world, thus receiving information 10
from outside the peer-to-peer network and disseminating it to the rest of the network’s 11
nodes. A subset of the nodes, called miners, will then gather the circulating information 12
from the peer-to-peer network (by receiving transactions from the nodes they are 13
connected to), and form blocks of information, which they try adding to the blockchain. 14
Obviously, it is impossible for all the nodes to add their blocks at the same time, as 15
each of them would then have a different version of the blockchain and they would 16
get desynchronized. And so, the nodes must reach a consensus as to which block gets 17
added next to the blockchain. For this very reason, the code of the blockchain must 18
have both a consensus algorithm and also a block validation algorithm. 19
In public blockchains, the mining nodes do all the hard work, and they usually 20
1 need some incentive to do so. Cryptocurrencies are virtual currencies that only exist
2 on the blockchain they belong to, and they allow for a new monetary system to come
3 into life. These currencies play an important role in blockchain, since they allow for
4 miners to be rewarded. Without them, public blockchains would probably not work
5 as well, which is why there are so many alternative currencies popping up, with the
6 advent of this technology.
7 Of course, this is just one of many ways to make a blockchain move forward
8 successfully, and other types of consensus algorithms have been idealized, though
9 most of the consensus algorithms in public blockchains will use cryptocurrencies as
10 the prime incentive.
11 2.2.3 Private, Public and Hybrid Blockchains

12 Blockchain, traditionally, is of public nature. But, as many institutions grew aware of
13 the possible benefits of this technology, they started investing in it, and so appeared
14 the private blockchains and the semi-private or consortium blockchains.
15 Public Blockchains When a blockchain is public, it is accessible to any user. Anyone

16 is able to both read and validate information from it, as well as contribute to its
17 extension by participating in the consensus process. They are secured by the economic
18 incentives that are given to the miners, in the form of cryptocurrency tokens. These
19 blockchains can be considered fully decentralized and have no access control. Every
20 user is at the same level.
21 Private Blockchains These are usually owned by some organization and have access
22 control, restricting write access to certain peers inside the organization. Read access
23 might be restricted or not, according to the organization’s goals. These blockchains,
24 unlike public ones, might not require cryptocurrency or incentives, as the maintenance
25 of the blockchain is done by the organization who owns it, and so they have all the
26 interest in having nodes that can run the consensus process. In the end, this is a
27 more centralized version of the blockchain, as the nodes are concentrated under the
28 ownership of the organization. This also gives the advantage that alterations to the
29 blockchain are easier to achieve, if so is desired (though it subtracts from the actual
30 meaning and concept of an immutable blockchain). It is usually more efficient than
31 public blockchains, being able of achieving a higher number of transactions processed
32 per second.
core concepts and features 13
Consortium blockchains They are a kind of hybrid blockchain, though closer to 1
a private blockchain. They are controlled by many different organizations, and the 2
consensus process is handled by pre-selected nodes from the organizations. This 3
consensus might involve, for example, at least a certain percentage of the nodes 4
agreeing on something (e.g.: if there are 15 fixed nodes, require at least 10 to sign the 5
block). The permissions to read might be public or otherwise permissioned, and as 6
such, this can also be considered a partially decentralized blockchain. 7
Consortium and private blockchains are not that different. According to Vitalik 8
Buterin, [9], "so far there has been little emphasis on the distinction between consortium 9
blockchains and fully private blockchains, although it is important: the former provides a hybrid 10
between the ‘low-trust’ provided by public blockchains and the ‘single highly-trusted entity’ 11
model of private blockchains, whereas the latter can be more accurately described as a traditional 12
centralized system with a degree of cryptographic auditability attached". 13
2.2.4 Types of Consensus Mechanisms and Algorithms 14
The most commonly used consensus algorithm is Proof of Work (PoW), though there 15
are others, like the most used alternatives, Proof of Stake (PoS), and Proof of Activity 16
(PoA). We showcase some of the algorithms in Table 2.2. 17
2.2.5 Transparency 18
The blockchain is not only available to the mining nodes in the network. Though they 19
are the ones who actively interact with the chain in order to make it grow, if the chain 20
is public, anyone can view the records and verify the authenticity of the data. This is 21
the property of transparency. In private or permissioned blockchains, it might happen 22
that only certain actors have access to certain records, according to the access control 23
rules set by the organization or set of organizations that manage it. This is done with 24
the help of sets of asymmetric key pairs and a public key infrastructure. 25
Table 2.1: Comparison between different consensus mechanisms.
Type Overview Better Used In

In short, PoW works by making the nodes spend
computational power until they can find out a hash
that satisfies a certain rule, for a certain block. When
a node finds this hash, it is allowed to extend the
blockchain with that block. The node transmits the Public Blockchains
Proof of Work (PoW)
new blockchain to all the other nodes. It is assumed (Bitcoin, alt coins)
that the longed valid chain (where all blocks have
valid mining hashes and valid contents) held by any
block is the correct one. Additionally, the creator of
a block includes a reward for themselves in the block.
In PoS, the "miners" stake their cryptocurrency
tokens as a bet, on which block they want to
include in the blockchain. By doing so, they
actively have a chance to mint that block
proportional to the number of tokens they Public Blockchains,
Proof of Stake (PoS) stake. This makes it so that any participant of the Consortium
network has in its best interest to be honest. The Blockchains
higher their stake, the more invested in the
network they are. PoS is less wasteful than PoW,
which consumes a lot of energy in computational
power.
The transactions are validated, aggregated into blocks
and put into the blockchain by approved known nodes,
Proof of Authority
which act like "admins" and are the source of truth Private Blockchains
(PoA)
for the system. This is a more centralized kind of
consensus.
Every participant in the network is assigned a random Private Blockchains,
Proof of Elapsed
amount of time to wait, and the first participant to Consortium
Time (PoET)
finish waiting gets to commit the next block. Blockchains
There are many algorithms for this kind of consensus. Private Blockchains,
Byzantine Fault
One is Practical BFT (PBFT), with pre-selected nodes Consortium
Tolerance (BFT)
selecting and ordering the transactions. Blockchains
applications 15
2.3 Applications 1
In general, blockchains are applied in different ways, from public ledgers to private, in 2
a continuum, according to the specific needs. Many of them even apply the concept 3
of smart contracts. Vitalik himself suggested some possible applications of Ethereum, 4
and many more have been idealized, with some even being successfully applied. Here 5
are some examples of areas where the benefits of introducing blockchain have been 6
studied. 7
• Identity/Record Management - like in a notary, documents are validated and 8
recorded. 9
• Insurance - Smart contracts, having to abide to certain rule with certainty, make 10
for a perfect system for risk-management. Given that certain conditions are 11
met, the insurance could be claimed, giving way to faster and less error-prone 12
insurance processing. 13
• Health care - Health records easily accessible anywhere. This could be coupled 14
with other applications, like using sensors and smart contracts to automatically 15
monitor patient status. 16
• Distributed Cloud Storage - Instead of the traditional centralized cloud, dis- 17
tributed clouds could become a reality. 18
• Voting - Using blockchain, digital voting could become feasible. The greatest 19
barrier to e-voting have been the concerns with security, and blockchain provides 20
an anonymous and secure way to do it. 21
• Internet-of-Things (IoT) - Any object connected to the Internet can upload infor- 22
mation, which can either be stored or processed on the blockchain. Devices with 23
sensors, for instance, can be programmed to send their values to the blockchain, 24
which can then be queried by others to check these values. There can even be 25
pre-programmed smart contracts that have events based on what is happening 26
and the information that is being sent by the devices. 27

1 2.4 Blockchain Frameworks
2 There are several frameworks to build blockchains, as well as platforms to partici-

3 pate in already existing ones. A blockchain does not have to be built from scratch, as
4 there is already a lot of work done in this area. This chapter goes into detail, explaining
5 some of the most important frameworks, and their applicability to certain cases.
6 2.4.1 Ethereum
7 With the purpose of building a blockchain that does more than just provide a currency
8 system, the Ethereum project was developed and launched in 2014. A white paper,
9 written by Vitalik Buterin was released explaining the concepts and inner-workings
10 of this platform, and its popularity has been growing ever since. Citing Buterin’s
11 paper, Ethereum has the intent to "allow developers to create arbitrary consensus-based
12 applications that have the scalability, standardization, feature-completeness, ease of development
13 and interoperability" [8].
14 Smart Contracts
15 In short, Ethereum is a blockchain platform that implements a Turing-complete pro-

16 gramming language, allowing for the existence of code stored in the form of "contracts".
17 This allows for the practical existence of Smart Contracts, a concept first proposed by
18 Nick Szabo in 1996 [37]. According to Szabo, "a smart contract is a set of promises, specified
19 in digital form, including protocols within which the parties perform on these promises".
20 So, at a more superficial level, a smart contract is just source code, a structure that
21 follows pre-specified rules, in order to move around assets and their ownership, such as
22 cryptocurrency tokens. A smart contract reacts according to the interactions it has with
23 the other elements of the blockchain, which, in a crude manner, can be either people
24 or other contracts. In other words, Ethereum moves beyond the realm of currency
25 and opens up the possibility for decentralized applications to be ran directly on the
26 blockchain. Smart contracts are written in different kinds of custom languages, like
27 Solidity, which are then compiled to byte code, deployed to the chain and interpreted
28 by the Ethereum Virtual Machine (EVM).
29 Unlike with Bitcoin, Ethereum’s blockchain saves, not only the transactions, but also
30 the state of its smart contracts. The smart contract code is also subject to the consensus
31 mechanism, as it is being run on the same nodes that validate the transactions.
blockchain frameworks 17
Currency 1
The interesting aspect of Ethereum, however, is that the code from these applications or 2
contracts is executed by the peer-to-peer network nodes, making Ethereum a globally 3
available computer. Of course, with computational power comes a price. Each time a 4
function from a contract is called, someone’s computer, a mining node, is doing all 5
the computations, and for each line of code, an agreed fee must be paid. As such, 6
Ethereum has its own cryptocurrency, by the name of Ether, and which is essential to 7
fuel the network. 8
Consensus 9
At the moment, Ethereum is still using PoW as the consensus protocol, in a similar 10
fashion to Bitcoin. There are projects currently trying to move Ethereum to PoS, such 11
as Casper [10]. PoS is a consensus protocol with a different paradigm, in which the 12
block mining process is roughly based on trust, on the fact that the miner has a certain 13
stake or investment (like cryptocurrency) in the network, and so it is in their best 14
benefit to be an honest node. 15
The benefit of PoS over PoW is that there is not as much "waste" of computational 16
power as in PoW. In PoW, miners have to intensively search for a target number, 17
which allows them to claim the block as their own. This serves no other scientific or 18
practical purpose other than making the mining process hard, and, as soon as a node 19
successfully mines a block, all the energy used by all the other mining nodes that were 20
in this process basically goes to waste [7]. There are other concerns that make a PoS 21
system like Casper a better option as well, such as performance concerns. 22
Performance and Scalability Issues 23
Ever since its conception, there has been concern as to whether Ethereum’s throughput 24
and latency are enough to handle a large amount of applications running at once, and 25
if it will be scalable in the future. The recent launch of an application by the name of 26
1
CryptoKitties disrupted Ethereum, congesting the main network and slowing down 27
the speed of transactions, again raising concern over Ethereum’s performance. 28
These concerns are also very much valid for the case of supply chains. If Ethereum 29
were to be integrated with a supply chain, by using smart contracts, one of the most 30
important factors to take into account would be exactly the performance and scalability 31
1 https://www.cryptokitties.co/
1 of the system. It is important to note, though, that private and public blockchains
2 have different performances as well as different scalability concerns. Furthermore,
3 certain values that affect the performance (such as the block time) also have an affect
4 on the scalability, and consequently, on the security (a blockchain with a lot of nodes
5 is more secure than one with fewer, for instance). This means that these attributes
6 are interdependent and require a fine balance. It is important to mention that it is
7 possible to deploy a network for Ethereum separate from the main network, so that it
8 runs on a separate number of nodes and so that the network could have some of its
9 values customized. However, such a network will still be public, like the main network
10 already is, suffering from most of the same issues.
11 In a public chain, security is a much bigger concern, as there are many different
12 kinds of attacks, and the blockchain’s values, such as the block size, are balanced in a
13 way that tries to prevent these. Such values can easily be adjusted in a private chain,
14 in ways they can not in a public chain, where they would cause forks, clog the chain or
15 raise security issues. In addition, private blockchain deployments are usually more
16 centralized, concentrating their power in fewer nodes, as there is an inherent sense of
17 trust from within the network. For this very reason, this type of blockchain is more
18 easily scalable as well.
19 The performance of blockchains such as Ethereum is usually measured by the
20 average throughput, which is the number of processed transactions per second (TPS).
21 This depends a lot on two main factors:
22 • The block size - in Ethereum, the block size is not a fixed value; rather, it has
23 a "gas" limit; each transaction put into the block spends some gas, and when
24 the gas reaches the limit for that block, the block is full; here, "gas" is a unit
25 that refers to the computational steps taken to process a certain transaction or
26 contract; the more complex the transaction, the more "gas" it spends;
27 • The average time to publish a block - block interval; in Bitcoin, this was a fixed
28 10 minute time, but in Ethereum, this time can be as low as 15 seconds [35]; this
29 is directly related to the latency, the time a transaction takes to be integrated into
30 the blockchain;
31 The fact that both transactions and block can vary in their size makes it hard to
32 theoretically pinpoint what the performance of an Ethereum network is. In practice,
33 though, and according to recent studies and statistics gathered, the throughput of the
34 main Ethereum network is around 15 TPS.
Besides latency and throughput, most blockchains are facing the problem that the 1
blockchain size, the required to store the blockchain itself is becoming increasingly 2
large, and is constantly growing. With this kind of pace, not every node will be able to 3
store the chain in order to validate it. 4
This easily becomes a security problem for public blockchains, as the power will be 5
concentrated among the few nodes who can store the blockchain. In Ethereum, every 6
node has to store and process all transactions as well as store the entire state of the 7
blockchain [35], hence, this is an important issue to address. 8
Proposed Solutions 9
Solutions to the above mentioned issues of the above mentioned issues have already 10
been proposed and are being tested. Some of these are Raiden, Casper, Sharding and 11
Plasma. 12
Casper - PoS-based efficiency and security scalability To put it simply, Casper is a 13
partial consensus mechanism that aims to implement PoS as the consensus algorithm 14
in Ethereum. It works by allowing anyone who holds anything of value in the system, 15
in this case, the Ethereum currency, Ethers, to participate in choosing the next block. 16
Casper has the important characteristic of accountability. The validator nodes 17
deposit some of their currency to have a stake on the mining process of a block, so 18
they have their own deposits at stake. Therefore, they are encouraged to be honest, 19
because any violation of the rules or attempts of attack puts them at risk of losing this 20
deposit. The higher the stake, the higher the power: with a high stake, it might be 21
easier to perform an attack, but as it is also a lot riskier, so attacks are discouraged. 22
Another important aspect of Casper is that, as a PoS based mechanism, it allows for 23
a more efficient Blockchain as it enables miners to work without high end hardware 24
and high electricity costs, while also potentially allowing for lower block times. 25
Sharding - Transaction throughput scalability Sharding is a solution that aims to 26
increase the throughput of Ethereum. It acts upon the problem that every node 27
must validate every transaction, by dividing nodes and transactions into subsets and 28
assigning them such that a subset of the nodes will verify a subset of transactions [6]. 29
This allows for transactions to be processed in parallel, and, as long as there are 30
enough nodes validating a transaction, security is maintained, and more transactions 31
per second are able to be processed, therefore increasing throughput in a scalable way. 32
1 Raiden - Token transfer throughput scalability Raiden is a solution that allows for
2 off-chain transfers of tokens to happen outside the blockchain, on a side-channel, in
3 a secure way, using cryptography to build balance proofs [15]. This way, for a certain
4 number of transactions, a side channel can be opened, the transactions are performed,
5 and, at the end, the channel is closed and the transactions are submitted onto the chain.
6 Raiden implements the protocol that provides the routing between the nodes and all
7 other functionalities that make this possible.
8 Plasma - Throughput scalability Plasma uses smart contracts to build hierarchical

9 side chains, that can be thought of as children of the main blockchain. These chains
10 process information as a normal chain would, being governed by their own rules and
11 constraints, and it is even possible to revert transactions within them, as they have a
12 smaller scope and are built apart from the main chain. These child chains can then
13 relay information back to the main blockchain. Theoretically, there is no limit to the
14 number of chains, allowing for great scalability [30].
2.4.2 Hyperledger Fabric 1
Hyperledger is an open-source effort hosted by The Linux Foundation, which aims to 2
further improve the concept of blockchain to be used in many different contexts. 3
More specifically, one of the Hyperledger projects, Hyperledger Fabric, initially 4
contributed by IBM, tries to address some of the open issues of the existing frameworks, 5
like Ethereum. Hyperledger Fabric is an open source framework to build permissioned 6
(private or consortium) blockchains usable in industry, and, while it shares some 7
similarities with Ethereum, it also has many differences. 8
Chaincode 9
Hyperledger possesses a form of smart contracts, which it names chaincode. Similarly 10
to Ethereum, the chaincode programs are event driven programs which run on the 11
ledger, changing the ledger’s state when executed, thus being able to move assets 12
around. It can be said that this works much like a state machine. 13
A big difference to Ethereum, though, is the language used in the chaincode. Pro- 14
grams are written in Go, with support for other languages like Java to be implemented. 15
The code is deployed using an isolated VM, through a Docker container. 16
Being able to use general-purpose languages to code smart contracts is an advantage 17
and lowers the barrier of entry to use this framework as a blockchain. But it also 18
raises the issue that the code might be non-deterministic, leading to forks, which is the 19
specific reason why Ethereum uses a language that it compiles and runs on EVM. 20
Architectural Revision 21
The latest version of Fabric, v1.1, has a totally revised architecture from some of the 22
previous versions, like v0.6. These changes in architecture originated from changes 23
in the requirements, as well as to better address some other underlying issues of the 24
technology. 25
The previous version (v0.6) shared similarities with other blockchain systems, in 26
that it had an order-execute architecture, which combines consensus and execution of 27
transactions, in this order. In the order-execute architecture, after a block is assembled 28
and mined (agreed upon), all other nodes will execute its transactions sequentially. 29
This was a simple architecture, but it has several liabilities when used in a permissioned 30
blockchain like Hyperledger. Some of the most notable issues are: 31

1 • Non-deterministic code: In this architecture, any non-deterministic code might

2 cause forks, because the code might change the state in different ways for different
3 nodes;
4 • Sequential execution of smart-contracts: one slow contract could cause a delay

5 for the others;
6 • Hard-coded consensus: there is no "one-size-fits-all" solution, protocols vary im-

7 mensely in performance and functionality, and having alternatives and adaptation
8 to specific use cases is essential;
9 • Confidentiality of execution: sometimes, smart contract logic is intended to be

10 restricted, only to be run by some nodes, though the state should be propagated
11 to all nodes in the end; this architecture does not allow for such a restriction
12 A detailed architectural specification of Fabric’s revised version 1.1 can be found

13 in the documentation section of Fabric’s website [17] [19]. Other articles have been
14 produced by IBM researchers [11] [40], as well as numerous presentations, detailing
15 the general architectural problems and solutions of this technology.
16 This revised version follows instead an "Execute-Order-Validate" implementation,
17 which tackles the above mentioned issues, and, according to Fabric’s documenta-
18 tion, the advantages this reviewed architecture brings are scalability, confidentiality,
19 consensus modularity and chaincode trust flexibility.
20 System Architecture and Consensus
21 In Fabric, transactions are of two types: either deployment transactions, which create
22 new chaincode, or invoke transactions, which perform operations on the deployed
23 chaincode.
24 Being a permissioned blockchain, any node which wants to interact with trans-
25 actions is required to authenticate itself and have an identity. Transactions and data
26 are therefore restricted to certain participants of the network. The data partitioning
27 mechanism used to control this is called a channel. Users can belong to a channel,
28 having visibility of these transactions, and the consensus will happen only within the
29 channel and its members. This also means that there is one ledger (set of transactions
30 plus the state) per channel. The channels themselves have defined sets of rules for
31 what actions each participant can execute.
Besides the existence of permissioned channels, the other main difference in this 1
revised architecture is the way in which consensus works. The following definitions cor- 2
respond to steps in the consensus mechanism, which are needed to better understand 3
this consensus mechanic. 4
Endorsement Some endorser stakeholder first verifies the transaction and then de- 5
cides whether to accept it or reject it. The endorsement is simply a signature of the 6
transaction, which confirms the decision of the endorser. Endorsement policies might 7
require transactions to have a certain minimum number of endorsers to be accepted. 8
Ordering All the transactions gathered within a certain period are grouped into a 9
block, sorted and committed in that order. 10
Validation Check if the endorsement policy of a transaction is satisfied and then 11
checking if the transaction transformation is valid. 12
The consensus process is held by three different types of nodes: 13
Types of nodes: 14
• Client - submits a transaction to the endorser nodes 15
• Peer Node - peers form a peer-to-peer gossip network, maintain the state of the 16
ledger and manage the chaincode; they can be 17
– Endorser - simulates transaction execution and decides whether to endorse 18
or not. Endorsers are always also committers. 19
– Committer - verifies the endorsements and validates the transaction results 20
• Orderer Node - the orderer nodes together form a ordering service; this service 21
uses a certain pluggable (changeable) protocol to order the transactions received 22
from the peers, create a block with them and then broadcast this block to the 23
committers; 24
In a simplified way, the workflow of the consensus, as shown in Figure 2.2, is as 25
follows: 26
1. The client transmits the transaction to the endorser nodes. 27
2. The endorser nodes simulate the transaction and choose whether they endorse it 28
or not. If they do, they sign the transaction and send the endorsement back to 29
the client. 30
1 3. The client broadcasts the endorsement to the ordering service.
2 4. The ordering service gathers incoming transactions, sorts them into blocks and
3 then broadcasts the transactions by order to all the peers (orderers and com-
4 mitters); the peers then validate the transactions and verify their endorsements,
5 applying only the transactions which fulfill the endorsement policy.
Figure 2.2: Consensus workflow in Hyperledger Fabric. Available in [19].
6 Compared to other blockchains, this consensus mechanism has some advantages,

7 though its application is somewhat limited to some use cases. Table 2.2 summarizes
8 some points of difference between a blockchain using Proof of work and one, like
9 Hyperledger, using a BFT state machine consensus.
10 In brief conclusion, Hyperledger allows for a permissioned blockchain which
11 sacrifices some decentralization for scalability and performance. By using a different
12 consensus mechanism, most of the issues of public blockchains vanish. Furthermore,
13 data access must be authorized, such that sensitive data in a channel is protected, one
14 of the requirements for data in supply chains. Thus, Hyperledger Fabric’s features
15 are adequate for SCM’s requirements in a way that is difficult to achieve in public
16 blockchains.
17 2.4.3 Hyperledger Composer

18 Hyperledger Composer is another tool which works together with Fabric to allow for
19 an easier approach to modeling a blockchain network. It is actually a higher level
Table 2.2: Comparison between traditional PoW consensus and Hyperledger’s BFT consensus
mechanism
Proof of Work BFT state machine replication

(Bitcoin, Ethereum, ...) (Hyperledger, Ripple, ...)
Membership
Permissionless Permissioned
type
Decentralized, Anonymous Centralized, all Nodes know all other
User IDs
(Decentralized protection by Nodes (identity management protects
(Sybil attack)
PoW compute/hash power) against Sybil attacks)
Scalability Can scale to 100 nodes, with certain
Excellent, >100k nodes
(no. of nodes) performance degradation
>10k tx/sec with existing
Peak from 7tx/sec (Bitcoin) and
implementation in software
Throughput 15tx/sec (Public Ethereum)
[>10 nodes]
Power
>1 GW (Bitcoin) Good (commodity hardware)
efficiency
Temporary
Possible (leads to double-spending
forks in Not possible
attacks)
blockchain
Consensus
No Yes
Finality
abstraction of Fabric, which allows for a big reduction in the lines of code written and 1
simplifies the whole process of building a business network and deploying it, as well 2
as the process of managing the identities of the network’s participants. The whole 3
documentation for the project is continuously being updated at their website [24]. 4
It features a nice and intuitive graphical user interface to manage all of its com- 5
ponents, and it also features a REST server to expose the blockchain to outside 6
applications. 7
Business Network 8
A business network is a model of all the data in the blockchain, which includes all the 9
objects, functions, transactions and identities that will connect to each other and be 10
saved on the ledger. It is basically an abstraction of the chaincode that will be installed 11
onto Fabric. A business network, being a network model, can be deployed into an 12
instance that runs on a certain number of nodes. 13
Composer features a custom modeling language which makes it easier to define a 14
business network. It is divided into 4 main components, as can be seen in Figure 2.3. 15
If a business network model is deployed multiple times with a different sets of 16
nodes each time, it will simply constitute different instances of a network model. 17
Each instance will constitute a separate network with a separate ledger, independent 18
Figure 2.3: Hyperledger Composer abstraction over Fabric. Available in Composer’s docu-
ments [38].
1 from the other networks. This is analog to modelling a class in a object oriented
2 programming and then instancing it multiple times. Each instance is separate from the
3 others, even though it is based on the same model. Therefore, a good model design
4 can be used by several businesses separately, and each can configure the model to
5 represent the topology they are looking for.
6 The 4 main components:
7 Model File This is where all the main data components are defined. Assets are
8 the main "objects" that are handled in transactions, and they can represent a variety
9 of things. One example can be a "car". Participants are the types of people that
10 will be participating in the network. One example participant can be "Customer",
11 which will have fields like "Balance" and "Name". An instance of a participant can be
12 linked to a real identity of a person using the blockchain. Transactions are the most
13 important data object. They model what actions can be taken, and they usually have
14 some data fields associated, which act as the input of the transaction. An example
15 of a transaction can be "BuyCar", which could have as parameters the car ID, and a
16 participant could then call this transaction, if they had the permission to do so. All
17 these 3 components, Assets, Participants and Transactions have their own registry.
18 While the Assets and Participants registries are mutable, the Transactions registry is
19 not. Additionally, another type of object can be defined in this file, Events, which can
be emitted by transactions and subscribed by applications which can handle them, for 1
instance, to generate notifications. 2
Script File This file contains all the functions that define how a transaction behaves 3
and what kind of data it processes and outputs. It can also have additional auxiliary 4
functions. 5
Access Control This is where the access rules are defined. These rules include 6
restrictions on who can invoke which transactions, who can read the data, and many 7
other permissions. 8
Query File This file includes some queries that can retrieve information from the 9
blockchain. This information might include any assets, participants or transaction 10
history, and it is also subject to the access control rules. These queries are both 11
exposed to outside applications through the composer REST server and to the Script 12
file functions. 13
All of these components can be compiled into one file (.bna), which is then deployed 14
onto Fabric. 15
Authentication and Identities 16
Hyperledger Composer also features identity management. An identity is a digital 17
certificate and private key, in the form of an account which can interact with the 18
blockchain network. Within a certain business network, an identity can even be bound 19
to a certain instance of a Participant type. For example, if there is a participant type 20
called "Customer", an instance of that participant called "Customer1" can be created, 21
which can then be bound to some real person’s account. That person will then be 22
able to interact with the blockchain, but will be bound by whatever access rules the 23
participant "Customer" is bound by. 24
In order to make identity management easier, Composer has a feature called 25
"Business Network Cards". These cards are files which can are associated with an 26
identity and a network, and also act as a private key. If a user possesses a card, they 27
can import it to prove their identity and start interacting with the blockchain. 28
1 Fabric Topology
2 Composer also has configuration files for some of Fabric’s properties. It possesses files
3 to determine which organizations exist and which kind of nodes they possess, along
4 with their mapping. It also has a definition for the endorsement policies.
5 2.4.4 Corda
6 Corda’s take on blockchains vastly differs from Ethereum or Hyperledger. Traditionally,
7 banks have their own ledger, but Corda wants to unify these ledger’s into one, claiming
8 that it improves the cost and efficiency. Corda focuses solely on providing a distributed
9 ledger for financial services, where financial agreements can be recorded and managed,
10 available to any financial institution[5].
11 This is a very specific purpose, which means that Corda’s application on Supply
12 Chains would be rather limited, to fixing payments and agreements, perhaps. Even
13 Corda’s own smart contracts are pretty limited in what they allow, in comparison to
14 Ethereum’s, since they do not allow for all the freedom of computation. In theory,
15 Corda is limited to the financial and legal contracts domain, with the functionality for
16 custom contracts being very limited.
Figure 2.4: Corda’s vision on a Shared Ledger. Available in Corda’s White Paper [5].
17 Concepts
18 Corda is also a permissioned blockchain. While the ledger is global, some transac-
19 tions and agreements involve only certain groups and should be visible only to the
20 participating parties or those with a reason to be able to see them.
21 There are some other important concepts to understand how Corda works:
State Objects The state of the ledger, where the agreements are set and stored, in the 1
code from the contracts. 2
Transactions These are the actions that change the state of the ledger. 3
Transaction Protocols It is the business logic that enables the coordination of actions, 4
through the smart contract code. 5
CorDapps 6
CorDapps are distributed applications running on the Corda platform. The concepts 7
of State Objects, Transaction Protocols, among others, all fit into these distributed 8
applications. 9
The functionality of these applications is, however, rather limited, since a CorDapp’s 10
ultimate goal is to program a specific agreement, which will then lead to updates on 11
the ledger. So, similarly to a "smart contract", the execution of CorDapp’s leads to 12
transactions which change the state of the ledger, fixing immutable agreements into 13
the blockchain. 14
These applications have code, just like a smart contract would. But, while a normal 15
smart contract is just code, a program, CorDapps have another side to them: they 16
incorporate legal prose into the code, transforming them into something akin of a 17
"smart legal contract", legally enforceable contracts, clearly designed for the highly 18
regulated environments of the financial industry. 19
As with Ethereum, Corda also uses a virtual machine. In this case it is the Java 20
Virtual Machine (JVM), and the applications are written in Java. 21
2.4.5 Comparison 22
Comparison’s between these three platforms are recurrent, though Hyperledger and 23
Corda might have more in common with each other than with Ethereum. Valenta [39] 24
concisely describes the main points of difference between these frameworks, with a 25
focus on the consensus process and general characteristics of the frameworks. 26
He concluded that Ethereum is more of a general purpose platform, while Fabric 27
tries a different solution, adaptable to a different set of problems. Fabric is flexible 28
and customizable in ways that the other frameworks are not. On the other end, Corda 29
was designed with one specific application in mind, financial services, and it is rigid 30
in that sense, which actually made its architecture a lot more simple compared to 31
1 Fabric’s. It is also arguable that Hyperledger can be tailored to resemble Corda, due
2 to its modularity, as Corda is not really a competitor of Hyperledger, but rather a
3 complement.
4 Hyperledger vs Corda In one sense, Corda has more of an out-of-the box experience,
5 while with Fabric, the logic would have to be implemented. Composer does make
6 Fabric more user-friendly, but it is still hard to setup and configure, compared to Corda.
7 It all comes down to what kind of system we want to build, and what are its the final
8 objectives, functionalities and requirements.
9 Ethereum vs Hyperledger Also, as already pointed out in Section 2.4.2, a permis-

10 sioned ledger like in Hyperledger might better fit the supply chain industry require-
11 ments than Ethereum, though one solution does not discard the other. Another
12 important aspect to distinguish is also the difference in performance between these
13 platforms.
14 Performance
15 The difference in performance of various blockchain platforms is a crucial topic

16 to address, that might lead to choosing one platform over another, with similar
17 functionalities. In the case of Supply Chain, it might be important to measure the
18 difference in performance of Ethereum and Hyperledger, for instance.
19 Pongnumkul has conducted a performance analysis of private deployments of
20 these platforms [29] and he reached some interesting conclusions. In summary, Hy-
21 perledger’s performance is higher in every aspect than Ethereum’s (on a private
22 deployment), but, for the same resources, Ethereum can actually handle a higher
23 number of concurrent transactions.
24 The metrics used in the analysis are throughput, latency and execution time. In
25 every test performed, Hyperledger had a higher throughput, lower latency and lower
26 execution time than Ethereum. The disparity between these numbers also grew with
27 the number of transactions, with Ethereum’s performance degrading much more than
28 Hyperledger’s for the same increase in transactions. This means that Hyperledger not
29 only performs better, it also scales better, as seen in Figure 2.5.
30 Another interesting conclusion was that, with a really high number of transactions
31 (10000), Hyperledger only took 3.57 seconds to finish executing the first transaction,
32 while Ethereum took 361.36 seconds, showing that Ethereum’s network clogs easily
Figure 2.5: Comparison of average latency between Ethereum and Hyperledger, with growing
number of transactions. Available in [29].
and is slow to start up, while Hyperledger executes the transactions more consistently. 1
This was exactly one of the reasons for the revision in the architecture of Fabric. 2
Chapter 3 1
Blockchain in the Industry 2
This chapter presents an overview of how the blockchain might apply to the 3
industry in general and supply chain in particular. It goes on to describe the general 4
advantages of using blockchain, with a focus on how it might positively affect SCM, 5
as well as the disadvantages and challenges the integration of blockchain might face. 6
Some applications that are already trying to merge the concepts of blockchain and 7
Supply Chain are presented. Finally, an overview of some design alternatives are given, 8
which will be the basis for the design analysis and decisions later on. 9
The purpose of this chapter is to present some topics that might unify the topics of 10
blockchain and supply chain into one, to ascertain if they are a good fit. 11
3.1 Advantages of Blockchain in Supply Chain 12
Some of the advantages blockchain would bring to supply chain, over other solutions: 13
• Less error prone: reduction in errors on manual data entries, especially when 14
combined with IoT and other automated processes; 15
• Enhanced security of transactions: not only is the ledger immutable, attempts 16
at fraud are easily detected. 17
• Improved tracking: the ledger is easy to analyze and delivers the results really 18
fast, making it possible to know the status of any order or asset at any time; at 19
the same time, any error, either accidental or on purpose, that manages to find 20
its way into the system is easily traceable. 21

34 blockchain in the industry
1 • Improved consumer trust: blockchain could allow users to check the provenance
2 of their products, developing a relationship of trust with the suppliers.
3 • Reduced costs: reduced governance costs for exchanging info and etc, allowing
4 for higher efficiency and faster times at processing the information (enhancing
5 cost effectiveness); reduced internal management costs, increasing efficiency
6 and sustaining competitiveness; reduced product or service costs, creating com-
7 petitive advantage and barriers to competition, reduced supply chain lead times
8 and increased flexibility in supply chain design.
9 • Internal supply chain trust: It is important that the elements of a supply chain
10 trust the information that comes and goes from each other, and blockchain allows
11 this to happen.
12 This last point is one of the most important aspects, which is often overlooked in
13 favor of other more obvious functionalities.
14 Informally speaking, a business knows it can easily access its own data at any time,
15 so there is usually a lot of self trust. Therefore, businesses trust and rely a lot on
16 themselves, but not always on others. Trust means being cooperative and relying on
17 other business for the needed data, and believing that this data is also error-free.
18 As described by Panayides [27], co-operation and trust are the key in improving
19 supply chain performance and innovativeness, increasing the quality and leading
20 to benefits for all parties involved. Similarly, Yeung [42] managed to find a relation
21 between trust and a higher supply chain integration. In the context of supply chains,
22 trust might be defined as not only loyalty, but also reliability. This last aspect is very
23 important, because it measures just how much you can expect from your partners in a
24 supply chain. And when you need information quickly, trust in the form of reliability
25 is a very important asset to have.
26 In this sense, if the blockchain technology manages to improve the information
27 flow in a supply chain, while maintaining security and trust between parties (at least
28 at a technical level), then it follows that, just as concluded by Panayides and Yeung, the
29 supply chain itself will have an improvement in performance, since the parties involved
30 do not have to worry as much about these aspects or any power struggles. Therefore,
31 trust seems to be a key factor in building an efficient and effective supply chain.
challenges of blockchain application to supply chain 35
3.2 Challenges of Blockchain Application to Supply 1
Chain 2
The reverse side of the coin is that Blockchain is not always as good a solution as it is 3
prophesied. Blockchain itself is a topic in research and, while some of its applications 4
and advantages are quite obvious, many of its disadvantages are overlooked, and these 5
might be crucial when making the decision to apply blockchain to a supply chain. 6
3.2.1 Technical Limitations and Scalability Concerns 7
The technical limitations include, but are not limited to: throughput, latency, size and 8
bandwidth and security. 9
• Throughput: Current blockchain technologies, even in private deployments, such 10
as Hyperledger, have a high throughput, but not as high as certain centralized 11
systems. This is one of the main concerns in supply chain, that a blockchain can 12
not process the information quite as fast as the current systems, which could lead 13
to a decrease in performance and further delays. As in any distributed system, 14
though, the decrease in speed is often the price to pay for decentralization in 15
supply chain. Ultimately, while the flow of information inside one specific 16
company might be lower than before, the flow between different companies, 17
which were previously not integrated, might actually be much faster than before. 18
It is not fair to compare the speed of a centralized system with the speed of 19
a distributed ledger, since the latter offers more functionality and disperses 20
the information further where the former could not. A slower dispersion of 21
information globally, through various entities, is, in this case, preferred to a fast 22
dispersion only locally, through an organization’s system or its closest associates. 23
In conclusion, there might be a tradeoff between throughput and functionality, 24
with higher functionality and integration being achieved at the cost of throughput. 25
• Latency: Similarly to throughput, and related to it as well, the latency of a 26
transaction is something to take into account. With some blockchain deployments, 27
like Bitcoin, each transaction might take a long time to validate, and this time 28
might depend on the fees paid as well. This is mitigated by permissioned 29
platforms such as Hyperledger, which have low latency, even in the presence of a 30
high number of transactions, and possess no currency or fees to worry about. 31

1 • Size: The more transactions are processed and information stored in the
2 blockchain, the bigger it actually grows. In the current context, if we were
3 to deploy a global blockchain for all the supply chains, it would probably grow
4 way too large in a small amount of time, which would not be sustainable in the
5 long run. In a more limited scope, however, it would probably not be as big of a
6 problem. There is also a lot of research in the optimization of blockchain size.
7 • Security: One concern for blockchains in general is how security is handled. This
8 issue is more important in the case of public blockchains with PoW consensus.
9 In the case of supply chains, there are many alternatives, and possibly having a
10 public PoW blockchain is not the optimal one, so this is not the main security
11 aspect to worry about. There is, however, another aspect to take into account,
12 which is the fact that the hash functions being used at the moment might be
13 broken in some years. If this were to happen, the immutability property of a
14 blockchain would be broken and any prospects of proving the provenance of
15 products or their traceability would lose their groundwork.
16 3.2.2 Lack of Interoperability Standards

17 Provided that there is a way to share information, companies each have their own
18 means of inserting information into their systems, in whichever format they want, as
19 long as the correct pieces of information are there. Other companies which might want
20 to access this information might have a difficult time understanding just what to look
21 for and where to look for it.
22 This is the first part of the problem, the lack of standards by which companies
23 should abide to, if they want to form some common ground by which they can
24 cooperate and understand each other’s information.
25 The second part of the problem deals, in a more technical way, with the lack
26 of interoperability in the system’s themselves. Many Enterprise Resource Planning
27 (ERP) systems are operated under closed environments, with information often being
28 manually entered into the system, and no APIs for external systems to connect to.
29 3.3 Similar existing applications

30 Some projects which try to fit blockchain as a solution for improving SCM have already
31 emerged, or are in being worked on. This section explores some of these applications.
similar existing applications 37
3.3.1 CargoX 1
CargoX delivers a solution for making the Bill of Lading (B/L) documents digital. To 2
give some context: in a supply chain, many times, the products are delivered by cargo 3
ships, inside containers. The B/L document has the same value as the value of the 4
goods that are declared on it, serving the following functions: 5
• It is a receipt that acknowledges the loading of the products. 6
• It contains the terms of the contract of carriage. 7
• It is a title to the goods it declares. 8
These characteristics make it an extremely valuable document, which must be trans- 9
ferred from the carrier to the company acquiring the products in a safe way. Losing 10
this document would mean losing the rights to all the goods in the shipment, as well 11
as losing the proof that they were even shipped in the first place. 12
CargoX uses Ethereum’s smart contracts to put these paper documents into the 13
blockchain. It has a built in token system that allows to exchange the document’s 14
ownership immediately after payment [12]. 15
Relevance and Applicability 16
It is a very specific solution for a very specific problem. It is a concept that could be 17
integrated in a broader solution, and should fit the needs of this dissertation partially, 18
in theory. 19
The execution of the concept, however, seems to be lackluster in that it uses a public 20
blockchain, Ethereum, for extremely valuable documents. One one hand, might bring 21
about security issues, or even other problems. If Ethereum were to suffer a 51% attack 22
or any other kind of attack, the whole project would be compromised, along with the 23
bills of lading. 24
On the other hand, the project uses a token system that seems designed to monetize 25
a concept and also to move currency around more than the documents themselves. 26
In the end, the idea of transmitting documents is an integral part of information 27
integration, especially when these documents prove the ownership of something, and 28
blockchain, depending on the execution, might be a good idea to digitize that proof of 29
ownership in a way that can be traced. 30

1 3.3.2 Eximchain
2 Eximchain is an all-round solution, which acts as a ledger, recording historical data and
3 transactions, as an inventory management tool and also provides financial applications,
4 by means of smart contracts. It was developed using a fork of Ethereum, Quorum,
5 which is a permissioned version of Ethereum, focused on enterprise use, which means
6 Eximchain runs on its own network [16].
7 The smart contracts of Eximchain allow for the transmission of finances and veri-
8 fication of the validity of orders placed. All the data from these transactions, which
9 include the transmission of goods, is recorded onto the ledger, allowing suppliers to
10 prove their reliability to deliver.
11 At the same time, the inventory, as well as all the goods, as are tracked across the
12 supply chain with small delay, with the information being accessible seamlessly among
13 partners. This allows for more accurate supply and demand predictions, especially if
14 the information is directly integrated with forecasting systems.
15 Relevance and Applicability
16 This application seems to focus on the most important points of supply chain manage-
17 ment: the tracking of goods by the enterprises, the financial process of transmitting
18 those goods and the integration of this information. These applications are highly
19 practical and resonates with the goals that this dissertation tries to achieve, which are
20 exactly to turn SCM more efficient by making the information readily available.
21 3.3.3 OriginTrail
22 Like CargoX, OriginTrail operates on the Ethereum network, and has its own ERC20
23 tokens. It synchronizes all supply chain data in the platform, and uses these tokens
24 as an incentive. Underlying the use of the Ethereum network, OriginTrail has a
25 custom network topology protocol designed as a privacy-layer, which can be seen in
26 Figure 3.1. This network uses zero-knowledge methods to validate data without making
27 it accessible. This custom protocol consists of Data Holder (DH) and Data Creator
28 (DC) nodes working together to receive, transmit, store and process the information.
29 The data is communicated to the blockchain, where people with OriginTrail tokens
30 can interact with it.
31 The main objective of the project is to ensure traceability of the products as they
32 move from supplier to retailer, all while ensuring the data is not tampered with, which
similar existing applications 39
means this project has a high focus on privacy. The tokens serve as a way to exchange 1
data ownership, as well as to make reviews on a reputation system [33]. 2
Figure 3.1: Overview of the OriginTrail network. Available in [34].
Relevance and Applicability 3
This solution specializes more in the tracking of the goods, especially so that the public 4
can know where their products are coming from, as well as the companies. This allows 5
for higher integrity and authenticity of the products. A good example of a use case 6
is in situations where a bad product is detected and batch recalls need to be made. 7
With this tracking, a specific batch can be identified and removed, whereas without 8
the tracking, product providers as well as the product buyers would have to get rid of 9
substantially higher amounts of that product, leading to a loss of revenue. 10
Though it is a more specialized solution, it is important not to ignore the aspect it 11
focuses on. This can be one of the easiest methods to save money by integrating the 12
supply chain with the blockchain. 13
3.3.4 Ambrosus 14
Ambrosus focuses on tracking the quality of the goods transported during shipments, 15
specializing in the food and pharmaceutical industries. Not only does it track ship- 16
1 ments throughout the entire supply chain lifecycle, it also uses the Internet-of-Things
2 (IoT), through sensors, to communicate quality metrics of the products in real-time to
3 the blockchain.
4 The enterprises can then query this data and retrieve it immediately to their
5 own databases, effectively achieving a better quality assurance. It is also provides
6 enforceable proof of the quality or, if otherwise, the lack of it.
7 Like OriginTrail, Ambrosus also has its own protocol, called AMB-NET, which
8 hosts smart-contracts and communicates with the Ethereum blockchain.
10 This is another project with a more narrow scope, specializing in the tracking of the
11 quality by using IoT. It is something that the other projects are not implementing, but
12 it is important nonetheless. To some industries, it is even more important than any
13 other feature, which makes quality-tracking a must in a supply chain management
14 blockchain project.
15 3.3.5 IBM and Maersk’s Demo

16 IBM, together with Maersk, just recently launched an innovative project which aims
17 to create an open platform, using Hyperledger, for information sharing on a large
18 scale [2].
19 It is an open platform, which features a shipping information pipeline and paperless
20 trade. It deals mostly with the transportation of goods and automating all the processes
21 associated with it.
23 Although it has a similar purpose to the one of this thesis, there have been reports
24 of companies discontent with this platform, since it does not focus on the industry
25 as a whole and ensure common standards. Instead, it is a platform designed to meet
26 IBM and Maersk’s expectations. Other than this, there has been very little information
27 about it yet or about any progress made [1].
designing a blockchain-based supply chain 41
3.4 Designing a Blockchain-based Supply Chain 1
Blockchain is not always a one-size-fits-all solution, and its use must be carefully 2
tailored to the application in question and to the specific requirements. This section 3
describes some important points of focus to have in mind when making decisions for 4
the design of a blockchain based supply chain. 5
3.4.1 Integration Models 6
Point-to-point Business-to-Business (B2B) Data Interchange - The integration must be 7
designed between each two specific endpoints. Each new connection must be modeled 8
separately. In a large scale, this does not work very well, it is a model that only works 9
under specific cases and requirements, since it requires a customized integration. 10
One-to-many entities Hub B2B - A company can develop a connection endpoint to 11
which other companies can connect, as long as they follow the hub’s communication 12
standards or use its API. This way, a single company can establish connections with 13
multiple intermediaries. 14
Many-to-many entities Cloud B2B - This model encompasses full integration, where 15
the information can flow freely between businesses. This is the ultimate goal of a 16
public blockchain, but it would require companies the development of interoperability 17
standards, which are, at the moment, lacking. Otherwise, it is the most cost-effect 18
model and the one which can bring about the most benefits as well, given that the 19
companies can develop their services to be integrated with the blockchain. 20
3.4.2 Key Implementation Components and Features 21
As seen in the previously mentioned projects, like CargoX, Eximchain and OriginTrail, 22
each of them followed their own purpose and goals, and each of them has a different 23
set of features that allows them to achieve these goals. Similarly, these are some of the 24
key components that a blockchain possesses, and the respective features that must be 25
decided upon: 26
Information Storage The most basic and important feature of a blockchain is the 27
ability to save data, which is then considered immutable, as well as registering any 28
important events. As such, information storage might be important in the supply chain. 29
1 It also makes Inventory Management possible (though its implementation is out of the
2 blockchain’s scope), traceability and provenance of products.
3 Ledger and Transactions Similarly, allowing for transactions and their recording
4 onto the chain might be important, especially in what accounts for payments between
5 businesses.
6 Smart Contracts Finally, smart contracts have the potential to be an important part
7 of SCM. In the applications we described, smart contracts were used to transfer
8 ownership of either data or products through tokens. This is just one of the many
9 possible uses. Other smart contract uses include tracking items by their location or
10 condition, automatically updating the status on the blockchain and reacting to any
11 important events by notifying the organization responsible for the items. Another
12 possible functionality is the automation of payments upon delivery. In the end, smart
13 contracts allow for virtually any application, since they are code, programs being run
14 on the blockchain, and so, they are one of the components of blockchain with the most
15 potential for new and innovative features to be developed upon.
Chapter 4 1
Problem Statement 2
This chapter focuses on explaining the objectives of this thesis, by defining the 3
thesis statement, as well as the approach that will be taken to determine whether the 4
statements and underlying assumptions are valid or not. 5
After having previously mentioned some background information about Blockchain 6
technology and frameworks, as well as about supply chain management and supply 7
chain issues, it is now time to focus on what these issues mean. Therefore, a possible 8
way to overcome these issues through the means of Blockchain technology shall be 9
formulated and tested. 10
4.1 Objectives 11
This section introduces the focus points of the research content and the objectives of 12
the research work. 13
4.1.1 Main Points of Focus 14
In SCM, a product’s life cycle can be roughly divided into the many phases the product 15
goes through, down from the raw materials up until the finished product ends in the 16
hands of a consumer. Starting in the raw materials, most products undergo iterations of 17
processing and shipment, traveling from one place to another, while being transformed 18
in successively more refined versions and changing owners. This holds true for any 19
product in any kind of industry, and even the simplest of products which might not 20
require any processing (for instance, fresh produce), have to be shipped from their 21
place of origin to the place where they will be sold. 22

44 problem statement
1 The improvement of the management of this life cycle is one of the main objec-
2 tives of this thesis. This improvement, however, has many points of focus. Some
3 were already briefly introduced in Sections 1.1 and 1.2, from which the following
4 points are summarized as being important:
5 • Speed of delivery The effects of the evolution of SCM throughout the last century
6 are visible to everyone. Products are bought and shipped from one side of the
7 globe to the other in a matter of weeks or sometimes even days. Whether this is
8 fast enough or not is a question that can not be entirely answered in one collective
9 voice.
10 The world around us moves quickly, and in the freneticism and frenzy of our
11 lives, it might happen that sometimes weeks or days are not enough. The faster
12 the products arrive to their buyer, the faster the buyer can satisfy their needs.
13 This holds true not only for the final customer of a product, but also for any
14 enterprise that provides products and services to other enterprises, be it in the
15 role of supplier, manufacturers, distributors or retailers.
16 • Synchronization Many times, the data from a company is synchronized with

17 its own servers and software, in protocols and data formats that can only be
18 understood by that specific piece of software. If many companies share this same
19 software, then they can easily integrate the information between themselves.
20 The real problem occurs when the companies have no common ground and the
21 data is not transmittable in an automatic way, leading to a lot of unnecessary
22 manual work to export the data from one system and import it into another.
23 Though there may be many causes for this, the logic assumption would be that
24 this problem may be originated mainly from the following:
25 – Lack of development of data integration standards in the supply chain

26 industry.
27 – Lack of a common technology to store all data, from where each company
28 could have their own software extract the information from.
29 • Tracking During a product’s lifetime, a lot of alterations occur and, sometimes,

30 the records about the origins of the products are lost, falsified, or flat out not kept
31 in a registry. This leads to unreliability in the goods the consumers use everyday
32 and it may happen that some products are falsified and not the real product they
33 were advertised to be. Additionally, it can also happen that the products, not
objectives 45
being properly tracked, do not hold up to the conditions or quality standards 1
that are required by the regulatory entities. This can sometimes even lead to 2
safety hazards. If a product is subject to hazardous conditions during any part of 3
its lifecycle, it may become dangerous to be used or consumed. 4
For this reason, it is of the utmost importance that the products are tracked 5
since their origin, right up until the delivery to the final customer, as well as the 6
conditions they are shipped in and the transformations they suffer. 7
• Security This point is one of the most important to deal with, as security is 8
comprised of many aspects, such as: who to authorize to access the information 9
and how to restrict this, what authentication methods should be used, how to 10
accurately detect and prevent fraud, etc. 11
Information in a supply chain is highly sensitive and it should be controlled so 12
that only trusted entities can access it. Most enterprises (or groups of enterprises) 13
compete amongst themselves to make the most sales, the most deliveries and 14
have the fastest product cycles. Therefore, the information that is generated 15
in the process of managing a supply chain might be too sensitive to share, in 16
order to keep the edge on the competition. Additionally, the information that 17
is generated and inserted into any system should always be verified, in order 18
to prevent both human error and fraud attempts. 19
4.1.2 Possible Solutions 20
While these previous points of focus are not problems in themselves, their improvement 21
will greatly benefit any industry as well as the consumers of these industries. As 22
such, the actual problem here can be narrowed down to finding a way to satisfy these 23
needs for improvement through technological means. 24
Some of the most common and traditional solutions for this problem include 25
distributed systems, and there are many solutions already available. However, these 26
solutions, which include distributed systems like the cloud or distributed databases, 27
might not satisfy all the needs of the supply chain. Researching alternative designs 28
can be a good way to find new and useful implementations that might possibly even 29
revolutionize this area. 30
So, is there any other tool or technology that can be applied to SCM, in order to 31
satisfy the need for improvement, one that is scalable, as well as secure? In many ways, 32
Blockchain is similar to a distributed database, and it can even be integrated with the 33
1 cloud for a mixed solution (the best of both worlds?), so there is a need to investigate
2 if it might or might not be a good solution for the supply chain requirements.
3 4.1.3 Thesis Statement

4 The main objective has already been defined: to improve the security traits, tracking of
5 goods and processes, information synchronization, and possibly speed of delivery of
6 the supply chain, along with other minor attributes. A seemingly good alternative that
7 stands out is Blockchain.
8 Therefore, the main statement that this thesis defends is:
9 "Blockchain is a good architectural design for the Supply Chain Management
10 domain."
11 What remains to be answered, though, is if mentioned attributes are really the right
12 requirements to focus on, and if Blockchain can really fill them, as a distributed archi-
13 tecture. Thus, it can be seen that this statement might be based on some assumptions,
14 which gives rise to some more questions. For instance, we are assuming that the points
15 of focus from Section 4.1.1 are really the most important ones, given the background
16 information that was collected.
17 Thus, the questions that need to be answered first, in order to reach a conclusion
18 towards the main thesis statement are the following:
19 1. What supply chain issues, improvements and requirements do the experts

20 really find the most important?
21 2. What is the Blockchain tool or framework most adequate to the development

22 of an architecture that can support these requirements?
23 3. Is it possible to build a feasible architectural design, by using such a tool, to

24 implement all these requirements?
25 These questions are sequential, meaning that, in theory, in order to answer one
26 of them, we have to answer the previous question. But in practice, it is not always
27 practical to follow this sequence, and a question might serve as a guide to start
28 working on the following one. Therefore, the questions can be worked on iteratively.
29 For instance, having some answers to the survey might allow work on the architecture
30 and prototype to start, and, as more answers are collected, the more the requirements
31 for the prototype are refined.
approach 47
In the end, all the questions end up being answered and it is possible to reach 1
a definitive conclusion towards the thesis statement. The sub-conclusions are also 2
interesting to analyze and are a contribute themselves to this area. 3
4.2 Approach 4
To answer these questions from Section 4.1.3, the work of this dissertation was divided 5
into two main parts, each of them comprising a chapter: 6
1. Supply Chain Issues Validation and Requirements Elicitation 7
2. Solution Design and Implementation 8
Each of these focuses on reaching a conclusion towards the answers that underlie 9
the thesis statement. 10
4.2.1 Supply Chain Issues Validation And Requirements Elicitation 11
The first question to answer in order to reach any conclusion is "What supply chain is- 12
sues, improvements and requirements do the experts really find the most important?". 13
As already mentioned, the other questions depend on the answers that we reach for 14
this question. 15
The proposed way that was used to get an answer was an online survey. The 16
survey serves the following purposes: 17
• Collecting quantitative data on the relevance of the issues that supply chain 18
management suffers from. 19
• Collecting quantitative and qualitative data on which are the major points of 20
improvement and compare their relative importance. 21
• Collecting quantitative and qualitative data on which use cases the experts think 22
Blockchain can be more useful to accomplish. 23
• Collecting quantitative and qualitative data on which the functionalities that 24
supply chain requires of information systems and blockchain. 25
• Correlate some of the data collected in the previous point and reach some extra 26
conclusions that might help decide on the validity of the results. 27

1 The survey was designed to be answered by people with experience in the field
2 of Supply Chain, with knowledge about Blockchain being optional but appreciated.
3 These are the opinions that have the most importance on this field, and these are also
4 the people that interact with the systems in question and can more accurately pinpoint
5 the points of failure and improvement.
6 The survey was distributed over the internet, through relevant media and social
7 forums, as well as through direct contact with professionals from the area. It was
8 shared on some telegram channels of projects that apply Blockchain to the supply
9 chain (most of which mentioned in the state of the art), on Reddit, through their supply
10 chain and logistics forums, as well as on supply chain focused forum websites. It
11 was also distributed to professionals through messages on LinkedIn (with a focus on
12 managers), personally and through email.
13 In conclusion, the goal of the survey is to validate some assumptions and direct the
14 dissertation towards the most important supply chain management problems.
15 4.2.2 Solution Design and Implementation

16 This section is focused on applying the knowledge of which are the most impor-
17 tant aspects of supply chain to focus on improving, to answer the other two final
18 questions: "What is the Blockchain tool or framework most adequate to the devel-
19 opment of an architecture that can support these requirements?" and "Is it possible
20 to build a feasible architectural design, by using such a tool, to implement all these
21 requirements?"
22 The state of the art review documented in Chapters 2 and 3 already provided some
23 information towards the answer to the first of these questions, through the comparison
24 of frameworks. Therefore, and taking the results of the survey into account, a brief
25 analysis is undertaken to make a decision.
26 Finally, and to answer the final question about the possibility and feasibility of
27 building a blockchain-based architectural design for supply chain management, the
28 implementation of a proof of concept is undertaken, using the chosen platform.
29 This approach is divided into the following phases:
30 1. Requirement Elicitation and validation - through the literature review research

31 and survey results
32 2. Design - using the requirements, building a model that can implement the
33 elicited requirements
approach 49
3. Implementation - program the system according to the design 1
4. Validation - check if the built system satisfies the initial requirements fully, and 2
if otherwise, explaining why not 3
After this approach is finished, the results are analyzed qualitatively, as to which 4
use cases are implementable and usable or not and as to what were the limitations 5
found because of the various decisions taken. Taking the various points of this analysis 6
into consideration will allow for some conclusions to be taken in reference to the 7
remaining question. 8
After having answered all of the three questions that underlie the thesis statement, 9
it is possible to analyse the validity of the thesis statement ,though future work may 10
eventually bring different answers, since Blockchain is a technology which is seeing 11
great and fast developments, due to the amount of research being put into it. 12
Chapter 5 1
Supply Chain Issues Validation and 2
Requirements Elicitation 3
The opinions of experts from a field can be highly valuable for research to achieve 4
valuable contributions for that field. The optimal way to validate the issues of the 5
supply chain would be to interview experts in a formal way. However, there were 6
difficulties in this aspect, especially because most of the contacts did not go through 7
and a lot of time and effort put into this was not fruitful. Therefore, since expert 8
knowledge was still necessary, it was decided that a survey would be a more efficient 9
method of gathering opinions and results. 10
The survey was written during the months of March and April, 2018, with results 11
being collected from the end of April up until the mid of June. The purpose, method- 12
ology and results of the survey are analyzed in this chapter, leading to the validation 13
of the issues mentioned in the previous chapters. The survey and analysis done here 14
also serves as a basis for the requirements that were used to build a proof of concept 15
prototype. 16
However, due to various factors, the survey and collection of results was delayed 17
from the initial planning, resulting in the collection of results only being completed in 18
June. Thus, the PoC used some assumptions from both the background analysis and 19
the few initial answers from the survey, and kept iterating the requirements based on 20
the new answers received during the development. 21

52 supply chain issues validation and requirements elicitation
1 5.1 Purpose and Target

2 Even though the survey was delayed, the answers given are still important in the
3 end. The main purpose of this survey, as stated in 4.2.1, was to give a response
4 to the question we are focusing on: "What supply chain issues, improvements and
5 requirements do the experts really find the most important?".
6 This is done by dividing the survey into groups of questions: some about the
7 issues of supply chain, some about the points of improvement as well as the opinions
8 applicability of Blockchain as a system for supply chain management. Together,
9 these allow for an opinion to be formed about the quantitative measurements of the
10 importance of each issue, as well as a qualitative collection of requirements.
11 The survey is aimed at people with knowledge in the area of Supply Chains, and
12 optionally Blockchain. The combination of knowledge in both areas is relevant for the
13 questions that focus Blockchain applicability. However, having low knowledge about
14 Blockchain is also relevant, so that the answers are more diversified for both sides,
15 thus reducing the bias.
16 5.2 Methodology
17 This section describes how the data was collected and analyzed. It gives a brief
18 overview of what questions were asked, how they were grouped, the objectives of each
19 question, along with the type of answers used.
20 5.2.1 Data Collection

21 The data for the survey was collected by sharing the survey with professionals of the
22 supply chain area, through contact with related companies, personal contacts, social
23 networks like LinkedIn, Reddit and conversation groups.
24 The collected sample size was 25. Even though these are answers from knowledge-
25 able people, the sample size is not very significant, so the margin of error for this study
26 is higher than if it were otherwise.
27 The questions of the survey can be roughly grouped into four main groups of
28 questions. Each of the groups has similar questions, with a distinct purpose.
29 1. Question Group 1 - General Information

methodology 53
• Questions - Information about the respondent’s contact with supply chain, 1
role in the industry, years of experience and number of employees in the 2
current company (if in a job related to supply chain). 3
• Goals - Characterization of the respondent’s, especially in order to validate 4
the relevance of their profiles. 5
2. Question Group 2 - Blockchain Knowledge and Opinions 6
• Questions - Questions about the general knowledge of Blockchain technol- 7
ogy, opinions about Blockchain cryptocurrencies and their usefulness in 8
various contexts, as well as Blockchain regulation and the effect of GDPR on 9
Blockchain technology. 10
• Goals - Get a vision on the need or not of cryptocurrencies for Blockchain 11
related architectures, as well as the impact of regulations on this technology. 12
3. Question Group 3 - Supply chain Points of Focus and Problems 13
• Questions - Questions to rate affirmations that deal with supply chain 14
issues, focusing on the level of agreement that the participants have with the 15
affirmations. Most of the affirmations correlate supply chain major issues 16
with the points of failure that might underlie them; The others rate specific 17
problems in an importance scale or by percentage of occurrence. 18
• Goals - Validation of the issues that affect the supply chain management 19
metrics the most, as per the opinion of specialists. 20
4. Question Group 4 - Supply Chain Points of Improvement and Applicability 21
of Blockchain Technology 22
• Questions - The first half of these questions serves to prioritize the im- 23
portance of some supply chain issues, as well as the importance of some 24
functionalities that supply chain information systems should feature. The 25
second half of the questions ranks the use cases and benefits that Blockchain 26
could bring to supply chain management. 27
• Goals - This is the main point of the survey, and from here, the most 28
important information towards the conclusions we want from the survey is 29
gathered, which consists in the supply chain issues leading to Blockchain 30
system requirements. 31
1 Most of the important questions use statements with the Likert scale in the answer,
2 from 1 to 5, where 1 means "Strongly Disagree" and 5 means "Strongly Agree". In
3 this survey the middle of the scale, 3, is "Neutral" or "Neither Agree nor Disagree"
4 and there was a separate answer with "Do not know". Therefore we can classify this 1
5 to 5 scale as ORDINAL, since all of the values directly relate to a scale of increasing
6 agreement. Additionally, some of the other questions also use a scale of importance
7 from 1 to 5, while the remaining questions mostly have nominal answers (meaning
8 that the group of answers for a question are fixed, qualitative and not numerical).
9 5.2.2 Data Analysis

10 The analysis of the answers is done through bar graphs and using mostly the measures
11 of central tendency or location, measures of central spread, scale or dispersion and
12 measures of skewness and kurtosis. The metrics used to analyze the data set and
13 reach some conclusions are therefore: the mean, median and mode, the standard
14 deviation and range, and the skew.
15 The meaning behind these metrics and how they are applied here can be found in
16 annex A.1.
17 To classify if the skew of the distribution is high or not, there is a measure
18 that
q can be calculated, the skewness standard error, with the following formula:
6∗ N ∗( N −1)
19
( N −2)∗( N +1)∗( N +3))
, where N = samplesize.
20 For a sample size of 25, the Skewness Standard Error is 0,463683501.
21 5.3 Results
22 The results of the survey are analyzed in this chapter 1 . Each group of questions
23 features the graphs and metrics of the corresponding questions, and a brief informal
24 analysis is done, based on the values.
25 5.3.1 Question Group 1 - General Information and Participant Clas-

26 sification
27 Data from the participants was inquired, including: role, industry, years of experience
28 and company size (if they worked in one at all).
1 The results are available at: https://drive.google.com/file/d/
1Zyg8BGj0dV6KFKPZdshgbYHYi-m8snGX/view?usp=sharing
results 55
What is your role in the Supply Chain Industry? WHAT SUPPLY CHAIN INDUSTRIES DO YOU WORK ON OR
I am a Developer, either working or
HAVE THE MOST EXPERIENCE WITH?
4% interested in Supply Chain.
4%
Retail 4
I am a Student (Masters/PhD).
12%
Transport and logistics 13
I am an investor.
Other 4
I am knowledgeable in these areas, but
12% don't necessarily study or work with them.
56% None 2
I work in Consulting related to Supply
Chain and Logistics.
Health 5
My position at a company is directly

12% involved in the processes of Supply, Electronics 2
Manufacturing, Retail, Logistics or
Transport.
0 5 10 15
(a) Role played in relation to Supply Chain Management (b) Industry

How many years of experience do you have in Supply Chain? How big is your company in number of employees? (Optional)
8% 8% 201 to 1000
13%
50 to 200
8%
36%
3 to 5
Less than 50
6 to 10
Less than 3 More than 1000

None 42%
48%
No Answer/I do not work for a
29% company involved in Supply
Chain
8%
(c) Years of experience (d) Number of employees in company
Figure 5.1: Questions about the respondent’s Role, Industry, Years of Experience and Company
Size.
The data, as can be seen in Figure 5.1, can be summarized in the following state- 1
ments: 2
• Most people, about 68% of the respondents, have an active role working in 3
areas related to supply chain. From these, 56% work in a company directly 4
involved in the processes of supply, manufacturing, logistics, retail or transports 5
and 12% work in consulting related to these areas. The rest are people with a 6
profile that gives them knowledge about supply chain, be it through education 7
or other type of contact with the field. 8
• The most common area of supply chain to work in is, by far, Transport and 9
Logistics, with 52% of the respondents saying they have work experience in this 10
field. Health and Retail are also common areas, with 20% and 16% respectively. 11
• 48% of the respondents have less than 3 years of experience, with 36% having 12
3 to 5 years and 8% having 5 to 10 years. However, in total, there were only 2 13
respondents (8%) without any years of experience in the field. 14

1 • 62,5% of the respondents work in medium to big companies (more than 50

2 workers), from which 41,7% work in companies with more than 1000 people and
3 12,5% in companies with between 200 and 1000 people.
4 Conclusions from Question Group 1

5 From this data, we can ascertain the general profile of the survey respondents. These
6 are people who, in their majority, work in big companies related to the supply chain,
7 in the various fields, but mostly in transport, logistics and health. The respondents,
8 though they may have had education in this area, do not show a high number of years
9 of experience, with most of them having only up until 5 years of experience.
10 5.3.2 Question Group 2 - Blockchain Knowledge and Opinions

11 This section features some questions that inquire about the respondent’s knowledge in
12 blockchain, and their opinions about the relationship between cryptocurrencies and
13 blockchain. Are blockchains independent of cryptocurrencies or not? And in which
14 cases? These are questions that will also help decide the need of a cryptocurrency for
15 the design of the system that was proposed.
16 1 - General Blockchain Knowledge.
How would you grade your knowledge of BLOCKCHAIN

technology?
12% 8%
1 - No knowledge
20%
2 - Insufficient knowledge
3 - Sufficient knowledge
24%
4 - Good knowledge
5 - Very good knowledge
36%
Figure 5.2: Question about Blockchain knowledge.

results 57
In Figure 5.2, it can be seen that most answers are in the middle of the scale, while 1
both the extremes have few answers, which closely resemble a gaussian or normal 2
distribution. 3
Indeed, when calculated, the skew of this data is about -0,065104294, which is a 4
very low number (the standard error was about 0,46) and close to 0 (zero). A normal 5
distribution has a skew of 0 (zero), so this can be said to be a good approximation. 6
Additional, it can be said that there is not much of a bias towards accepting or denying 7
blockchain when answering other questions, either from knowing too much or too 8
little, since the knowledge curve seems to be normal. 9
2 - Rate the affirmations about the use of cryptocurrencies in the 10
blockchain. 11
After inquiring about the blockchain knowledge of the respondents, some affirmations 12
were made about cryptocurrencies, which can be seen below. The question was 13
optional, since respondents without sufficient knowledge of blockchain might face 14
difficulties understanding the affirmations. 15
Affirmations: 16
1. A blockchain always needs to have a cryptocurrency attached in order to work 17
well. 18
2. Cryptocurrencies are useful in blockchains open to the public, in order to create 19
incentives for good behavior, but not always necessary in private chains. 20
3. Blockchains can be useful in some uses cases, independently of whether they 21
hold a cryptocurrency or not. 22
Independently, these affirmations do not hold an absolute value that can help 23
ascertain if there is a need for a cryptocurrency in the case of supply chain. But 24
together, the three affirmations lead to a higher degree of certainty. 25
The first affirmation states that a blockchain, any at all, independently of the 26
purpose or type, does indeed need a cryptocurrency. The second affirmation goes 27
on a tangent from the first one, stating that maybe cryptocurrencies are only needed 28
as an incentive, and otherwise could be not needed. The final affirmation is more 29
generic in nature, and attempts to completely separate the concept of blockchain 30
and cryptocurrency. The results for each affirmation can be found in Figure 5.3 and 31
in Table 5.1. 32
WHAT IS YOUR OPINION ON THE FOLLOWING STATEMENTS REGARDING THE

RELATIONSHIP BETWEEN BLOCKCHAINS AND CRYPTOCURRENCIES?
15
13
13
Do not know
11
1 - Strongly Disagree
10
2 - Disagree
7
3 - Neither Agree nor
Disagree 5
4
4 - Agree
3
1
1
5 - Strongly Agree
0
0
A BLOCKCHAIN ALWAYS CRYPTOCURRENCIES ARE BLOCKCHAINS CAN BE
NEEDS TO HAVE A USEFUL IN BLOCKCHAINS USEFUL IN SOME USE CASES,
CRYPTOCURRENCY ATTACHED OPEN TO THE PUBLIC, IN INDEPENDENTLY OF
IN ORDER TO FUNCTION ORDER TO CREATE WHETHER THEY HOLD A
PROPERLY. INCENTIVES FOR GOOD CRYPTOCURRENCY OR NOT.
BEHAVIOUR, BUT NOT
ALWAYS NECESSARY IN
PRIVATE BLOCKCHAINS.
Figure 5.3: Question to rate affirmations about the use of cryptocurrencies in the blockchain.
Table 5.1: Question results metrics for the affirmations about the use of cryptocurrencies in the
blockchain.
Standard
Mode Median Mean Range Skewness
Deviation
1. Blockchain needs
1 1 1,36 0,79 3 2,74
cryptocurrencies to work well
2. Cryptocurrencies are only
useful as incentives in public 4 4 4,06 0,87 4 -2,51
blockchains
3. Blockchains can be useful in
some cases, regardless of having 5 5 4,61 0,50 1 -0,50
or not cryptocurrencies
1 • The first affirmation has a very low agreement rate. Almost all of the respondents
2 answered that they strongly disagreed with it, which can be seen in the table,
3 as both the mode and median are 1, and the mean is also close to it. It can
4 be concluded that, according to these opinions, blockchain can sometimes not
5 have a cryptocurrency and still perform well.
6 • The second affirmation has a high agreement rate, with an average of 4.06. The
7 mode and mean are also very close to the mean, and the standard deviation is
8 lower than 1, which means that there is a consensus on the responses. Therefore, it
9 can be concluded that, as per the opinions of the professionals, a cryptocurrency
10 is more useful in public blockchain contexts and applications, as an incentive,
11 than in private blockchains, where these incentives are not needed.
results 59
• The last affirmation has a very high agreement rate, the highest of them, with 1
a mode and median of 5, and a mean of 4.61. There is a strong consensus, as 2
all of the respondents answered with either 4 or 5 (Agree or Strongly Agree), 3
leading to a low standard deviation and range. There is a slight skew, since the 4
answers are distributed between these 2 items, with a bigger number of responses 5
on item 5. The conclusion for this affirmation is that blockchains are useful, 6
independently of holding a cryptocurrency or not. 7
Conclusions from Question Group 2 8
With these conclusions in mind, one final conclusion can be derived. If blockchains 9
do not need cryptocurrencies to perform well (concluded from the non agreement 10
with affirmation 1) and can generally still be useful without them (affirmation 3), 11
then cryptocurrencies should not be considered a necessity, but rather a design 12
option, depending on the benefits it can bring to a particular use case. Taking this 13
conclusion into account, and also according to the agreement with affirmation 2, 14
then: if a blockchain design features a private blockchain, it does not necessarily 15
need a cryptocurrency as a requirement, since incentives are not needed. This is an 16
especially interesting conclusion for the proof of concept. 17
5.3.3 Question Group 3 - Supply Chain Points of Focus and Prob- 18
lems 19
This part of the survey focuses on finding out if the issues dug out on the background 20
and pointed out in the Problem Statement chapter are really the ones that plague 21
supply chain management. As such, a battery of questions including the various 22
concerns mentioned was given to the respondents. 23
1 - Speed of Delivery, synchronization and traceability issues 24
The respondents were asked the following 2 questions, as well as some affirmations to 25
classify their agreement with. 26
Questions: 27
1. In your experience, how frequently does the absence of crucial information cause 28
delays in processes such as shipping, packaging, etc.? 29
2. How important is Inventory Management for the efficiency of the supply chain? 30
1 Affirmations:
2 1. In a supply chain, if the information gap between partners is shortened, a faster

3 product cycle (or shorter lead time) can be attained.
4 2. Distribution, supply, demand and inventory planning all rely heavily on the
5 information being both accurate and up to date
6 3. Supply Chain Management lacks a way to quickly and seamlessly share between
7 companies all the information generated by the flow of assets in a Supply Chain.
8 The data collected from the first 2 questions can be visualized in the graphs from
9 Figure 5.4. The data for the 3 affirmations can be visualized in the graphs from
10 Figure 5.5 and was summarized in Table 5.2.
IN YOUR EXPERIENCE, HOW FREQUENTLY DOES THE ABSENCE OF CRUCIAL HOW IMPORTANT IS INVENTORY MANAGEMENT FOR THE
INFORMATION CAUSE DELAYS IN PROCESSES SUCH AS SHIPPING, EFFICIENCY OF THE SUPPLY CHAIN?
PACKAGING, ETC.?
14
13
9
12
11
10
7
6
4
4
3
2
1
1
0
0
1 - NOT AT ALL 2 - SLIGHTLY 3 - IMPORTANT 4 - FAIRLY 5 - VERY

1 2 3 4 5 6 7 8 9 10 IMPORTANT IMPORTANT IMPORTANT IMPORTANT
(a) Inventory Management Importance (b) Relation between the absence of information and delays
Figure 5.4: Questions to rank inventory management importance and relationship between
absence of information and delays.
results 61
RATE THE FOLLOWING AFFIRMATION: "DISTRIBUTION, SUPPLY, DEMAND

RATE THE FOLLOWING AFFIRMATION: "IN A SUPPLY CHAIN, IF THE AND INVENTORY PLANNING ALL RELY HEAVILY ON THE INFORMATION
INFORMATION GAP BETWEEN PARTNERS IS SHORTENED, A FASTER BEING BOTH ACCURATE AND UP TO DATE"
PRODUCT CYCLE (OR SHORTER LEAD TIME) CAN BE ATTAINED."
18
14
16
16
12
12
14
10
10 12
10
9
8
8
6
6
4 4
2
2 2
1
0
0
0
0 DO NOT KNOW 1 - STRONGLY 2 - DISAGREE 3 - NEITHER 4 - AGREE 5 - STRONGLY

DO NOT KNOW 1 - STRONGLY 2 - DISAGREE 3 - NEITHER 4 - AGREE 5 - STRONGLY DISAGREE AGREE NOR AGREE
DISAGREE AGREE NOR AGREE DISAGREE
DISAGREE
(b) Relation between management planning and information ac-

(a) Relation between information gap and delays
curacy
RATE THE AFFIRMATION: "SUPPLY CHAIN MANAGEMENT LACKS A WAY TO
QUICKLY AND SEAMLESSLY SHARE BETWEEN COMPANIES ALL THE
INFORMATION GENERATED BY THE FLOW OF ASSETS IN A SUPPLY CHAIN."
14
13
12
10
6
5
4
2
2
1
0
DO NOT KNOW 1 - STRONGLY 2 - DISAGREE 3 - NEITHER 4 - AGREE 5 - STRONGLY
DISAGREE AGREE NOR AGREE
DISAGREE
(c) Affirmation about the lack of a system with good integration

of information
Figure 5.5: Questions to rate affirmations about the effects of information gaps, the reliability of
management planning and lack of a system with good integration.
Beginning with the analysis of the 2 questions: 1
• The first question had the objective of finding out whether Inventory Management 2
is an important discipline for the efficiency of the supply chain, which is an 3
important aspect, if it is to be treated as point of possible improvement. The data 4
was ranked from 1 to 5, with 1 being "Not at all important" and 5 being "Very 5
Important". The question scored a mean of 4.48, with the mode and median 6
both being 5, since most results sit on that score. There is little dispersion in the 7
results, with most of the other answers scoring a 4 and only 1 answer scoring a 3. 8
It can be concluded that Inventory Management is an essential discipline for 9
supply chain management, according to the professionals. 10
• The second question tries to relate the absence of information with delays in the 11
processes of sending products. The scale went from 0 to 10, which corresponded 12
from the percentages 0 to 100%. The final results ranged from 40% to 90%, with 13
most of the answers sitting between 60% and 80%. The results were not very 14
spread out, with a standard deviation of only 1.29, in the scale of 1 to 10. There 15
Table 5.2: Question results metrics for the affirmations about the effects of information gaps,
the reliability of management planning and lack of a system with good integration.
Standard
Deviation
Affirmation 1 - A reduction
of the information gap
5 4 3,92 1,26 3 -1,21
between partners can lead
to a faster product cycle.
Affirmation 2 - Distribution,
supply, demand and inventory
planning all rely heavily on 5 5 4,64 0,49 1 -0,62
the information being both
accurate and up to date.
Affirmation 3 - Supply Chain
Management lacks a way to
quickly share between 4 4 3,79 0,83 3 -0,56
companies all the information
from the supply chain.
1 were not also any significant outlier values, with the skew being classified as
2 normal, with a value below the threshold of the standard error. The average
3 result for this opinion was 68%, which is a reasonably high percentage that we
4 can say there might really be correlation between these 2 aspects, especially
5 given the consensus and non-existence of outlier values. However, this can
6 never be said with total certainty, since these are only opinions and not factual
7 data.
8 A follow-up with the analysis of the opinions about the affirmations:
9 • The first affirmation related a reduction in the information gap with a faster
10 product cycle. In layman’s terms, this can be thought of as "if there is more
11 information available, the products will get made faster, shipped faster and
12 received faster". Many respondents seemed to only cautiously agree with the
13 affirmation, not committing to a strong answer. Even though the most popular
14 answer was 5, the mean still was below the normal agreement level, at 3.92.
15 There is some skew and spread, due to the lower results, but these still look
16 like valid answers. Therefore, it can be informally generalized that while it may
17 be true indeed that having information available will generally help products
18 finish their cycle faster, it might not always be the case, as there is not a strong
19 consensus about this.
20 • The second affirmation relates all the planning disciplines in SCM with the
21 existence of up-to-date and accurate information. The respondents all answered
results 63
with either 4 or 5, a very low spread of answers, with most of them strongly 1
agreeing (agreement average of 4.64. It can then be concluded that having accurate 2
and up-to-date information is essential for these planning management tasks, 3
which, of course, affect inventory management, which we already concluded to 4
also be essential. It is, therefore, of the utmost importance for a supply chain 5
to be provided timely with exact information. 6
• The last affirmation states that supply chain management might lack a way to 7
integrate the information provenient from the flow of assets between companies 8
easily. However, out of the 3 affirmations, this is the one with the lowest agree- 9
ment of them. While the average agreement, 3.79, is close to the one from the first 10
affirmation, the most popular choice here was 4 (Agree), followed by 3 (Neutral). 11
The skew is almost low enough that this would represent a normal distribution 12
for the answer. While it seems that not every professional agrees, and some 13
think that there are already good ways to integrate information quickly and 14
seamlessly, the majority still thinks that SCM is lacking on this aspect. 15
2 - Quality assurance and traceability issues 16
Finally, with the objective of ascertaining whether quality assurance is also an issue, 17
the respondents were asked 2 questions, with the results being shown in Figure 5.6. 18
The first, similarly to previously, was asking about the agreement with an affirmation, 19
and the second was a question. Both the affirmation and question are as follows: 20
1. Non-compliance with certain standards is a big issue that affects the reputation 21
of companies working with sensitive products. 22
2. In your experience, do you think that compliance with quality standards would 23
be easier to achieve if all the products were traced as well as the processes they 24
go through? 25
RATE THE FOLLOWING AFFIRMATION: "NON -COMPLIANCE WITH CERTAIN IN YOUR EXPERIENCE, DO YOU THINK THAT COMPLIANCE WITH QUALITY
STANDARDS IS A BIG ISSUE THAT AFFECTS THE REPUTATION OF COMPANIE S STANDARDS WOULD BE EASIER TO ACHIEVE IF ALL THE PRODUCTS WERE
WORKING WITH SENSITIVE PRODUCTS." TRACED AS WELL AS THE PROCESSES THEY GO THROUGH?
14 16
15
12
12 14
11
12
10
10
9
8
8
6
6
4
4
2
2 2
1
0
0
0 0
DO NOT KNOW 1 - STRONGLY 2 - DISAGREE 3 - NEITHER 4 - AGREE 5 - STRONGLY DO NOT KNOW 1 - STRONGLY 2 - DISAGREE 3 - NEITHER 4 - AGREE 5 - STRONGLY
DISAGREE AGREE NOR AGREE DISAGREE AGREE NOR AGREE
DISAGREE DISAGREE
(a) Relation between standard non-compliance and company (b) Relation between process traceability and quality standards
reputation compliance
Figure 5.6: Questions about quality assurance issues.
1 Looking at the graphics, the second question has a slightly higher agreement rate
2 than the first one. However, both questions have very high agreement results, with
3 absolutely no disagreement answers and only 1 neutral answer on the second question.
4 It can be concluded that quality standards compliance might affect a company’s
5 reputation and is also somewhat dependent on the traceability of products and
6 processes they go through.
7 Conclusions from Question Group 3

8 • From the first set of questions, we summarily conclude that the accurate syn-
9 chronization of data and the speed of delivery (metrics stated in the problem
10 statement) are related and an improvement in the synchronization might posi-
11 tively affect the speed of delivery, as well as other important metrics of a product’s
12 cycle. Though there may be solutions for this, the professionals still that they
13 might be lacking.
14 • From the second set of questions, the only conclusion was that companies have
15 in their interest to follow the quality standards, and traceability plays a big role
16 in this.
17 The questions from this group have successfully validated most, if not all, of the
18 supply chain issues raised in the previous chapters. The remaining questions from the
19 survey point towards points of improvement for these issues, as well as what possible
20 features to implement in a system could help with these issues.
results 65
5.3.4 Question Group 4 - Supply Chain Standalone Points of Im- 1
provement and Blockchain points of Applicability and Im- 2
provement for Supply Chain 3
The first goal for this part of the survey is to find out the points of improvement 4
for supply chain. What is being questioned are not the issues of the supply chain 5
themselves, which were already asked, but what parts of supply chain, even though 6
they may already work well, could work even better. 7
The second goal is to find out more about the requirements that an information 8
system must have to satisfy the needs of SCM. This includes ranking the functionalities 9
of an information system for their importance. Many of these functionalities probably 10
relate to the points of improvement found here, as well as to the supply chain issues 11
described in Section 5.3.3. 12
For the sake of simplifying the ranking process for both the "points of improvement" 13
and "functionalities of an information system", a division into groups of importance shall 14
be done according to the observed results. The importance scale went from 1 to 5, but 15
most of the mean scores were between 3 and 4.5. 16
Therefore, the following classification for the lists of results will be adopted: 17
• Mean ≥ 4 - High priority or importance 18
• 3.5 ≤ Mean < 4 - Medium importance 19
• Mean < 3.5 - Low importance 20
1 - Rank the importance of some aspects which Supply Chains aim 21
to improve. 22
In this category, we can see the results on Figure 5.7 and then represented on Table 5.3. 23
Pretty much all the options had a range of 3 and deviations close to 1, which is to be 24
expected. Traceability had the highest skew value, as there seemed to be some dissent, 25
as a few outlier values pushed the mean to be lower than the median. However, it still 26
rated the highest, by importance. 27

RANK THE IMPORTANCE OF SOME ASPECTS WHICH SUPPLY CHAINS AIM TO

IMPROVE.
1 - Not at all important 2 - Slightly Important 3 - Important

4 - Fairly Important 5 - Very Important Do not know
20
18
18
16
14
13
13
12
12
11
10
10
8
8
6
6
6
6
5
5
4
4
4
4
4
4
3
3
2
2
2
1
1
0
0
0
0
TR A CEA B ILITY D EVELO PMEN T F R AU D AU TO MATED B ET TER D ELIVERY S U PPLY
O F IN D U S TRY D ETEC TIO N IN FO R MATIO N IN FO R MATIO N S CHED U LES CO N TRO L
S TA N DA R D S S HA R IN G PR IVA CY
Figure 5.7: Question: "Rank the importance of some aspects which Supply Chains aim to
improve."
Table 5.3: Question results metrics for the question to rank the importance of improvement
aspects of the supply chain.
Standard
Deviation
Traceability 5 5 4,40 1,12 3 -1,67
Development
of Industry 4 4 3,63 1,06 3 -0,36
Standards
Fraud
5 5 4,13 1,18 3 -1,00
Detection
Automated
Information 5 4 3,64 1,19 3 -0,20
Sharing
Better
Information 2 2 3,13 1,32 3 0,51
privacy
Delivery
5 4 3,84 1,28 4 -0,71
Schedules
Supply Control 5 5 4,24 0,926 3 -0,87
results 67
The importance ranking described as before follows below: 1
1. High importance - "Traceability", "Supply Control", "Fraud Detection"; 2
2. Medium importance - "Delivery Schedules", "Automated Information Sharing", 3
"Development of Industry Standards" 4
3. Low importance - "Better Information Privacy" 5
Conclusions: 6
• High Importance - It had already been concluded from the previous set of 7
questions in 5.3.3 that inventory management was an essential discipline to 8
SCM, so it was expected that Supply Control would be rated highly as a point 9
of improvement, which it did. The same can be said about Traceability: it 10
was expected to rank highly, since it is related to both quality assurance and 11
availability of information, two other issues that were validated in the previous 12
set of questions. At the same time, Fraud Detection was also highly ranked, which 13
can be explained by its relation to traceability and quality compliance and control. 14
Traceability helps to avoid fraud and, at the same time, fraud detection also 15
relates to quality control and compliance, since avoiding fraud is all about 16
making sure that the products circulating the supply chain are authentic and 17
have good quality. With this in mind, it is only natural that Fraud Detection is 18
considered important, together with traceability. 19
In conclusion, the 3 most important items are traceability, supply control and 20
fraud detection, with supply control and fraud detection directly depending 21
on the traceability, which makes traceability probably the most important 22
point of improvement in the supply chain. 23
• Medium Importance - From the items that got rated as medium importance, 2 of 24
them relate to synchronization improvement: Automated Information Sharing and 25
Development of Industry Standard. The last point, Delivery Schedules also relates to 26
Supply Control, though it is less generic. 27
In conclusion, though system synchronization is not as important as traceabil- 28
ity or some of the other items that depend on traceability, it is still a welcome 29
improvement which comes in second place to the others. 30

1 • Low Importance - Finally, the lowest ranking item was Better Information Privacy.
2 This comes as a surprise, since security was a big focus on the background
3 research for supply chain management.
4 The conclusion we can take from this item being rated the lowest, is that it
5 might be a concern that the current systems already take care of, therefore it
6 does not have much space for improvement.
7 2 - Rank the importance of the following functionalities for an infor-

8 mation system that stores or processes data pertaining to a Supply
9 Chain
RANK THE IMPORTANCE OF THE FOLLOWING FUNCTIONALITIES FOR AN

INFORMATION SYSTEM THAT STORES OR PROCESSES DATA PERTAINING TO A SUPPLY
CHAIN
1 - Not at all important 2 - Slightly Important 3 - Important

4 - Fairly Important 5 - Very Important Do not know
16
15
14
13
12
12
12
11
10
8
8
8
8
7
7
6
6
6
6 6
5
5
4
4
3
2
2
2
1
1
1
0
0
0
0
0
0
0
0
INTEROPERABILITY SECURITY STANDARDIZED STANDARDIZED REAL-TIME MONITORING AND OPTION TO ADD CONTROLLED
BETWEEN SYSTEMS ACCORDING TO THE PROCESS DATA FORMATS TRACKING AND CONTROLLING INFORMATION AS ACCESS FOR THE
(ERPS, MES, AND LATEST SECURITY INTERFACES SHARING OF EVENTS ATTACHMENT USERS
OTHER REQUIREMENTS (STANDARDIZED INFORMATION
INFORMATION DATA PROCESSING WITH PARTNERS
SYSTEMS) AND APIS)
Figure 5.8: Question: "Rank the importance of some functionalities in a supply chain based
information system."
10 Results for this question are found in Figure 5.8, and the analysis metrics are in
11 Table 5.4 the range of answers is pretty much 3 for all options but 2 of them. The
12 mean and median of the items are also a close approximation of each other, which
13 happens because the skew in most cases is not very high (only for the Interoperability
14 and Security items was it higher than 1). The skew is highest on the items that also
15 had the highest mean. This happens because, even though these items are the most
results 69
Table 5.4: Question results metrics for the question to rank the importance of functionalities in
an information system for supply chain.
Standard
Deviation
Interoperability Between
Systems (ERPs, Manufacturing
5 4,5 4,29 0,86 3 -1,08
Execution Systems, and other
information systems)
Security according to the
5 5 4,33 1,05 3 -1,49
latest security requirements
Standardized Process Interfaces
4 3 3,32 1,18 4 -0,36
(Data Processing and APIs)
Standardized Data Formats 4 4 3,60 0,96 3 -0,31
Real-time tracking and sharing
5 4 4,16 0,94 3 -0,67
of information with partners
Monitoring and controlling events 5 3 3,48 1,19 3 0,05
Option to add information
2 3 2,79 1,02 4 0,19
as attachment
Controlled access for the users 4 4 4 0,85 3 -0,96
popular, there are always a few answers from people who disagree. However, this is 1
to be ignored, given the low deviation and given that the median and mean are very 2
close to each other in every case. Therefore, the mean can still be used here to classify 3
the importance. 4
The importance ranking described as before follows below: 5
1. High importance - "Security according to the latest requirements", "Interop- 6
erability Between Systems", "Real-time tracking and sharing of information", 7
"Controlled access for the users"; 8
2. Medium importance - "Standardized Data Formats" 9
3. Low importance - "Monitoring and controlling events", "Standardized Process 10
Interfaces", "Option to add information as attachment" 11
Conclusions: 12
• 2 of the high importance items actually relate to security, namely access control 13
and following security requirements. This contrasts with the point of improve- 14
ment from the previous set of questions "Better information privacy", which was 15
rated the lowest in relative importance. There seems to be a disparity between the 16
importance of the functionality and the importance of the improvement, which 17
might mean that the functionality is important but already good enough as it is. 18
1 The conclusion we can take is that keeping security up to date still seems to
2 be considered important, but on aspects other than privacy (which is already
3 fulfilled) such as access control, which relates to authorization and authenti-
4 cation.
5 • The other 2 high importance functionalities were about interoperability between

6 systems, and tracking and sharing information. Tracking and sharing information
7 relates to traceability and information synchronization, while interoperability
8 relates only to synchronization.
9 Though these points, which relate to synchronization scored high as a func-
10 tionality, the points of improvement they relate to only scored as medium
11 in the previous sections, namely "Automated Information Sharing" and "De-
12 velopment of Industry Standards". Thus, integrating the information is seen
13 as an important aspect to have,but not one that needs improvement over the
14 current status.
15 • Most of the items rated as having medium or low importance do not necessarily
16 stand out nor do they have important conclusions to be taken. The one thing that
17 stands out is that "Monitoring and controlling events" rated as a low importance
18 functionality, even though traceability rated high as a point of improvement,
19 which does not make a lot of sense, since traceability also means having the
20 means to monitor what is happening.
21 3 - Blockchain applicability to the supply chain

22 The final important group of questions featured 2 questions about the viability of
23 applying blockchain to the supply chain. The results are shown in images 5.9 and 5.10
24 The first question asked people which use cases they thought were the best for applying
25 blockchain to the supply chain and respondents could select a maximum of 3 options
26 (including "None" or "Do not know").
results 71
W HICH US E CAS ES DO YOU S EE AS M OST VIAB L E FOR AP P LY IN G

B LOCKCHAINS TO T HE S UP P LY CHAIN ?
Location Data 1
Secure data storage 10
Regulatory compliance and auditing 11
None 1
Financial transactions 15
Do not know 2
Customer engagement and verification 4
Contract enforcement 11
Asset management 6
0 5 10 15 20
Figure 5.9: Question about the Blockchain use cases for the supply chain.
What benefits would you expect BLOCKCHAIN to bring to Supply Chain Management in
your industry (or in general, if you don't belong to one in specific)? Select all that
apply.
Reduction of risks (tampering/fraud information leaks etc.) 17

Reduced time to transmit information between systems from
partners 12
Stronger working relationship with partners 16
None 1
Lower cost for processing transactions 6
New business models (via contracts, identity management,
financial management) 9
Increased global processing speed 12
Improved business efficiency 8
Do not know 1
Better transaction integrity and visibility 16
Better data protection 9
Automation of business processes among partners 8
0 5 10 15 20
Figure 5.10: Question about the Blockchain benefits for the supply chain.
Starting with the analysis of the first question: 1
• Financial transactions was, by far, the most popular choice. The respondents 2
look at blockchain as a way to move money as an asset, more than a tool to 3
manage the goods themselves, since traditional systems only deal with data and 4
the money is dealt with by third parties (banks). It makes sense that the second 5
most voted choice is Contract Enforcement. As per the background research 6

1 and state of the art, it was pointed out that some of the applications already
2 enforce payments through contracts, when the goods are delivered,for instance,
3 without the need of a third party (thus reducing fees). Financial transactions and
4 contract management go hand in hand.
5 • With the same number of votes, also in second place, is "regulatory compliance
6 and auditing". Regulatory compliance is a term also related to contracts enforce-
7 ment. Contracts are used to establish mandatory rules which are automatically
8 enforced according to the conditions of the system (for instance, enforce that the
9 food transported in a truck never goes over a certain temperature value). How-
10 ever, an important point to note is that regulatory compliance and auditing
11 are made possible through the traceability characteristic of blockchain, which
12 allows for products and processes to be thoroughly verified. This means that
13 traceability is a highly sought after application of blockchain.
14 • "Secure data storage" was also a highly voted option. Security is an important
15 focus in information systems, so this should be taken into account when building
16 the proof of concept. In the previous set of questions, "access control" and
17 "security according to the latest requirements" were also features that stood
18 out, so it is not a surprise that secure data storage is seen as one of the main
19 advantages of blockchain, since it boasts of being cryptographically secure,
20 having immutability by design and an easy to implement access control..
21 The proof of concept has to not only take these use cases into account as the main
22 applications, but also implement (or make possible the implementation of) the most
23 important features of information systems previously analyzed, which makes the
24 second question complementary of the first one.
25 For the second question, there is an analysis of the benefits that blockchain can
26 bring to the supply chain, according to the respondents:
27 • The three most voted items were: "Better transaction integrity and visibility", "Reduc-
28 tion of risks (fraud/tampering/information leaks)" and "Stronger working relationships
29 with partners".
30 The first two items were expected to rank high. They directly relate to the security
31 and traceability, points of improvement already discussed - traceability makes it
32 possible to view the records to make sure nothing suspicious is going on, and
33 the security and immutability of the information makes it impossible to tamper
34 with the data.
results 73
The third point, "Stronger working relationships with partners", however, is 1
interesting to see being chosen a high ranked benefit. The concept of strong 2
relationships with partners is linked to the concept of internal supply chain 3
trust, which was already introduced in 3.1. The ability for partners to trust each 4
other is what makes the supply chain possible and efficient to the standards of 5
today. It seems that the professionals really do think of blockchain as a tool to 6
improve this internal trust. 7
The selection of these 3 items as the most voted does not seem to be a coincidence. 8
Blockchain can be used as a source of truth for the supply chain and this leads 9
to the side benefits of internal trust, better relationships with the partners, 10
less fraud, less tampering, less leaks, among other benefits, all made possible 11
because of the main characteristics: security and traceability. 12
Conclusions from Question Group 4 13
This was the most important group of questions in that it provides direct information 14
as to which functionalities the proposed system design should possess and implement. 15
At the same time, these functionalities can be related to the points of improvement 16
found, as well as to the issues validated in the previous groups of questions. 17
• From question group 3, some issues in the supply chain were validated: inventory 18
management, quality assurance and getting accurate and timely data. On this 19
group, the main points of improvement were found to focus on: traceability, 20
supply control, fraud detection and synchronization. In a generalized way, the 21
common links to both issues and points of improvement seem to be: security, 22
traceability and synchronization, effectively validating the initial concerns from 23
the problem statement. 24
• Another important conclusion to take from this set of questions are the features 25
to include in the design for the blockchain system. These include the "Blockchain 26
only features", functionalities implemented in an unique to the blockchain, as 27
well as the standard "Information system features", which are the features that 28
were found to be the most important to information systems in a supply chain. 29
• By order of importance, the blockchain features are: 30
– Financial transactions. 31
– Some form of regulatory auditing. 32

1 – Enforceable contracts (smart contract functionality).

2 – Secure data storage.
3 – Asset management.
4 • By order of importance, the most important information system requirements

5 are:
6 – Security according to the latest requirements.

7 – Interoperability between systems.
8 – Real-time tracking and sharing of information with partners.
9 – Controlled access for the users.
10 5.4 Comparison to the state-of-the-art projects

11 Most of the projects analyzed in the state-of-the-art, thought they use a multitude of
12 different frameworks and custom networks, also do not focus on satisfying all of the
13 requirements, but mostly a subset of them. Most of the projects specialize only in 1
14 problem area, like traceability, instead of going for an all-rounded concept.
15 CargoX This project focuses somewhat on Secure Data Storage, Enforceable Con-
16 tracts and Security, even though in a limited way, since the data stored is not for any
17 asset or document, but specifically for bill of lading documents. Additionally, it lacks
18 a lot in the traceability items.
19 Eximchain It attempts to tackle all of the areas: Traceability, Security, Synchroniza-
20 tion, Contracts and Finance. Though it promises a lot in its presentations, the actual
21 whitepaper and technical documents focus mostly on the financial and contractual
22 aspects and do not explain how the other aspects will be achieved in detail. The
23 product looks promising for this area, by focusing all the requirements in a way that is
24 claimed to be efficient, with custom networks and consensus algorithms and proto-
25 cols. However, and very importantly, Eximchain’s product has not yet been proven to
26 work. The project has 3 proof of concepts planned in their roadmap, each focusing on
27 separate areas, but none has been presented yet.
28 OriginTrail This project boasts of its strong traceability capabilities, mainly for
29 asset management, auditing and fraud detection. It is a specific project, but it does
30 not fit all of the requirements above, as it misses the financial transactions and some
31 security aspects, such as access control. Again, as is the case with Eximchain, the
conclusions 75
project seems promising, but is yet to prove most of its functionalities, having released 1
proof of concepts mostly for the traceability requirements. This seems to be a common 2
element to most of these projects, in that they look promising but take a long time to 3
prove that they can deliver their promises. 4
Ambrosus Focuses a lot on auditing, fraud detection, quality control and traceabil- 5
ity in general, so it fills all the traceability requirements. Even though these features 6
are a must, and seemingly the most important, most of the other requirements are not 7
met, especially the financial transactions, asset management and part of the security 8
requirements. 9
In summary, the existing projects are either very specialized and do not meet all 10
the requirements, or they are very broad in the requirements, but in early stages of 11
development, without proving that they can do what they promise. 12
5.5 Conclusions 13
Having analyzed all the groups of questions from the survey, it should now be possible 14
to have an answer for the first question of the thesis sub-statements, presented in 15
the problem statement: "What supply chain issues, improvements and requirements do the 16
experts really find the most important?". 17
Most of the conclusions for the survey were summarized in the analysis of question 18
group 4. These conclusions included the most important issues of the supply chain, 19
points of improvement, blockchain features and information system functionalities 20
important to the design. 21
Issues - These include inventory management, quality assurance, and lack of 22
accurate and timely data. This last item was confirmed by the respondents to have a 23
correlation to the lack of good integration and synchronization tools and to be one 24
of the possible causes for the difficulties in planning management and product cycle 25
delays. 26
Point of improvement - These include traceability, supply control, fraud detec- 27
tion and synchronization. These items reflect themselves on the feature requirements 28
that were elicited. The results can therefore be crossed with the points of improvement 29
to make more refined logical groups of requirements: 30
Important Features - The most important features, gathered from a junction of 31
information system features and blockchain features, are summarized in Table 5.5. 32
These are important contributions from the experts of the area, though with a 33
Table 5.5: Elicited requirements grouped by improvement area of focus.
Area Requirements
Security according to the latest requirements
Security Controlled access for the users
Secure data storage
Regulatory auditing
Fraud detection
Traceability
Asset management
Real-time tracking information
Interoperability between systems
Synchronization Development of industry standards
Real-time sharing of information with partners, leading to
better working relationships
Transaction Financial transactions
Enforcement and Enforceable contracts (smart contract functionality)
Financial domain
1 bigger sample, the answers would have been more representative. The next chapter
2 will focus on these requirements as the major points of focus for the design.
Chapter 6 1
Solution Design and Implementation 2
Following the conclusions and requirements elicited from the previous chapter, it 3
is now time to answer the remaining two questions. The first question, "What is the 4
Blockchain tool or framework most adequate to the development of an architecture 5
that can support these requirements?" requires an analysis of the frameworks. The 6
second question, "Is it possible to build a feasible architectural design, by using 7
such a tool, to implement all these requirements?" requires that the elicited require- 8
ments be formed into a list and that an architectural design be built and implemented 9
using the chosen framework. Only at the end of these tasks can we verify if all the 10
requirements are implemented by the PoC. 11
This chapter deals with explaining these tasks sequentially. The first section 12
analyzes which frameworks best satisfy the requirements and a choice is made. The 13
second through fourth sections resemble a software engineering approach: starting in 14
the requirements specification, following it up with the design, implementation using 15
the framework and finally, the validation of the requirements. 16
6.1 Framework Comparison and Choice 17
Following the conclusions and requirements elicited in the previous chapter, it is 18
now time to answer the second question from the problem statement: What is the 19
Blockchain tool or framework most adequate to the development of an architecture 20
that can support these requirements? 21
In order to make a good choice for the framework, there is a need to make a mixed 22
analysis that focuses on the most important functionalities that an information system 23
78 solution design and implementation
1 should feature as well as what use cases are most viable for applying blockchain to the
2 supply chain.
3 In addition to the requirements from the previous chapter, the performance analysis
4 from Chapter 2.4.5 should also be taken into account.
5 6.1.1 Framework Requirements Elicited from the Survey

6 The requirements for the choice of a framework can be partially derived from the most
7 important functionalities pointed out on the results of the survey, in Table 5.5. These
8 functionalities are directly based on some points of focus from this thesis: synchro-
9 nization, security and tracking or traceability, so it is based on these attributes that
10 the framework should also be selected.
11 Security: From Section 5.3.4, it was ascerted that the improvement of information
12 privacy in supply chains was not very important in itself. Maybe it is something that the
13 current systems already do well, but as we can see, there are still some outstanding
14 concerns which deal with other security aspects that still need to be taken care
15 of: access control and fraud detection seem to rank high on the requirements for
16 such a system. Thus, the selected framework should support a highly controlled
17 environment, where the actions each user takes should be properly authorized and
18 there are good authentication mechanisms. Some fraud verification checks should
19 be supported.
20 Traceability: For the traceability requirements, the proposed system should be
21 able to track all information, including changes in the system, registries of assets,
22 transactions, network participants and organizations. It should also be open to outside
23 regulatory entities, so that they can look into the system for auditing. Addition-
24 ally, sanity checks and other fraud-detection operations should be possible, possibly
25 through smart-contract functionality. Thus, the selected framework must support the
26 management of data in the form of assets, entities and organizations, which should
27 be accessible only to specific entities, including auditors.
28 Synchronization: As the source of truth, the blockchain should be easily accessible
29 to any external system that needs to query or insert data. The elicited requirements
30 for synchronization include the development of standards and system interoperability
31 for real-time sharing of the information. Thus, the selected framework should easily
32 expose the blockchain information to outside systems (for instance, through REST
33 APIs) using predefined data formats.
34 Transaction Enforcement and Financial domain: There is interest in financial ap-
framework comparison and choice 79
Table 6.1: Summary of the framework requirements for each improvement area.
Area Framework Requirements

Highly controlled environment
Security Authentication and authorization mechanisms
Fraud verifications (by smart contracts)
Management of data: assets, entities, organizations
Traceability
Data access controlled, but accessible to auditors
Expose data to the outside systems through APIs
Synchronization
Allow the use of predefined data formats
Transaction Smart Contracts
Enforcement and Native cryptocurrency or a way to simulate currencies or
Financial domain account balance
plications, and cryptocurrencies are a part of this. However, for financial applications 1
to be possible in the supply chain using blockchain, a native blockchain cryptocurrency 2
is not necessarily needed, as cryptocurrencies can be simulated using balances, de- 3
pending on the design of the blockchain network. For this, and other functionalities to 4
work, smart contract functionality should exist, though. Thus, the selected framework 5
should either have a native cryptocurrency, or allow for the design of some kind of 6
digital balance or token. Additionally, it should support smart contracts. 7
This information is summarized in Table 6.1. 8
6.1.2 Framework Choice 9
So, what conclusions can be taken from these framework requirements? Firstly, a 10
private blockchain framework seems more adequate, because of all the security con- 11
trol mechanisms that are needed. Secondly, the framework should allow for highly 12
customizable networks, including not only asset management, but also identity 13
management, where the participants of the blockchain can be given specific permis- 14
sions. Lastly, the framework needs to allow the use of APIs. 15
Crossing these requirements with the capabilities of the frameworks presented in 16
the background chapters, we can do an analysis of the applicability of each one: 17
• Ethereum - It is a public framework that features a native cryptocurrency and 18
has strong financial capabilities. However, it costs money to run code on. Having 19
a lot of the required functionalities on Ethereum would be a lot more expensive 20
than in a private network, where only a few nodes need to be maintained. At 21
the same time, it does not natively feature the essential identity management, 22
1 authentication and authorization mechanisms. It features strong financial and

2 traceability, but lacks in security and cost scaling.
3 • Corda - It is a private network, cheaper to maintain, and most of the privacy

4 requirements are possible. It also focuses a lot on financial transactions, which
5 was a highly rated requirement. However, it sorely lacks in the management of
6 data like assets and entities, therefore having weak traceability properties.
7 • Hyperledger Fabric - It has the needed mechanisms for authentication and au-
8 thorization, and, similarly to the other frameworks, has smart contract capability.
9 It is highly customizable, allowing for all the data and identity management
10 needed. As for synchronization, it features easy to deploy rest servers, which is
11 also important. However, it has a setback: though it is customizable, it does not
12 feature a native cryptocurrency, so financial transactions are possible, but only if
13 designed from scratch to be simulated by the network.
14 From a requirements perspective, Hyperledger fits practically all of the require-

15 ments, if we assume that financial transactions can be simulated within the network.
16 Ethereum has the setbacks of cost and security, while Corda has the setback of lacking
17 asset management and traceability.
18 To make the framework decision final, a performance comparison should also
19 be used. Based on previously published studies, which were mentioned in 2.4.5,
20 Hyperledger has a lower latency, execution time and higher throughput than Ethereum.
21 All while being cheaper to maintain and satisfying more requirements than any of the
22 other analysed frameworks.
23 The question "What is the Blockchain tool or framework most adequate to the
24 development of an architecture that can support these requirements?" can finally be
25 answered. From the analyzed tools, Hyperledger Fabric, together with Hyperledger
26 Composer, seems to be the tool that both satisfies the most requirements and has
27 higher performance and lower costs, being the most adequate of the analyzed tools for
28 the development of an architecture for supply chain.
29 6.2 Requirements Specification

30 From the survey, a list of high level requirements was defined, but these requirements
31 need to be refined into more detailed requirements, if they are to give origin to a
32 design and implementation. As it was already mentioned, in theory, the survey would
requirements specification 81
have to be finished before the requirements were written, but in practice, the work was 1
done more iteratively. 2
The structure for this specification will somewhat resemble the organization of IEEE 3
830-1998 requirements specification standard [36], but in a simplified way, without 4
some of the unneeded clutter and information. The specification is divided in the 5
following way: 6
1. Introduction - Product purpose, scope, overview and users; 7
2. Requirements - Specific requirements including functional requirements, non- 8
functional or quality requirements, permission list and design constraints. 9
6.2.1 Introduction - Project Drivers 10
1. Scope of the Work 11
This project is being developed as a proof of concept to validate the feasibility of 12
implementing of a supply chain-based blockchain using Hyperledger Fabric and 13
Composer. It does not represent what a fully developed project would act or look like. 14
Therefore, the objective is to showcase a product concept that can enhance the 15
discipline of supply chain management, according to the results of the survey, by 16
making the data more easily accessible, reducing synchronization time, improving 17
integration and security, and providing a tool that assists in guaranteeing end-to-end 18
traceability. 19
2. Scope of the Product 20
This PoC encompasses the development of a Hyperledger Composer business network 21
accompanied by the respective Hyperledger Fabric node topology. The business 22
network itself is comprised of the blockchain ledger model and respective integration 23
endpoints. The ledger will be designed to accommodate transactional data from a 24
supply chain, and it will also be possible to execute smart contracts, in the form of 25
transactions, to manage both assets and the identities of the participants. 26
The process of extracting data from the ERP systems and forwarding it to the 27
system’s node endpoints, as well as the process of sending data from the ledger to the 28
ERP are out of the scope of this PoC. External systems must themselves build their 29
own integration modules. Building the needed APIs for this is a task of this project, as 30
1 well as the standardization of the data, with the aim of facilitating future integration
2 tasks.
3 3. Client, Customer, Stakeholders

4 This project would benefit any industry which uses supply chain, but more particularly,
5 it would be directed towards any company which wishes to integrate their own
6 information systems (i.e. ERPs and so on) with this ledger, such as to maintain a
7 common underlying information transmission channel with their partners, as well as
8 to have more permanent records of their transactions.
9 Possible stakeholders for this system and the benefits they have are listed as:
10 • Supply Chain Executives, Managers and common employees
11 • Manufacturing companies, Suppliers, Distributors, Retailers - the executives

12 and managers represent all of these company types; these companies can have
13 their partners information more readily available, therefore speeding up the
14 transmission of goods and increasing trust;
15 • The consumer - the consumers may be able to track some of their goods to a
16 more precise level;
17 • Auditors and certification Authorities - easy single entry points for auditors to
18 collect their information from;
19 These are some examples of typical users of the Product:
20 • Supply Chain members - the employees from all types of companies will be the
21 most common users, and they may register incoming and outgoing products on
22 the blockchain (through their companies own integration module); distribution
23 delivery employees may, for instance, register deliveries, etc.
24 • Regulatory Entity - the auditors that will use the network to view information
25 from the companies and make sure everything appears to be running correctly
26 and without fraud.
27 • System administrators - to control the network, help solve any issues that come
28 up and do the needed maintenance.
29 • Integration developers - the developers in charge of connecting their companies

30 system to this system.
Each user shall have defined roles assigned within the system, according to their 1
needs. These roles, along with the system itself, are the actors of the system: 2
• System - Hyperledger Fabric and Composer have certain behaviours that can be 3
adjusted, which makes it possible for the system itself to be an actor with specific 4
requirements it shall be able to satisfy. 5
• Regulatory Entity 6
• Admin 7
• Supply Chain Member 8
– Supplier 9
– Manufacturer 10
– Distributor 11
– Retailer 12
– Customer 13
6.2.2 Functional Requirements Drivers 14
1. Functional Requirements 15
To simplify reading and to save space, the functional requirements list consists of a 16
small explanation at the beginning, followed by each requirement, with the ID and 17
description. Since Hyperledger Fabric and Composer are being used, the requirements 18
have some terms specific to the software, such as asset registry, transaction registry, 19
participants, etc. 20
The System The system itself needs to be able to record aggregate all of the data 21
into blocks; the data consists of transactions, which are the actions undertaken in the 22
system, and there should be registries for the network participants and assets as well. 23
It is important that the information from these transactions can be made visible and 24
that they can be invoked by the participants which have the permissions to do so. At 25
the same time, the system should be able to handle multiple organizations joining the 26
ledger, inserting all of their current data to the system, as well as extracting it to their 27
own systems when needed. 28
Identity management, consensus, access control, synchronization of information 29
are all be concerns of the system and how it is programmatically written. Some of 30
1 these concerns are already partially supported by Hyperledger, but the remaining have
2 to be implemented. In the end, the system used itself already has a lot of support for
3 the elicited requirements from the survey.
4 • S1 - The system shall allow the execution of chaincode transactions.
5 • S2 - The system shall record all user actions, including transactions, into a registry
6 with the identification of the user and action performed.
7 • S3 - The system shall maintain an immutable list of all the past transactions, in
8 the form of blocks.
9 • S4 - The system shall allow for the submission of a transaction batch, with many
10 transactions at once (possibly corresponding to the synchronization process of a
11 company uploading their data, for instance).
12 • S5 - The system shall assign each transaction a timestamp.
13 • S6 - The system shall allow for the definition of multiple channels/sub-ledgers,

14 to support separate sets of permissions and separate the information of different
15 organizations in Composer.
16 • S7 - The system shall be able to emit notification events.
17 • S8 - The system shall be programmed to be able to detect any mismatches that

18 might constitute fraud: for instance, a product being received in a location
19 different than the one where it was supposed to show up.
20 • S9 - The system shall define different permissions for each role and for some
21 specific identities, including permissions for invoking transactions and reading
22 the data on the ledger.
23 • S10 - The system shall be able to expose all of the actions that users can undertake
24 in the form of a REST API.
25 • S11 - The system shall be able to authenticate users through a REST API.
26 Supply Chain Member For the supply chain member users, all of the following
27 requirements are only doable in case the specific actor has the specific permissions,
28 as was mentioned in requirement S9. In this system, the supply chain members
29 need to be able to manage their assets and shipments. All of the actions need to
30 be recorded onto the immutable ledger, which means that any action happens by
the invocation of a transactions. Therefore, the users can invoke transactions for 1
pretty much every action they need to do: to create, edit, delete assets, interact with 2
shipments, deploy contractual agreements, check the status of assets and shipments. 3
All of these actions will ensure both the data management and information tracking 4
and traceability aspects that were so popular in the survey. The financial aspect and 5
enforceable contracts requirements are also included in these requirements. 6
• SCM1 - The members shall have the ability to invoke transactions. 7
• SCM2 - The members shall have the ability to read the information of assets, 8
other people and transactions, according to their permissions. 9
• SCM3 - The members shall have the ability to write and deploy their own 10
contractual agreements on the blockchain. 11
• SCM4 - The members shall be able to query and obtain the steps through which 12
a particular product has gone, effectively tracing the product from origin up to 13
where it is at the moment of the query. 14
• SCM5 - The members shall be able to query what is the current entity possessing 15
an asset. 16
• SCM6 - The members shall be able to create assets. 17
• SCM7 - The members shall be able to edit or delete the assets they own. 18
• SCM8 - The members shall be able to create shipments with the assets they own. 19
• SCM9 - The members shall be able to attach contracts to their shipments. 20
• SCM10 - The members shall be able to query all the information of a specific 21
shipment, including the owner, holder and assets involved in the shipment. 22
• SCM11 - The members shall be able to query the shipments owned by a specific 23
user. 24
• SCM12 - The members shall be able to query the user that possesses a specific 25
asset, if they have the permission to do so. 26
• SCM13 - The members can check a shipment status, location and the status of 27
all the item status included in the shipment, given that they are either the buyer, 28
seller or current holder of the shipment. 29

1 • SCM14 - The members shall be able to submit item damage reports into the
2 system for the assets in the shipments that they hold;
3 • SCM15 - The members shall be able to update the shipments, along with the
4 status, for the shipments they hold.
5 • SCM16 - The members shall be able to edit their identity;
6 • SCM17 - The members shall be able to input an XML file with a standardized
7 format in order to submit data automatically;
8 • SCM18 - The members shall be able to hold a cryptocurrency, in the form of a

9 balance, with a static equivalence to real money, so that they can transfer it in
10 contracts, in order to enable payments, fines and to settle contractual agreements.
11 Regulatory Entity
12 The auditor is a role essential to manual fraud detection, as well as to ensure that
13 the system is working well and as intended. As such, the auditor needs to be able to
14 have full read access to the system.
15 • RE1 - The regulatory entity shall be able to query and obtain the steps through
16 which a particular product has gone, effectively tracing the product from origin
17 up to where it is at the moment of the query.
18 • RE2 - The regulatory entity shall be able to query all the transactions, participants
19 and assets in the system.
20 Admin
21 The admin is an essential part of the ecosystem that the blockchain will support.
22 Any node maintenance, any problem, will have to be solved by an admin. The
23 admin is also the entry point for users to join the network, as well as an authority
24 that can help fight fraud and make the system more secure and controlled. The
25 identity management mechanisms, which include authentication and authorization
26 are managed by the admin, making the admin an essential user for the enforcement of
27 the elicited requirements.
28 • A1 - The admin shall be able to revert the effects of certain transactions, by

29 submitting a transaction that has the opposite effect of a given transaction.
30 • A2 - The admin shall be able to create and delete new ledger channels.
• A3 - The admin shall be able to create a network identity card for a user. 1
• A4 - The admin shall be able to assign a user’s network identity card to an 2
instance of a virtual participant of the network. E.g.John’s card ca be associated 3
to the network participant Auditor#21. 4
• A5 - The admin shall be able to update the details of the participants, including 5
their initial balance. 6
• A6 - The admin shall be able to create, edit or delete assets; 7
• A7 - The admin shall be able to submit any transaction; 8
• A8 - The admin shall have the permission to change the roles of the other users. 9
• A9 - The admin shall have the permission to give others the permission to change 10
roles. 11
These requirements were written having in mind the architecture of the Hyperledger 12
projects, as well as the needs of a supply chain. They are also loosely written because 13
they are iterated on during the implementation phase of the proof of concept. 14
2. Data Requirements 15
Another important part of the requirements which is not in itself an action undertaken 16
by the users, is the form in which the data is formatted. One of the main objectives of 17
building a blockchain system transversal to a whole supply chain, is to make the data 18
as standardized as possible, so that any organization can easily import or export the 19
data from the ledger to their systems and still have it in formats that any organization’s 20
system can understand. 21
As such, research was undertaken, and the following data requirements were built, 22
based on the standards from the GS1 organization 1, an organization which builds 23
global supply chain standards. 24
• The data is divided into Master Data and Transactional Data. 25
• The Master Data relates to Products/Assets and Entities, being more generalist 26
and fixed, for those pairs. It includes the location number (for the location), the 27
1 https://wiki.hyperledger.org/_media/groups/requirements/hyperledger_-_
supply_chain_traceability-_anti_counterfeiting.pdf
1 entities name, country and address data, as well as the asset’s weight, name,
2 identification number (GTIN).
3 • The Transactional Data relates to the movement of assets through the supply
4 chain, in the form of transactions. It includes the "when" part of the transactions,
5 such as the planned date, expected dates and actual dates of a shipment, for
6 instance.
7 In a real system, all these data requirements would have to be implemented in a

8 perfect way, with all the parameters, but this project, only being a proof of concept will
9 use the minimum number of data fields deemed necessary for the implementation and
10 basic functionalities of the system.
11 6.2.3 Non-Functional Requirements Drivers
12 1. Non Functional Requirements Drivers

13 Overall, the product should follow these parameters:
14 1. Usability
15 The available product, corresponding APIs and documentation should be clear
16 enough to allow for the developers to perform the implementation of an oracle,
17 which is a piece of software that connects the blockchain to another external
18 product, serving as a means of pulling and pushing information from and to the
19 blockchain and from and to the external system (ERP, for instance).
20 2. Performance
21 Speed and latency: The throughput and latency on Hyperledger have already
22 been tested, and the throughput is not expected to be as high as in a centralized
23 data system. But, overall, the time to synchronize the information from one
24 company to another might increase; The goal is to make the product be as fast
25 as needed to support the businesses, even if it does not have better performance
26 than other alternatives, since what we are looking for here is the addition of new
27 functionalities (shared ledger);
28 Precision and accuracy: The product shall record the data just as it was entered,
29 and the predictions as to whether a product has any mismatching entries shall
30 always be justifiable;
Reliability and availability: The product shall not always be available unless all 1
of the nodes fail at once, which is almost impossible, unless a coordinated attack 2
were to happen; If some of the nodes happen to fail, the response time of the 3
system might be lower than expected; 4
Scalability: The product should scale to hundreds of companies, which would 5
require a similar number of nodes; 6
3. Maintainability and portability 7
The product is expected to run on Linux based systems, compatible with the 8
Docker, nodejs and golang versions that Hyperledger Fabric uses. More specif- 9
ically, Amazon Web Services services have servers with the required setup for 10
this. 11
Creating new nodes or moving an existing one should be an easy process, without 12
much complication, other than starting the node software on the environment, 13
and closing an existing one, if needed. 14
4. Security 15
Privacy: The system must ensure appropriate visibility of transactions and 16
products, which might be privacy sensitive; sharing some data would pose 17
a threat or could possibly have negative effects for some of the companies; 18
otherwise, transactions should also be secure, authenticated and verifiable; 19
Immutability: No one can make changes to the contents of the ledger; 20
Authorization: All changes to any data should be approved by the people that 21
possess the data or will be affected by these changes directly. A shipment delivery 22
transaction should, for instance, be approved by both the person delivering and 23
the person receiving the shipment 24
5. Legal 25
The ledger might be subject to verification from competent legal authorities or 26
auditors, and it must also comply with certain laws, such as the european global 27
data protection regulations (GDPR); 28
"Traceability and its relation to the law (e.g., regulatory law, international law 29
etc.) has a profound effect upon many products. In the case of diamonds, conflict 30
minerals or rare earth derived material several international agreements and 31
global law governing these items. Ensuing traceability of these products can 32
1 literally mean the difference between supporting terrorist groups or supporting

2 those who need good jobs to provide for their family. "
3 2. Mandated Constraints
4 • The data will follow the GS1 EPCIS standards 2 and specifications for data
5 formatting, as possible.
6 • The product shall have well defined APIs that allow for incoming and outgoing
7 data to circulate between the ledger and external systems, namely ERPs.
8 • Any software frameworks used will be open source. This project will use Hyper-
9 ledger Fabric and Hyperledger Composer.
10 • A company/trading partner wishing to join the supply chain’s blockchain ledger

11 must comply with the GS1 standards, namely by having a globally recognized
12 identification (GS1 Company Prefix) and the company’s locations must also be
13 globally and uniquely identified.
14 3. Project Issues
15 1. Open Issues
16 The architecture of Hyperledger Fabric and Composer are complex and not
17 completely studied yet, which may lead to deviations from the requirements or
18 alterations at some point.
19 Again, these softwares are open source, constantly evolving, and Composer is
20 still in the Incubation phase, so it is not a complete product that can be relied
21 upon for everything. In this case, it is a PoC, so a risk is being taken.
22 2. New Problems
23 User Problems:
24 3. For a new company that is trying to use the product, they have to take the time
25 to understand the API and develop their own oracle to synchronize all the data.
26 Limitations in the Implementation Environment:
2 https://www.gs1.org/sites/default/files/docs/epc/EPCIS-Standard-1.2-r-
2016-09-29.pdf
design and implementation 91
4. It is not yet known how many companies this will be able to scale to, since it also 1
depends on how many nodes each of them run, and the quantity of data going 2
through the network at any given moment. 3
5. Costs 4
Maintaining the blockchain running requires little to no cost, as only a few dozen 5
nodes might be needed at most, depending on the scale, and each of them might 6
be operated by different companies. 7
The development itself and testing might run into cost troubles in the aspects 8
that require the simulation to be faithful to reality, such has having lots of servers 9
distributed geographically running at the same time (requiring expensive cloud 10
services, at times). 11
6.3 Design and Implementation 12
Although some projects build entire or partially custom blockchain network software, 13
using a framework like Hyperledger Composer is a much more streamlined way to 14
get a fast functioning prototype. 15
The baseline for the design will be the written list of requirements, mainly the 16
functional requirements part, and the specifications of the Hyperledger projects. 17
The design can be divided into 4 parts: 18
• Model Design for a Composer Business Network 19
• Access Control Design and Identity Management 20
• Network Topology and Deployment 21
• Integrating Existing Systems and Building External Applications 22
These parts are not necessarily sequential, but following the listed order may bring 23
about the best results in development. Since time was an issue and the dissertation 24
already included aspects other than the development, the scope of the development 25
itself could not be broad enough to include a deep exploration of all the aspects listed. 26
Therefore, the project here presented focuses more on the quality and functional 27
aspects of applying blockchain to the supply chain, and not so much on the quantitative 28
part, which would include tests to the efficiency of the network (throughput, latency). 29
What this means is that the development had a bigger focus on the model design, 30
1 access control design,identity management and the implementation and validation of

2 these aspects than on building and testing a realistic node topology. The scope for
3 the last item, integrating existing systems and building external applications,was also
4 narrowed down to the essential.
5 This section is divided in several parts to explain in which way these items were
6 approached, so that conclusions can then be taken to reach an answer to the question:
7 "Is it possible to build a feasible architectural design, by using such a tool, to
8 implement all these requirements?"
9 6.3.1 Composer Business Network - Model Design

10 From the requirements, the business network model for Hyperledger Composer was
11 designed and built. This includes the specifications for the .cto file, with the definitions
12 of all class types participants, assets, transactions and events, as well as the enums
13 and concepts (which are basically non-instantiable data types). The script file with the
14 implementation of the transactional code and a query file with custom queries for the
15 blockchain are also explained.
16 Only the most important data attributes for the classes will be explained, even
17 though all of the data attributes from all the classes can be seen on the class diagram
18 exhibited in the annexes.
19 Participants
20 The first step towards designing the system was to define who the users are, in order
21 to model the participants. This is an easy task, as the actors of the system were already
22 defined beforehand.
23 The logical separation for the participant type:
24 • auditor - the participant type that will represent the auditor role; the reason a
25 specific participant type is needed for this actor is so that the access control for
26 the auditors can later be specified;
27 • supplyChainMember - the main participant of the network, the supply chain

28 members are the actual users that will be interacting with each other, so it makes
29 sense that they are modeled; Sub-types were also designed, having in mind that
30 they may exhibit different behaviours, and different access rules can be written
31 based on the sub-type;
– Supplier 1
– Manufacturer 2
– Distributor 3
– Retailer 4
– Customer 5
Both the auditor and the supply chain member participant types have as attributes 6
some company and personal identification, and the supply chain members also have 7
an account balance, which is the basis for financial transactions. The reason the admin 8
does not appear here is that the admin of a business network does not need a user 9
type to be able to invoke transactions. Instead, they only need their admin identity 10
card, which in no way needs to be tied to a network participant. 11
Assets 12
Another integral component of the system are the assets, for the asset management 13
aspect of the supply chain. If traceability of products is to be achieved, these products 14
need to be modeled as assets, so that the network can register which ones exist, their 15
status, and any changes that happen. 16
The proposed assets in this model were: Commodity, ShipmentBatch and Con- 17
tract. Each of them serves a purpose. A diagram with the assets and their relationships 18
to the participants and each other can be found in Figure 6.1. 19
Commodity - Represents a single product being exchanged, with all its attributes, 20
including the product ID (GTIN), name, description, item status and even the ID of 21
the person who owns it (a participant of the network). 22
ShipmentBatch - Represents a physical shipment, that a buyer orders from a seller. 23
The shipment includes all the tracking information, including tracking number,a ship- 24
ment status and location. Additionally, the shipment has an array of the Commodity 25
items included in it, as well as information on who is the current physical holder of 26
the shipment and owner (other participants). When a shipment is created, since it has 27
an origin and a destination along with other sensible data and shipment conditions, it 28
makes sense that a contract is generated, therefore the shipment also has a contract 29
associated. 30
OrderContract - This represents a digital contract for the conditions of the shipment. 31
The expected arrival location and time, the buyer and seller, as well as a payment price, 32
for when the shipment is delivered (though it is optional). One of the requirements was 33
1 that contractual agreements should be made possible, as well as financial transactions,

2 and this is the proposed way to make it happen. Fraud checks can also be done on the
3 arrival location, to check if the real arrival location matches the expected one.
Figure 6.1: Class Diagram for the relationships between assets and participants.
4 Transactions and Transactional Scripts
5 The way that the participants an interact with the network and with the assets is
6 through transactions. Transactions are the chaincode functions with certain parame-
7 ters invoked by a user of the network (how a user can invoke a transaction is another
8 matter, also discussed in the following sections). So, while the participants and assets
9 model the users and data storage of the system, the transactions model the behaviour
10 of the network, by accessing the participant and asset registries and making changes.
11 Any transaction invocation is always recorded in an immutable historical record.
12 All the creation, deletion and update transactions are already supported by default
13 by Composer, but all other behaviour needs to be modeled, and sometimes, even these
default transactions should be made restricted and replaced by custom made ones, to 1
ensure system integrity. 2
The transactions that were modeled for this network, are featured in the following 3
list, with their descriptions: 4
• CreateShipmentAndContract - creates a shipment and the associated contract 5
at the same time, for a certain set of parameters, which includes a buyer, seller, 6
the commodities to include in the shipment, etc. 7
• UpdateShipment - update a shipment’s tracking status, location and optionally 8
pass it over to a new holder. In case the shipment is being delivered to the buyer, 9
if a payment was established in the contract, it is automatically done. Emits 10
a "possible fraud" event when a shipment does not arrive on the expected 11
location, and a normal event warning that the shipment was updated as well. 12
• UpdateCommodity - A custom transaction to update a commodity, instead of 13
using the default one. The reason is to make access control rules easier for this 14
behaviour easier. 15
• DeleteCommodity - Again, a custom transaction, to delete a commodity. The 16
reason for this transaction being custom is that a verification must be done to 17
check if the commodity is part of a shipment before deleting it. In case it is, to 18
maintain the integrity of the system, the commodity is not deleted 19
• ReportDamagedGood - Sometimes, goods are damaged during their shipment. 20
This transaction updates the current status of a commodity and a description of 21
the occurrence, so that a registry for any damages occurred can be 22
• TransformCommodities - This transaction converts 1 or more commodities in a 23
different set of commodities, by deleting the old ones and creating new ones. It 24
is useful, for instance, when creating a product out of raw materials. Emits an 25
event warning that the products were transformed. 26
• TransferCommodityPossession - transfer the ownership of a commodity to a 27
different participant of the network, but only if the commodity is not currently 28
part of any shipment. Emits an event warning about the change of ownership. 29
• TemperatureReading - Finally, and to ensure full product condition traceability, 30
temperature readings can be inserted into the system. A shipment can log an 31
1 array of temperature readings, and each time this transaction is called for a
2 shipment, a reading can be inserted into the array.
3 Additionally, the transactions, with all their parameters can be seen in Figure B.1,
4 from appendix B.
5 Queries
6 The transactions are used to model actions and behaviour, but to retrieve some of
7 the information, something else is needed. Composer already retrieves the basic
8 information for participants, assets and transactions, but anything else requires
9 queries. Hyperledger Fabric uses a relational database to store the asset and participant
10 registries and Composer features a way to retrieve that data easily, through filtered
11 queries (using a javascript framework, LoopBack).
12 In this proof of concept, some queries were programmed for some of the most
13 important pieces of information that can ensure traceability and other properties. These
14 can be found in table 6.2.
Table 6.2: List of designed and implemented queries, with their parameters.
ID Name Retrieve Parameters

1 selectShipmentByID ShipmentBatch Shipment ID
2 selectShipmentByOwner ShipmentBatch[] Shipment Owner
3 selectShipmentByHolder ShipmentBatch[] Shipment Holder
4 selectShipmentByCountry ShipmentBatch[] Location Country
5 selectShipmentByTrackingcode ShipmentBatch Tracking Number
6 getHistorianRecords Transaction[] None
7 getHistorianByPerson Transaction[] Participant
8 getHistorianByType Transaction[] Transaction Type
9 getDamagedGoodsTransaction Transaction[] None
10 getCreatedShipmentsTransactions Transaction[] None
11 getCommoditiesTransformations Transaction[] None
12 getCommodityOwner Commodity GTIN
13 getShipmentWhereCommodityExists ShipmentBatch Commodity
15 The queries are pretty straight forward to code. They are a basic SELECT type of
16 query, with the specification of what object we want to select, followed by a WHERE
17 kind of statement, where certain conditions like equality, inequality, "CONTAINS"
18 among a few others can be used.
19 For instance, query number 12, getCommodityOwner, takes as parameter the Com-
20 modity’s ID (GTIN), but instead of retrieving the owner of the commodity, a participant,
it returns the Commodity itself. Why? Because the commodity retrieved has all the 1
information of who the owner is. This information has to be extracted manually since 2
it is impossible to make a query to select only that attribute. 3
Query Difficulties 4
Though the ease of coding the queries is appreciated, they are pretty limited in what 5
they can do. For instance, it is impossible to natively nest a "SELECT" inside another. 6
Since the database behind is not relational, there are also no powerful query elements 7
like "JOIN", which makes for getting some pieces of information very hard or even 8
impossible. 9
To make up for this, some changes in the model had to be made. Originally, the 10
Commodity asset did not have a Owner data attribute, since it was not thought to 11
be needed. A ShipmentBatch has a Owner, and a list of Commodities. Therefore, if a 12
relational database were used, by providing the ID of a Commodity as parameter, it 13
would be possible to retrieve the Owner, simply by joining the tables for the shipment, 14
participant and commodity using the given ID, and it would return the owner. In a 15
relational database, any relation points both ways, so it is easy to navigate between the 16
classes of a model, but that does not happen here. 17
Figure 6.2: Exemplification of the non-relational model problem in the Hyperledger Projects.
Figure 6.2 illustrates the problem anc changes to the developed model that had to 18
be made to adapt to it. The Commodity was adapted to have a Owner data attribute so 19
that it is easier to query the owner of a commodity. This pretty simple query would be 20
a lot harder to accomplish in Composer, and anything more complex or having more 21
tables than this would be pretty much impossible to do without exporting all the data 22
to another system that could organize it and query it in a different way. 23

1 Another problem that this can bring, other than having the trouble of changing
2 the model, is the integrity issues that can be caused in the data. Anytime that the
3 owner of a shipment is changed, the owner of the commodity also has to be changed
4 in the code. If the owner of a commodity was not changed in the code, then it would
5 be inconsistent with the owner of the shipment, who in reality should also own the
6 commodity. If a programmer consistently adds attributes to classes to make up for
7 the weak Composer queries, eventually they might forget to make a change similar
8 to this one and the system might lose integrity.
9 6.3.2 Composer Business Network - Identity Management and Ac-

10 cess Control
11 Creating a model design for the network with all the previously explained items grants
12 the needed basic functionalities for the system to work, but it misses one of the most
13 important aspects from the requirements: the security and access control.
14 As previously explained in Section 2.4.3, Composer features the concept of Partici-
15 pant, a network instance of the class that represents a user, but it also features identity
16 cards, which are files that function as the private key and identification card for a real
17 person. An identity card and an instance of a participant can be linked to each other.
18 The control rules are written to reflect what actions are allowed to certain participant
19 class types, to specific participant instances, and even to specific identity cards.
20 A set of access control rules was designed with the requirements in mind, so that
21 only certain people can access certain sensible pieces of information, and so that not
22 everyone can manage other people’s data.
23 All of these rules were implemented in a mixture of two methods. The first is by
24 using the access control composer language and .acl file. The second is to program
25 the transactional scripts to check the identity and data of the person invoking the
26 transaction and then throw errors if the invoker should not have access.
27 The designed permissions are sectioned by items, namely the transactional data
28 and invocations, the asset data and its CRUD actions and the participant data and
29 its CRUD actions. The following list features a series of these items, with their name,
30 action and access control rule. The admin identity card is has full access, so it will be
31 mostly omitted from these rules.
32 Permissions and access control rules:
33 Transactions - Invoke
• CreateShipmentAndContract - Allowed for every participant and identity, exclud- 1
ing the customer participant types; 2
• ReportDamagedGood - Allowed only for the holder of a shipment with the 3
specified commodity; 4
• TemperatureReading - Allowed only for the holder of the shipment with the 5
temperature being read; 6
• TransferCommodityPossession - Allowed only for the owner of the commodity. 7
• TransformCommodities - Allowed only for the owner of all the commodities that 8
are input arguments. 9
• UpdateShipment - Allowed only for the holder of a shipment; 10
• UpdateCommodity - Allowed only for the owner of a commodity; 11
• DeleteCommodity - Allowed only for the owner of a commodity; 12
Assets 13
• Commodity 14
– Create - Allowed for supply chain member participant type; 15
– Read - Allowed for supply chain member participant type who owns the 16
commodity being read; allowed for the auditor participant type; 17
– Update - Allowed for supply chain member participant type who owns the 18
commodity being Updated; 19
– Delete - Admin only; 20
• OrderContract 21
– Create, Update, Delete - Admin only; 22
– Read - Allowed for the buyer and seller of the contract; allowed for the 23
auditor participant type; 24
• ShipmentBatch 25
– Create, Update, Delete - Admin only; 26
– Read - Allowed for the owner and holder of a shipment, as well as the buyer 27
in the shipment’s contract; allowed for the auditor participant type; 28

1 Participants
2 • Supply Members
3 – Create, Update, Delete - Admin only;

4 – Read - Allowed for the auditor participant type; allowed for a participant’s
5 own details;
6 • Auditor
7 – Create, Update, Delete - Admin only;

8 – Read - Auditor can read own details;
9 So, these rules reflect some basic facts. Auditors can read anything in the network,
10 while admins can read, update, delete, create or invoke anything. The common users
11 are subject to reading only details from themselves and the assets they are associated
12 to in some way (buyer, owner, holder, etc). In the same way, they are also limited on
13 the transactions they can invoke based on these associations.
14 Finally, the CRUD actions that the supply chain members can execute for the assets
15 and participants are also pretty limited, in order to maintain system integrity. This
16 was essential since Composer does not, by default, make some essential integrity
17 checks on the CRUD actions. For instance, when updating an asset’s reference to
18 another asset, Composer does not verify if the new reference actually points to an
19 existing instance of an object, which is the reason for why some custom transactions
20 were designed, such as UpdateCommodity.
21 Though all of these access rules were designed, not all were implemented in time,
22 but the ones that were implemented were tested and worked flawlessly.
23 Conclusions and Security Concerns
24 In an ending note, identity management is a complex thing in the Composer framework,

25 not only because of the rule design, but also because of how it can be bypassed by
26 human error and social engineering. Nothing, but the immutability of the ledger
27 records, is granted, especially when there is an admin that can control the system.
28 Additionally, some transaction invocations would be more secure if they could
29 have a multiple signature from many parties. One such transaction could be the
30 UpdateShipment transaction. when an item is being delivered to its buyer, it should be
31 made sure that the transaction was acknowledged by both parties, so that the payment
could be confirmed securely. Such a thing is not yet permitted by this framework and 1
constitutes a grave security fault, therefore not satisfying the security requirements 2
completely. 3
6.3.3 Network Topology and Deployment 4
Composer also features network topology design, which includes choosing the organi- 5
zations running the network, how many nodes each organization hosts and what types 6
of nodes and the endorsement policy. This is especially useful to quantitatively test the 7
efficiency metrics and scaling of the system, depending on the topological setup. Such 8
measurements are important to compare this system with other possible architectures. 9
However, the scope of this project covers mostly the qualitative and functional 10
part of building the network, with the aim of finding out if the requirements can 11
successfully be implemented and work as intended, independently of how the network 12
scales and independently of how other architectures behave. Especially in the case of 13
Hyperledger Composer, the implementation so far works, either with just 1 node,nd, 14
even though there was no implementation of a big topological network of nodes, some 15
speculation or with a small number of them. 16
With that in mi and thought were given as to how a proper network should look 17
like. Figure 6.3, taken from the Fabric documentation, exemplifies how a small supply 18
chain topology would be organized. 19
Figure 6.3: Example fabric topology for 3 organizations. Adapted from [18]
1 6.3.4 Integrating Existing Systems and Building External Applica-

2 tions
3 The synchronization requirements were another strong focus points, an issue that
4 deals a lot with building points of access for several external applications to use while
5 importing, exporting data and interacting with the blockchain.
6 Architectural Context Considerations
7 An important task of architectural design is identifying where blockchain is in the

8 middle of everything. It was already laid out that it can be used by other applications
9 as the source of truth. Architecturally, this may mean that blockchain might be used
10 as the lowest layer of a network, and that it can even be the support for more than 1
11 network.
12 All the other data layers would get the information from the blockchain, and inject
13 their information to the blockchain, when needed. The upper layers could organize
14 and treat information however they want, as long as they could retrieve it securely. This
15 way, it would even be possible to make up for the shortcomings of the query language
16 of Composer, by retrieving the Blockchain data to a higher level layer application and
17 have that application organize the data in a way that would make it more accessible.
18 Of course, building these upper layers is all up to the developers of each company and
19 application that wants to interact with the blockchain.
20 Figure 6.4 shows an idealization of what such an architectural layer design would
21 look like. From oracles extracting and inserting big chunks of data periodically, to
22 applications using the blockchain directly as their data storage source, the possibilities
23 for the layers above the blockchain network are many, and not even limited to what
24 can be seen in the figure.
25 The integration part of this project deals with defining secure and authenticated
26 points of access for the upper layers to have access to.
27 REST Server API and Authentication
28 Composer already features a ready-to-start API server, which includes all the transac-
29 tion invocations, queries and CRUD operations. Authentication, using identity card
30 files, is also included in the REST server’s functionalities.
31 It is also possible to write a custom REST server for composer, using Angular
32 applications, but the default server has the necessary features.
results and validation 103
Figure 6.4: Architectural layer representation of Blockchain Integration with other systems.
Other Applications 1
Other software are possible to be implemented with the blockchain. One such instance 2
of a software is Node-RED, to connect the blockchain to an IoT network of devices, 3
especially important in case we want to achieve traceability of product conditions or 4
quickly scan products. It can also be used to subscribe to network events. 5
6.4 Results and Validation 6
6.4.1 Requirements Validation 7
In order to determine the answer to the third and last of the problem statement 8
questions, "Is it possible to build a feasible architectural design, by using such a tool, to 9
implement all these requirements?", the suggested design and its implementation have to 10
be evaluated in an objective way. 11
The proposed methodology is to validate both the functional and non-functional 12
requirements from the specification. 13
As for the functional requirements, it needs to be ascertained which ones were 14
possible to implement, which ones were not, which ones were indeterminate (as in, 15
the development was not finished in time to come to a conclusion as to whether they 16
1 were possible) and which ones are only possible partially.

2 As for the non-functional requirements, a few comments will be made regarding
3 how each point was approached and whether it was fully satisfied, partially satisfied
4 or not satisfied at all.
5 Functional Requirements Validation
6 As can be seen in Table 6.3, a few of the functionalities are either not possible, or
7 only in a limited way.
Table 6.3: Validation of the functional requirements, according to the possibility of their imple-
mentation.
S1 Allow chaincode transactions Possible SCM10 Query specific shipment Possible

S2 Record all user actions Possible SCM11 Query shipment owned by a user Possible
Maintain immutable list of
S3 Possible SCM12 Query an asset’s owner Possible
transactions in blocks
Check shipment status, location,
S4 Submit transaction batches Not Possible SCM13 Possible
and all of the item’s status
S5 Assign timestamp to transaction Possible SCM14 Submit item damage reports Possible
Have multiple ledger/channels for Update a shipment with a new status
S6 Not Possible SCM15 Possible
Composer and location
S7 Emit notification events Possible SCM16 Edit own identity Possible
S8 Detect fraud mismatches Possible SCM17 Input an XML file to submit data Partially
Hold a cryptocurrency or enforced
S9 Define different permissions Possible SCM18 balance with equivalence to real Partially
currency
S10 Expose REST API Possible RE1 Query all the steps of a product’s life Partially
S11 Enable REST Authentication Possible RE2 Query every system registry Possible
Revert transactions, by submitting an
SCM1 Invoke transactions Possible A1 Not Possible
opposite transaction
Read assets, participants,
SCM2 Possible A2 Create and delete new ledger channels Partially
transactions, according to permissions
Write and deploy contractual
SCM3 Partially A3 Create network identity cards Possible
agreements
Assign identity cards to participant
SCM4 Query all the steps of a product’s life Partially A4 Possible
instances
Update details of participants,
SCM5 Query owner of an asset Possible A5 Possible
inc/ balance
SCM6 Create new assets Possible A6 Create, edit, delete any asset Possible
Submit any existing type of
SCM7 Edit and delete owned assets Possible A7 Possible
transaction
SCM8 Create shipment with owned assets Possible A8 Change a user’s role Possible
Attach contractual agreement Give other users permission to
SCM9 Possible A9 Possible
to shipment edit roles
8 There were 3 requirements not possible to implement, all due to limitations of the
9 framework: submitting transaction batches, using multiple ledgers on composer and
10 reverting a transaction’s effect.
11 • S4 - Transaction batches would have to be implemented on the client side

12 of any application that wants to communicate with the blockchain, and even
13 then, it could only "simulate" this feature, because it would have to submit the
14 transactions one by one, and they might not all get submitted in the same block,
15 which can be problematic.
• S6 - Multiple channels are still not available on Composer, making the creation 1
of multiple channels for groups of organizations impossible for this framework. 2
• A1 - Reverting a transaction’s effect is not possible, because it is not possible to 3
programmatically in the script file, using the Composer runtime API, to access 4
the contents of a previously submitted transaction. Composer only makes this 5
content accessible to the Client API to be used by other applications. 6
The partial requirements mean that part of the requirement was possible, or the 7
requirement was somehow simulated in a different way than the one written in the 8
specification. 9
• SCM3 - Deploying contractual agreements is only possible according to the 10
contract format specified in the design. This means that custom contracts can not 11
be submitted. Smart contracts are also limited to the ones already deployed on 12
the network, and only the admins can update the network with new contracts. 13
• SCM4 and RE1 - Querying a product’s lifecycle steps is possible for commodi- 14
ties that have not gone through transformations, by simply querying all trans- 15
actions associated with that commodity. However, when a commodity is trans- 16
formed, it basically is deleted and new ones are created and there is no way, with 17
the current Composer queries, to retrieve all of the transactions associated with 18
all the products, from before and after the transformation. 19
• SCM18 - Holding a cryptocurrency is simulated here by the balance, reason 20
why it is only partially implemented. It still has the same usability a real 21
cryptocurrency would have, since the balance can not be double spent because 22
of the consensus, but it has limited interchangeability with other currencies and 23
there are little management functions for the balance. 24
• A2 - Create and delete new ledger channels is possible in Fabric, though not in 25
Composer. In theory, an admin can create a channel for Hyperledger Fabric, but 26
it will not be usable by Composer. 27
Non-Functional Requirements Validation 28
The validation and analysis of the satisfaction of the quality requirements is pre- 29
sented in Table 6.4. 30
By joining the conclusions reached in both the functional and non-functional 31
requirements, there is a better understanding towards validating the requirements 32

Table 6.4: Validation of the non-functional or quality requirements.
The APIs are pretty straightforward to use. It is divided in

assets API calls, participant calls, transaction calls and query
Usability Satisfied
calls. It should be possible to develop oracles and software
integration modules with relative ease.
Though not formally tested, the speed of the system was
informally asserted from the software tests performed.
Speed and Composer seems to consistently slow down the speed
Not totally satisfied
Latency of the system and have a higher latency when compared
to the standalone use of Hyperledger Fabric (based on the
metrics analysed in the background)
Precision and All data entries are accurate, and there is some degree of fraud
Satisfied
Accuracy detection/user mistake detection.
These factors work as expected. The more nodes, the better the
Reliability and
reliability, but, depending on the endorsement policy, some Partially satisfied
availability
transactions might not go through when specific nodes are down.
Performance
Technically, it is possible to scale the product to the levels of
Scalability hundreds of companies, though the performance suffers a Satisfied
degradation.
Hardware It is easy to add new nodes and edit the configuration. Satisfied
Maintainability Limited maintainability, since the new versions of a business
and Portability Software network have to be compatible with the previous ones, and for this, Partially satisfied
some parts of the design can not be removed.
Privacy The access control rules ensure privacy. Satisfied
Immutability The implemented blockchain designed is fully immutable. Satisfied
Security
Some actions should require permission from more than 1 user,
Authorization Partially satisfied
which does not happen.
The new global data protection regulations (GDPR) put the legality
of blockchain into question. Supposedly, GDPR argues that any
Legal Not totally satisfied
data containing personal information must be removable. This rule
is, however, incompatible with the immutability requirement.
1 from the survey and also reaching a final conclusion for the last questions. The
2 validation of the survey requirements is shown in Table 6.5.
3 As can be seen, most of the requirements were fulfilled, but not all of them totally.
4 Security, as could be seen in the functional and non-functional requirements, has
5 some faults.
6 Regulatory auditing is also limited, because of the commodity transformations,
7 which limit the scope of how far we can trace back a product.
8 The development of industry standards is done by organizations such as GS1,
9 which are actively working to ensure that the standards they develop are adopted
10 world-wide.
11 Financial transactions were developed, but not fully to a level that can be used
12 industrially, so there is a lot of work to do on that field.
13 Enforceable contracts, as explained, are also limited to the designed contracts, and
14 the deployment of new or custom contracts is limited.
15 6.4.2 Development Limitations

16 In retrospective, the chosen framework had a big impact in the implementation of the
17 requirements. Some were made easier, but others were harder or even impossible, due
Table 6.5: Validation of the survey elicited requirements.
Security according to the latest requirements Limited

Security Controlled access for the users Satisfied
Secure data storage Satisfied
Regulatory auditing Limited
Fraud detection Satisfied
Traceability
Asset management Satisfied
Real-time tracking information Satisfied
Interoperability between systems Satisfied
Development of industry standards Limited
Synchronization
Real-time sharing of information with partners,
Non-applicable
leading to better working relationships
Transaction Financial transactions Limited
Enforcement and Enforceable contracts (smart contract Limited
Financial domain functionality)
to limitations in the software, and not due to the design. 1
Some of the Composer framework limitations found that impacted the development 2
of this proof of concept: 3
• Queries are not powerful enough. There is no JOIN and the usual SQL syntax is 4
not always applicable. There is also no WHERE . . . IN . . . , for instance. Model 5
changes had to be made to adapt to this, and integrity might be lost. 6
• The default Composer REST server is somewhat limited in its API. To extend 7
the API, a custom server needs to be written; The queries and use of LoopBack 8
filters is also limited on the default server, but can be more extensively used by 9
building a custom server. 10
• It is impossible to natively nest queries with the query language. To make up for 11
this, several independent queries sometimes need to be executed, which is very 12
inefficient. 13
• Some queries are bugged on features like LIMIT. 14
• The run-time API does not have methods to access transactions, so that past 15
transactions from the registry can be interacted with in the script file. 16
• Some access control rules might be impossible to apply to certain queries. 17
• The framework is still in development and has some bugs. For instance, LIMIT 18
in queries is bugged and does not work. Sometimes, when an asset is deleted, 19
1 a new asset with the same ID as the previous can not be created, because the
2 system thinks the previous asset still exists.
3 • Organizations are not supported in Composer in the same way they are in Fabric.
4 • Composer somewhat lacks integrity checks when references to instances of other

5 objects are used.
6 6.5 Conclusions
7 The whole chapter focused on building a list of requirements, designing a system,
8 implementing it and validating the work done. All to answer the question: "Is it
9 possible to build a feasible architectural design, by using such a tool, to implement all these
10 requirements?".
11 Thus, the final results and validation are essential to the answer and they are the
12 ultimate goals, but the whole process of getting there by building the requirements,
13 the design, and the implementation also provides important contributions.
14 Through the analysis of the results, the direct answer to the posed questions is:
15 No. It is not possible to use the Hyperledger Composer and Fabric frameworks to
16 satisfy ALL of the requirements through the built design, mainly because of limitations
17 in the software, and not because of the architectural design itself.
18 Even though the answer to the posed question was negative based on the results
19 from this dissertation, the fact remains that it was still possible to implement most
20 of the requirements. Therefore, if the question is instead changed to "Is it possible
21 to build a feasible architectural design, by using such a tool, to implement MOST of these
22 requirements?", the answer turns into a YES.
23 The design itself is feasible to be implemented, and even though the tool has some
24 limitations, most of the functionalities and quality requirements were indeed satisfied.
25 Both the design and the tool are not without some merit and it would not be fair to
26 simply say that such an architectural design, based on Blockchain, is not feasible or
27 usable simply because it does not satisfy an extensive list of requirements.
Chapter 7 1
Conclusions 2
The work done so far can be aggregated to reach some conclusions. This chap- 3
ter summarizes these conclusions to reach a final conclusion in the overview. The 4
difficulties that molded the trajectory of this dissertation are alo described. 5
Finally, this chapter features important content in the form of a list of contributions 6
of this dissertation, which interlace with the possible future work. More research can 7
be done in this area and hopefully some of it based on the findings from this thesis. 8
7.1 Overview 9
All the work and contributions of this dissertation aim towards proving whether the 10
following statement, introduced in chapter 4 is valid or not: "Blockchain is a good 11
architectural design for the Supply Chain Management domain". 12
For this reason, 3 questions were formulated in the problem statement: 13
1. What supply chain issues, improvements and requirements do the experts 14
really find the most important? 15
2. What is the Blockchain tool or framework most adequate to the development 16
of an architecture that can support these requirements? 17
3. Is it possible to build a feasible architectural design, by using such a tool, to 18
implement all these requirements? 19
Chapter 5 provided the answer to the first question. Chapter 6 used this answer to 20
provide the answer to the second and third questions, which can now lead to a final 21
conclusion towards the initial statement. 22

110 conclusions
1 Thesis Statement
2 We have almost all of the pieces to reach a final conclusion towards the main thesis
3 statement. However, there is still the need for the expression "a good architectural
4 design for the SCM domain" to be clarified. What exactly does it mean for an
5 architectural design to be good for some domain?
6 If we were to compare a new architectural design against other existing designs for
7 that same domain, then a system based on a new design could be considered good if
8 it could cover all of the functionalities of the other designs and have some additional
9 ones or be more efficient. But it was already determined that the focus of this thesis
10 statement was not to compare this architecture to others, but to evaluate it according
11 to the requirements. Therefore, a good design could be one that objectively covers all
12 of the most important elicited requirements.
13 The chosen framework had the possibility of satisfying the most requirements, out
14 of all the frameworks. Even so, by answering the last question, it was concluded that
15 the proposed design, even while choosing the most convenient tool possible, could
16 only fill the requirements partially.
17 Therefore, if a good design is one that must be able to satisfy all of the requirements, then it
18 is not certain that Blockchain is a good architecture for the supply chain management domain,
19 since not all of them were satisfied.
20 However, this does not mean Blockchain is not useful, since it can still partially
21 fill some important requirements. The fact that by itself, it might not be good
22 enough to satisfy all the requirements, does not mean it cannot be used together
23 with the current architectures to fill in some gaps. Blockchain can still be applied as
24 an aid and enhancement to some information system functionalities. For instance,
25 financial transactions was a requirement that was fulfilled and listed very high on the
26 requirements from the survey. No other present architecture uses this functionality,
27 but through Blockchain, it can be implemented.
28 7.2 Contributions
29 It is important that a conclusion was reached, but it is also important to look at the
30 work was done to reach that conclusion. The whole process of originating the answers
31 to the questions that support the conclusion also generated useful contributions.
32 These contributions might be useful for future research:
33 • Survey Research and Analysis of Expert Opinions

difficulties 111
– Validation by the experts of the most important supply chain issues, supply 1
chain points of improvement, information system features that a supply 2
chain needs and the most wanted blockchain use cases for supply chain 3
management 4
– List of requirements for a blockchain-based supply chain management 5
software, grouped by area 6
• Software Engineering Artifacts 7
– Framework Evaluation and Architectural design, including a Hyperledger 8
Composer model1 , a Prototype implementation and a validation of the 9
feasibility of the requirements 10
7.3 Difficulties 11
The work done in this research was not always linear, even though the logic is made to 12
be linear. Since the beginning of the research, questions arose as to what points should 13
be focused, what work would make the contributions important enough to reach a 14
good conclusion. 15
One of the initial difficulties that most impacted the research was the lack of a 16
quantitative baseline to compare the proposed design to. There are many other projects 17
that attempt to, in one way or another, enhance the capabilities of supply chain by 18
applying blockchain as an architecture, some even showcased in the literature review. 19
However, none had publicly available efficiency metrics that could be used for this 20
project to be compared to. Many developers and companies were contacted to try to 21
collect more data from the existing projects, to establish a baseline but the contacts did 22
not fall through in a satisfactory way. 23
In the same way, some supply chain companies were contacted to the purpose of 24
establishing a quantitative baseline for the needs of supply chain. This could have 25
included, for example, knowing how many products a company shipped per a certain 26
amount of time, since this data could lead to interesting conclusions. But none had the 27
specific data needed or the interest to maintain a continuous working relationship for 28
the purposes of this research. 29
1 The code developed for this model is open source, and can be found at https://github.com/
coletiv/supplychain-composer-thesis.
112 conclusions
1 Thus, one of the biggest difficulties for this dissertation was the lack of partnerships
2 and difficulty in establishing and maintaining contacts interested in contributing to
3 the research.
4 Another difficulty was that the frameworks used are not very mature. Some had
5 their development abandoned, while others are still in development, with unstable
6 code, and there are always new versions being released, which sometimes changed the
7 way the features worked.
8 Finally, without a comparison baseline, the survey was developed, as a way to get
9 expert knowledge in a more indirect way. But getting experts to answer the survey was
10 not easy. The expected profile for the participants of the survey was not a common
11 one, and the survey had to be shared through specific channels, often times having a
12 relatively low answer rate.
13 7.4 Future Work

14 The work here done was introductory in nature, and explored the requirements
15 and their satisfaction as a whole. Additionally, the maturity of the tools used was
16 questionable. This research can be used as the groundwork for more important
17 conclusions and contributions to be reached.
18 Future work might include:
19 • Gather requirements through other means, such as interviews and top-of-the-

20 market tools for supply chain management.
21 • Taking specific requirements from the most important requirements on the list
22 and research on using blockchain to successfully apply them as enhancements:
23 – Financial applications, payments and contractual agreements.

24 – "Applying Blockchain as a financial alternative in the Supply Chain", for
25 instance, can be a topic of research, among others.
26 • Research and attempt to use different frameworks to fulfill the same requirements
27 that were elicited in this dissertation.
28 • Build a more complete topological network for the proof of concept, thoroughly
29 analyze the performance and compare it to other systems and architectures,
30 including systems different from Blockchain.
Appendices 1
Appendix A 1
Statistical Analysis Methodology 2

116 statistical analysis methodology
Table A.1: Data analysis metrics used in the survey results analysis
Metrics Meaning
The mean represents the most probable value. In this
survey, with the use of scales with a lower and upper
bounds, the mean has the roles of representing the
average value of agreement, importance and other
measures.Normally, when the skewness of a distribution
Measures of Mean
is high, the meaning of the mean may get distorted by
Central Tendency
the existence of outlier values. However, since the scales
or Location
have a low range, with a lower and upper bound on the
answer values, this is not much of a concern. Therefore,
even in cases of skewness, the mean can be a useful metric.
Value of the 50% percentile, for numerical answers. Half
the answers are above this value and half are below,
pointing to a central tendency around this value. This is
Median a good metric to use, especially in skewed distributions
where there are outliers in the collected values, since the
meaning of the mean may get slightly distorted by the
outlier values.
Most frequent response. Though it represents the most
Mode popular answers, by itself the metric means nothing else,
as there might be answers almost as popular or not.
Quantifies the variation within the data set, by showing
how much the distribution spreads to either sides of the
center. A high value for the standard deviation means
Standard that there are a lot of values away from the mean, from
Measures of Spread,
Deviation which can be concluded that there is not a general
Scale or Dispersion
consensus on a certain answers.A low value means that
there is consensus, since all the values of the data set are
bundled more closely together.
Difference between highest and lowest value of the data set.
Together with the standard deviation, indicates the dispersion
of the value of the answers. A range of 0 means that a
Range question had the same value for all responses, for instance.
This metric ignores the frequency with which each answer
was given, that is why it must be coupled with the standard
deviation to be relevant.
This metric indicates the lack of symmetry in a distribution,
where the results bunch up in one side of the distribution.
Measures of
For instance, negative skewness values indicate a skew to
Skewness and Skew
the left: the values bunch up at the right end of the distribution
Kurtosis
and the left tail is long, indicating there are outliers in the lower
values.
Appendix B 1
Composer Model Class Diagram 2

118 composer model class diagram
Figure B.1: Full class diagram for the designed Hyperledger Composer model
References 1
[1] Ole Andersen and Louise Vogdrup-Schmidt. Rivals reject blockchain solution from Maersk and IBM, 2
2018. URL https://shippingwatch.com/carriers/Container/article10602520.ece. 3

Date Accessed: 2018-06-07. Cited on p. 40. 4
[2] A.P. MOLLER - MAERSK. Maersk and IBM Launch Digital Joint Venture, 2018. URL https://www. 5
maersk.com/stories/maersk-and-ibm-launch-digital-joint-venture. Date Ac- 6
cessed: 2018-02-08. Cited on p. 40. 7
[3] Ronald H. Ballou. The Evolution and Future of Logistics and Supply Chain Management. European 8
Business Review, 19(4):332–348, 2007. ISSN 0955-534X. doi: 10.1108/09555340710760152. URL 9
http://www.emeraldinsight.com/doi/10.1108/09555340710760152. Cited on p. 2. 10
[4] Dave Bayer, Stuart Haber, and W. Scott Stornetta. Improving the Efficiency and Reliability of 11
Digital Time-Stamping. Sequences II, pages 329–334, 1992. doi: 10.1007/978-1-4613-9323-8_24. URL 12
http://link.springer.com/10.1007/978-1-4613-9323-8{_}24. Cited on p. 4. 13
[5] Richard Gendal Brown, James Carlyle, Ian Grigg, and Mike Hearn. Corda: An Introduction. pages 1– 14
15, 2016. URL https://docs.corda.net/_static/corda-introductory-whitepaper. 15
pdf. Cited on p. 28. 16
[6] Vitalik Buterin. On Sharding Blockchains. URL https://github.com/ethereum/wiki/wiki/ 17

Sharding-FAQ. Date Accessed: 2018-02-07. Cited on p. 19. 18
[7] Vitalik Buterin. What Proof of Stake Is And Why It Matters, 08 2013. URL 19
https://bitcoinmagazine.com/articles/what-proof-of-stake-is-and-why- 20
it-matters-1377531463/. Date Accessed: 2018-03-20. Cited on p. 17. 21
[8] Vitalik Buterin. A Next-Generation Smart Contract and Decentralized Application Platform. 22
Ethereum White Paper, (January):1–36, 2014. URL https://github.com/ethereum/wiki/ 23
wiki/White-Paper. Cited on p. 16. 24
[9] Vitalik Buterin. On Public and Private Blockchains, 2015. URL https://blog.ethereum.org/ 25
2015/08/07/on-public-and-private-blockchains/. Date Accessed: 2018-03-20. Cited 26

on p. 13. 27
[10] Vitalik Buterin and Virgil Griffith. Casper the Friendly Finality Gadget. pages 1–10, 28
2017. URL https://github.com/ethereum/research/blob/master/papers/casper- 29
basics/casper_basics.pdf. Date Accessed: 2018-02-07. Cited on p. 17. 30
[11] Christian Cachin. Architecture of the Hyperledger Blockchain Fabric. IBM 31

Research, July, 2016. URL https://pdfs.semanticscholar.org/f852/ 32
c5f3fe649f8a17ded391df0796677a59927f.pdf. Cited on p. 22. 33
[12] CargoX. Reshaping the Future of Global Trade with World’s First Blockchain Bill of Lading, 2017. 34
URL https://cargox.io/CargoX-Whitepaper.pdf. Cited on p. 37. 35
120 REFERENCES
1 [13] Ram Ganeshan and Terry P Harrison. Introduction to Supply Chain Management. Supply Chain Man-
2 agement An International Journal, 47(July):3–4, 1995. ISSN 1745493X. doi: 10.1111/j.1745-493X.2011.
3 03231.x. URL http://lcm.csa.iisc.ernet.in/scm/supply_chain_intro.html. Cited
4 on p. 2.
5 [14] Stuart Haber and W Scott Stornetta. How to time-stamp a digital document. Journal of Cryptology,
6 3(2):99–111, jan 1991. ISSN 1432-1378. doi: 10.1007/BF00196791. URL https://doi.org/10.
7 1007/BF00196791. Cited on p. 4.
8 [15] Heiko Hees. What is the Raiden Network? URL https://raiden.network/101.html.

9 Date Accessed: 2018-02-07. Cited on p. 20.
10 [16] Juan Huertas, Hope Liu, and Sarah Robinson. Eximchain: Supply Chain Finance Solutions on a
11 Secured Public, Permissioned Blockchain Hybrid, 2017. URL https://www.eximchain.com/
12 EXIMCHAIN-Whitepaper.pdf. Cited on p. 38.
13 [17] IBM Research. Hyperledger Fabric Architecture Explained, . URL http://hyperledger-

14 fabric.readthedocs.io/en/release-1.1/arch-deep-dive.html. Date Accessed: 2018-
15 06-26. Cited on p. 22.
16 [18] IBM Research. Hyperledger Fabric Peers Explained, . URL http://hyperledger-fabric.

17 readthedocs.io/en/release-1.1/peers/peers.html. Date Accessed: 2018-06-27. Cited
18 on p. 101.
19 [19] IBM Research. Hyperledger Fabric Documentation. page 257, 2017. doi: 10.5281/zenodo.
20 1009257. URL https://media.readthedocs.org/pdf/hyperledger-fabric/latest/
21 hyperledger-fabric.pdf. Cited on pp. 22 and 24.
22 [20] International Training Centre of the International Labour Organization. Understanding

23 global supply chains, 2018. URL https://gbv.itcilo.org/index.php/briefing/
24 show{_}paragraph/id/127.html. Date Accessed: 2018-06-27. Cited on p. 2.
25 [21] Filiz Isik. Complexity in Supply Chains : A New Approach to Quantitative Measurement of the
26 Supply-Chain-Complexity. Supply Chain Management, pages 417—-432, 2011. Cited on p. 4.
27 [22] Kari Korpela, Jukka Hallikas, and Tomi Dahlberg. Digital Supply Chain Transformation toward
28 Blockchain Integration. pages 4182–4191, 2017. doi: 10.24251/HICSS.2017.506. URL http:
29 //hdl.handle.net/10125/41666. Cited on p. 3.
30 [23] Leslie Lamport, Robert Shostak, and Marshall Pease. The Byzantine Generals Prob-
31 lem. ACM Transactions on Programming Languages and Systems, 4/3:382–401, July
32 1982. URL https://www.microsoft.com/en-us/research/publication/byzantine-
33 generals-problem/. Cited on p. 9.
34 [24] Linux Foundation. [email protected], 2018. URL https://hyperledger.

35 github.io/composer/latest/introduction/introduction.html. Date Accessed: 2018-
36 05-20. Cited on p. 25.
37 [25] Rhonda R Lummus and Robert J Vokurka. Defining Supply Chain Management: a Historical
38 Perspective and Practical Guidelines. Industrial Management & Data Systems, 99(1):11 – 17, 2014.
39 ISSN 10983015. doi: 10.1108/02635579910243851. Cited on pp. 1 and 2.
40 [26] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. Www.Bitcoin.Org, page 9, 2008.
41 ISSN 09254560. doi: 10.1007/s10838-008-9062-0. URL https://bitcoin.org/bitcoin.pdf.
42 Cited on p. 4.
REFERENCES 121
[27] Photis M. Panayides and Y. H. Venus Lun. The Impact of Trust on Innovativeness and Supply 1
Chain Performance. International Journal of Production Economics, 122(1):35–46, 2009. ISSN 09255273. 2
doi: 10.1016/j.ijpe.2008.12.025. URL http://dx.doi.org/10.1016/j.ijpe.2008.12.025. 3
Cited on p. 34. 4
[28] Marc Pilkington. Blockchain Technology: Principles and Applications. Research Handbook on 5
Digital Transformations, pages 1–39, 2015. ISSN 1553-877X. doi: 10.4337/9781784717766.00019. URL 6
http://papers.ssrn.com/abstract=2662660. Cited on p. 10. 7
[29] Suporn Pongnumkul, Chaiyaphum Siripanpornchana, and Suttipong Thajchayapong. Performance 8

Analysis of Private Blockchain Platforms in Varying Workloads. 2017 26th International Conference 9
on Computer Communications and Networks, ICCCN 2017, 2017. doi: 10.1109/ICCCN.2017.8038517. 10
Cited on pp. 30 and 31. 11
[30] Joseph Poon and Vitalik Buterin. Plasma: Scalable Autonomous Smart Contracts Scalable Multi- 12
Party Computation. pages 1–47, 2017. URL https://plasma.io/plasma.pdf. Cited on 13
p. 20. 14
[31] Michael Prokle. Theory and Practice of Supply Chain Synchronization. Doctoral Dissertations, 2017. 15
Cited on p. 3. 16
[32] Alan Punter. Supply Chain Failures - A Study of the Nature, Causes and Complexity of Supply 17
Chain Disruptions. Airmic Technical, pages 1–52, 2013. Cited on p. 3. 18
[33] Branimir Rakic, Tomaz Levak, Ziga Drev, Sava Savic, and Aleksandar Veljkovic. OriginTrail: 19
First Purpose Built Protocol for Supply Chains Based on Blockchain, 2017. URL https:// 20
origintrail.io/storage/documents/OriginTrail-White-Paper.pdf. Cited on p. 39. 21
[34] Branimir Rakic, Tomaz Levak, Ziga Drev, Sava Savic, and Aleksandar Veljkovic. Technology @ 22
origintrail.io, 2018. URL https://origintrail.io/technology. Date Accessed: 2018-06-07. 23
Cited on p. 39. 24
[35] Mattias Scherer and Jerry Eriksson. Performance and Scalability of Blockchain Networks and 25
Smart Contracts. 2017. doi: UMEAUniversity. Cited on pp. 18 and 19. 26
[36] IEEE Computer Society. Ieee recommended practice for software requirements specifications. IEEE 27
Std 830-1998, pages 1–40, Oct 1998. doi: 10.1109/IEEESTD.1998.88286. Cited on p. 81. 28
[37] Nick Szabo. Smart Contracts: Building Blocks for Digital Markets. URL: 29
http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/ LOTwinter- 30
school2006/szabo.best.vwh.net/smart_contracts_2.html, 1996. Cited on p. 16. 31
[38] Hyperledger Composer Development Team. Introduction @ hyperledger.github.io, 32

2018. URL https://hyperledger.github.io/composer/latest/introduction/ 33
introduction.html. Date Accessed: 2018-05-31. Cited on p. 26. 34
[39] Martin Valenta and Philipp Sandner. Comparison of Ethereum, Hyperledger Fabric and 35
Corda. (June):1–8, 2017. URL http://explore-ip.com/2017_Comparison-of-Ethereum- 36
Hyperledger-Corda.pdf. Cited on p. 29. 37
[40] Marko Vukolić. Hyperledger Fabric - an Open-Source Distributed Operating System for 38
Permissioned Blockchains, 2017. URL https://blockchain-summer.epfl.ch/talks/ 39
hyperledger-fabric-vukolic.pdf. Cited on p. 22. 40
[41] Richard Wilding. The Supply Chain Complexity Triangle: Uncertainty Generation in the Supply 41
Chain. International Journal of Physical Distribution & Logistics Management, 28(8):599–616, 1998. ISSN 42
0960-0035. doi: 10.1108/09600039810247524. URL http://www.emeraldinsight.com/doi/ 43

10.1108/09600039810247524. Cited on p. 5. 44
122 REFERENCES
1 [42] Jeff Hoi Yan Yeung, Willem Selen, Min Zhang, and Baofeng Huo. The Effects of Trust and Coercive
2 Power on Supplier Integration. International Journal of Production Economics, 120(1):66–78, 2009.
3 ISSN 09255273. doi: 10.1016/j.ijpe.2008.07.014. URL http://dx.doi.org/10.1016/j.ijpe.
4 2008.07.014. Cited on p. 34.
REFERENCES 123

Thesis

Uploaded by

Copyright:

Available Formats

Thesis

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis

Uploaded by

Copyright:

Available Formats

UNIVERSITY OF PORTO • FACULTY OF ENGINEERING

Supply Chain Management with

Pedro Miguel Lourenço Costa

Filipe Alexandre Pais de Figueiredo Correia, Assistant Professor

In partial fulfillment of requirements for the degree of

Pedro Miguel Lourenço Costa

Rua Dr. Roberto Frias, s/n

Tel.: +351 968 203 386

Empresas de qualquer indústria trocam informação e recursos entre elas, criando um

No final, o sistema proposto foi analisado e comparado com os requisitos, para

3 Blockchain in the Industry 33

5 Supply Chain Issues Validation and Requirements Elicitation 51

5.3.4 Question Group 4 - Supply Chain Standalone Points of Improve-

6 Solution Design and Implementation 77

A Statistical Analysis Methodology 115

B Composer Model Class Diagram 117

1.1 Representation of a garment supply chain and all the relationships it

2.1 Representation of a blockchain’s structure . . . . . . . . . . . . . . . . . . 11

3.1 Overview of the OriginTrail network. . . . . . . . . . . . . . . . . . . . . 39

5.1 Questions about the respondent’s Role, Industry, Years of Experience

2.1 Comparison between different consensus mechanisms. . . . . . . . . . . 14

6.1 Summary of the framework requirements for each improvement area. . 79

for any industry, is in high demand. 12

1.1 Supply Chains 13

These entities can be identified as suppliers, carriers, manufacturing sites, distribution 19

integration and management processes win. 3

finances, growth and reputation of the companies involved [32]. 10

to briefly introduce some of the problems that affect them. 18

and information systems of a company [31]. 23

not, wasting time and resources. 30

15 1.3 From Blockchain Technologies to Supply Chains

specific problem well. 15

Requirements evolve, and so should the technology, in order to support them. 16

previous ones, or augment them. 18

The characteristics of blockchain architectures seem to be a good solution for 22

many of the identified problems in supply chain to be reduced or neutralized. These 23

incorruptible and immutable way to store information, with a fast synchronization 26

digital, leading to the possibility of a global overview. 29

12 1.6 Dissertation Structure

18 • Chapter 2, "Blockchain Technologies", some important concepts from the

21 • Chapter 3, "Blockchain in the Industry", the application of blockchain to supply

25 Part 2: Problem, Research and Solution - Provides a thorough explanation of the

• Chapter 5, "Supply Chain Issues Validation and Requirements Elicitation", fea- 1

for a supply chain system, so that a blockchain-based solution can be proposed. 3

• Chapter 6, "Solution Design and Implementation", features the choice of a 4

blockchain framework and the proposal of a solution, which consists in building 5

make a statement, also listing contributions, difficulties and future work. 9

• Chapter 7, "Conclusions", features an overview of the work done in the disserta- 10

tion, providing an answer to the previously defined problem, and following it up 11

with possibilities of future work in this area. 12

supply chain, by highlighting both the disadvantages and disadvantages, of blockchain 5

of blockchain with SCM. 7

“The Byzantine Generals’ Problem” is a classical problem faced by distributed systems, 9

state of the system is at any given time. 12

Nakamoto’s implementation of a blockchain seems to be, at present, the most 13

Internet-of-Things, health care, identity management, to name a few. 22

to store information, process information, process payments or provide services. The 24

3 2.2 Core Concepts and Features

Figure 2.1: Representation of a blockchain’s structure

have both a consensus algorithm and also a block validation algorithm. 19