A blockchain-based system for IoT-aided certification and traceability of EVOO

(1)

A blockchain-based system for

IoT-aided certification and traceability

of EVOO

Alessio Bianchini

Department of Information Engineering

University of Pisa

This dissertation is submitted for the degree of

Master of Science in Computer Engineering

Supervisors:

Prof. Gianluca Dini

(2)

Acknowledgements

Ai miei genitori,

per avermi supportato e sopportato fino a questa tappa della mia vita Ai miei amici,

per essere stati sempre al mio fianco Al professor Dini,

All’ingegner Perazzo, All’ingegner Arena,

per la loro immensa disponibilità durante l’intero lavoro di tesi Al professor Bechini,

Al professor Lettieri,

per avermi bastonato al primo esame, regalandomi nuove motivazioni e nuovi stimoli che mi hanno dato la giusta carica fino ad oggi

Alla città di Pisa,

(3)

Blockchain is one of the most emerging technologies of the last years. After its introduction, as the key technology behind Bitcoin electronic cash system, many other applications were developed exploiting the big advantages provided by this revolutionary technology. Building a blockchain-based application may involve big advantages from both technical and economical point of views, providing at the same time better security features, higher performances and less management costs. In this thesis, blockchain technology will be deeply explored in the context of a specific use case: the traceability and certification of Extra Virgin Olive Oil (EVOO). The goal is to create a real system based on this technology, taking a look at how blockchain can be integrated with other successful technologies like IoT, OAuth, Publish-Subscribe, Angular, etc.. The last contribution of this work is to provide a support for the correct dimensioning of the blockchain system, also proposing an innovative mechanism for real-time auto-tuning of parameters.

(4)

List of figures

1.1 Traceability and certification of EVOO . . . 2

2.2 Number of IoT devices over time (in billions) . . . 3

3.3 Different network topologies . . . 10

3.4 BC structure proposed for Bitcoin . . . 11

3.5 Hyperledger project . . . 12

3.6 Transaction flow overview . . . 16

4.7 Blockchain decision tree . . . 20

4.8 Olive oil production process flow diagram . . . 22

4.9 Olive oil production process . . . 24

4.10 Olive oil production process: an overview . . . 26

4.11 A malicious entity tries to impersonate someone else . . . 31

4.12 A malicious entity tries to modify its own data . . . 31

5.13 Business network architecture . . . 37

5.14 Business Network Archive creation . . . 49

5.15 Model class diagram . . . 51

5.16 Advantage in using Docker . . . 57

5.17 OAuth2 protocol flow [2] . . . 62

5.18 Exploiting multiple REST servers . . . 63

5.19 Raspberry Pi 3 Model B+ . . . 68

5.20 Project Architecture . . . 69

6.21 Simulation model . . . 72

6.22 Data analysis overview . . . 74

6.23 Delay evaluation (exponentially distributed arrivals): consensus execution time scenarios . . . 75

(8)

xii List of figures 6.25 Timer impact on delay: et = 200ms . . . 76 6.26 Delay evaluation (exponentially distributed arrivals): inter arrival times

scenarios . . . 77 6.27 Transactions delay without auto-adaptive mechanism . . . 80 6.28 Transactions delay with auto-adaptive mechanism under various parameters

(9)

List of tables

3.1 Comparison of consensus algorithms . . . 18

5.2 Assets Control Access Rules . . . 46

5.3 Transactions Control Access Rules . . . 47

5.4 Transactions Logic . . . 48

5.5 Raspberry Pi 3 Model B+ Specifications . . . 68

6.6 Parameters settings: auto-adaptation OFF (A) . . . 81

(10)

Nomenclature

Acronyms / Abbreviations ACL Access Control Language BC Blockchain

BNA Business Network Archive EVOO Extra Virgin Olive Oil

HCML Hyperledger Composer Modelling Language IoT Internet of Things

MSP Member Service Provider OFP Olive Farming Profile OHP Olive Harvesting Profile OOCP Olive Oil Conservation Profile OOPP Olive Oil Production Profile OOTP Olive Oil Transportation Profile

(11)

1. Introduction

Recently many new technologies were introduced, some of them are constantly growing over time whereas others are only at the beginning of their process of adoption. The goal of this thesis is to explore one of the most growing and promising technology of the last years: blockchain. Blockchain technology was first introduced by Satoshi Nakamoto as the main technology behind Bitcoin [4]. Blockchain became in few years one of the biggest topic of research for researchers, but also for big companies like Linux or IBM. The big advantages, both from security and economical p.o.v., together with its high flexibility, makes blockchain a suitable technology for many applications: financial, food, supply chains, research, etc.. Today the number of blockchain-based applications is constantly growing, but many compa-nies did not already start in adopting this new technology.

In this work, blockchain will be deeply explored and integrated with other successful tech-nologies (e.g., IoT, Angular, OAuth, Android) in order to understand the real advantages that the technology can provide to future applications. As already mentioned, blockchain technology is suitable for a wide range of applications, but in this work the attention will be focusing on a specific use case: the traceability and certification of Extra Virgin Olive Oil (EVOO from now on). EVOO is an emblematic product for Italy, known and venerated in the entire world. Unfortunately, this is also one of the most falsified product. This work would like to provide a system to enforce the certification of this product, by tracing the entire process of production: from the plantation to the shops. The goal is to enable a final user (the one that buys the product) to access the entire history of the product (e.g., farming process, harvesting, production, packaging, conservation, transportation) for example using its own smartphone (Fig. 1.1).

During the entire process of production, a product profile will be created with data extracted along the supply chain and stored in the system. Due to their enormous quantity, the process of data acquisition an storing will be supported installing an enabling IoT devices to automat-ically measure and transmit quantities of interest (e.g., C02, temperature, humidity, acidity, ..).

(12)

2 1. Introduction

Fig. 1.1 Traceability and certification of EVOO

1.1 Thesis organization

After introducing the main idea behind the thesis work, in next two chapters (2, 3) the two main used technologies will be introduced: IoT and blockchain. In the case of IoT a survey on existing security problems will be provided, whereas the chapter on blockchain will focusing its attention mainly on the Hyperledger framework, the one used in this work to implement the final system. In chapter 4, the use case details will be described. The entire production process will be presented and deeply explored, focusing the attention on all the parameters that affect the product quality. It will be demonstrated that the specific use case is suitable for the adoption of the blockchain technology. At the end of the chapter, the threat model will be discussed, providing a set of countermeasures to be taken in order to mitigate the effects of eventual attacks. Chapter 5 will discuss step by step the entire implementation of the system, from the definition of participants to testing and integration. Finally, in chapter 6 a performance evaluation of the blockchain will be done. Simulations will be executed in order to understand the impact of parameters on the system performances. The second part of the chapter will present a solution for an auto-adaptive blockchain that automatically changes its parameters to fit the business requirements.

(13)

2. Internet of Things

Internet of things is one of the most promising and growing technologies of the new century. The term ‘internet of things’ (IoT from now on) refers to a network formed by a, typically large, number of devices that are connected between them and that are able to exchange informations. Those devices may be everyday devices that may be made smart by equipped them with small computers that are able to perform simple operations as minimal computa-tions, easy measurements and transmissions of small packets to other devices. The reason why IoT is becoming one of the most promising technologies is related to the fact that it may be used in many fields, opening the way to an enormous set of new possible applications. IoT is now used to support a big range of processes creating new possibilities to improve efficiency in industries, but also people everyday life. Smart homes, precision agriculture, pollution control, healthcare applications, predictive maintenance are only few of the possible applications that IoT made possible. The consequence of this increasing interest can be easily showed using the graph below. In the last years the number of connected devices is incredibly increased following an exponential behaviour and it is destined to continue in increasing in the next years.

(14)

4 2. Internet of Things Due to cost and portability reasons, IoT devices are typically resource constrained devices with limited performance, energy and memory. Those new features open the way to new challenges related to the fact that in most cases typical protocols cannot be used because they are not suitable for the typical IoT devices for the previously described reasons. Resources must be correctly managed in order to avoid depletion and possible failures that may compromise the correct network and application behaviours. Differently from typical network, that can be considered as homogeneous networks and so composed by devices that have in principle the same basic characteristics, IoT must be seen as an heterogenous network where devices may be also extremely different between them. For all this reasons, new technologies need to be developed and new protocols to be designed in order to fill the gap. In the next paragraphs the main IoT features and technologies will be better highlighted, by conceding particular attentions to the technologies that are more important for the scope of this work. At the end of the chapter security and privacy in IoT will be well discussed in order to introduce the main problems that must be addressed.

2.1 Towards IoT next generation

As said before, IoT is an emerging technology that is still far from the way it was initially thought. The way in which actually IoT applications are implemented is called “vertical solution”. This term represents the case in which single applications are completely inde-pendent from the other ones: data are collected by a set of devices, elaborated and a service is provided. The collected data are not shared with the rest of the community but they are bounded inside the specific application. Differently from the actual situation, the IoT next generation is something which is more complicated: the worldwide devices must be seen as a unique network that is able to sense data, to collect and store them in order to have a much more wide and deeper comprehension of the world. This scenario is something which is much more similar with respect to the internet: devices belong to a single network and data can be accessed in order to provide and distribute services. The important thing to take in mind is related to the fact that, also if very similar to the internet, IoT creates completely new challenges that need to be addressed in order to successfully manage and maintain an horizontal solution. Actually, the reason why vertical solutions are adopted is relative to the fact that, in some cases, available technologies are not already suitable or are not already standardized and so a cooperation between existing applications is impossible, or at least very difficult. The increasing number of researchers that are focusing their attention in the field of IoT is guiding this technology towards the next generation solution.

(15)

2.2 Survey on security and privacy

The overall IoT is formed by a huge variety of devices like sensors, RFIDs, smartphones, tablets, cars and cameras that are used to provide a wide range of possible applications that in many cases need to access personal data about clients that may be more or less sensible. Unfortunately, most of this devices are not designed to manage security and privacy requirements. As mentioned before, IoT devices are typically constrained devices with limited resources and, in general, applications may require non-conventional functional requirements that can also be in contrast with the main features of security and privacy. The typical example is related to the fact that security through encryption schemes is a procedure that may require a non-negligible use of energy and so may be not suitable for devices that need to reduce as much as possible the energy consumption. Another example is related to critical applications where bounded and small delay is the main requirement. Cryptography is a cost not only in terms of spent energy, but also in terms of time that is needed in order to encrypt and decrypt messages or to share keys between parties during protocols execution. Privacy is an extremely difficult challenge to be addressed in some cases, in particular when it is coupled with security. As will be better explained later, only partial solutions are available that do not provide complete privacy, but at least are able to made difficult to obtain informations related to parties. Beyond the large number of problems that IoT creates, providing security and privacy features to clients is extremely important and is not only an option, but a real necessity. In October 2016, a massive Distributed Denial

(16)

6 2. Internet of Things of Service (DDoS) attack has been launched against Dyn through a botnet of IoT infected devices. This event has turned on the alarms on the consequences that vulnerable IoT devices may cause. The authors of [1] identifies the following set of security requirements for IoT devices, in order to be considered as secure:

• Secure authentication

• Secure bootstrapping and transmission of data • Security of IoT data

• Secure access to data by authorized persons

When exchanging data between IoT devices, confidentiality, integrity and availability become key features that need to be implemented, paying also attention in the way in which they are executed and optimized. [3] Confidentiality refers to two, or more, parties are able to exchange informations being sure that their communication is not read by third parties. It can be achieved by using encryption schemes and is particularly relevant in business context. Integrity protection includes preservation against malicious sabotage and physical failures. It is achieved by using hashing in combination with encryption schemes. Availability refers to the ability of a system to being available and to continuously provide its service. This feature is particularly important in business scenarios since unavailability may cause potentially catastrophic damages in terms of money. Variants of DDoS attacks are the main risk for the availability of the systems. In principle, security requirements depend by the specific application. Assume the following two examples: a smart home and a smart surveillance system inside a bank. The two examples are very similar in most the aspects but their scenarios are different. First of all, the evaluation of risk is a fundamental aspect in defining requirements: the risk of being subject to malicious attack is extremely bigger in the second scenario. Availability represents the biggest difference in this case. The same DDoS attack, launched against the two systems, is responsible of two different gravity of consequences. Due to their nature, IoT devices are typically subject to a wider range of possible attacks w.r.t. typical computers. The authors of [5] identify four different levels of possible attacks against an IoT network: low, medium, high and extremely high level attacks.

• Low-level attack: an attacker tries to attack a network without success. Eavesdropping, traffic analysis and alteration are some examples of possible attacks that may be easily avoided by ensuring confidentiality and integrity.

(17)

• Medium-level attack: an attacker is able to listen communication on the medium, but is not able to alter the data integrity. Encryption of data must be used in order to avoid attacks like man in the middle or eavesdropping.

• High-level attack: an attacker is able to alter the data integrity. Unathorized access, spoofing, cloning, message re-routing, interruption are some examples of attacks that may compromise the communication integrity.

• Extremely-high-level attack: an attacker performs illegal operations, making the network unavailable or sending bulk messages. DoS, jamming, malware attacks, Trojan horses, worms can be exploited by an intruder in order to cause big damages to the overall network.

(18)

3. Blockchain technology

Blockchain (BC from now on) was first proposed by Satoshi Nakamoto as the main technol-ogy behind Bitcoin [4]. BC is a distributed, append-only database where multiple participants contribute to write records. The database is continuously kept in sync, there is no single owner of the data. The main characteristic of BC is related to the fact that, differently from typical systems that are centrally managed, it enables parties to agree on events without needing to third parties. The use of BC provides some benefits as high efficiency, speeding up financial transactions between parties, but also transparency by providing a real time view of trades. Another fundamental benefit is related to the increased resiliency to attacks. The distributed nature of BC makes the overall system difficult to be compromised. Centralized methods are prone to data corruption due to their limited number of point of failures. For this set of reasons BC appears as a very good technology that is able to offer, at the same time, better performances and an higher level of security. In the next sections BC will be better explained by introducing technical details and implementation methods.

3.1 How Blockchain works

In Fig. 3.3 the difference between centralized, decentralized and distributed networks is shown. BC, as said before, is particularly relevant when mutually trust is needed in a peer-to-peer network (third in Fig. 3.3). By looking at the network topology, is easy to understand that no third parties are present inside a BC system. In this way, business cohesion is increased, complexity reduced and risk minimized.

BC can be used in many cases, but is important to understand when the use of this technology is able to provide real advantages or to solve problems. In principle, BC is particularly useful when multiple entities do not fully trust each other and need to agree on a single version of events, or require a data source that is tamper-proof. BC is defined as a shared, replicated, append-only database where participants are able to write transactions. In order to be part of the BC, a new participant need to, first, download the entire database, to install and run an ad-hoc software. Each node inside the network kept the same copy of the

(19)

Fig. 3.3 Different network topologies

database and it is an entry point for new data (transactions) that are added to the BC. Each participant acts as a validator of new transactions: before adding a new transaction in the BC the validity of it is proved by computing local measurements and by executing special protocols in order to solve particular cases in which parties say conflicting things. In Fig. 3.4 it is represented the way in which a BC in organized. Transactions are grouped into blocks. A block contains a set of transactions and it is chained with the previous block. Chaining is performed by including the hash of the previous block inside the current one. In this way a chronological order is maintained and integrity of BC is ensured. As explained in [1], the nonce is used in order to implement the proof-of-work (PoW).

BC is able to provide an high level of security: an attacker, in order to modify a block, needs to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. This situation is particularly improbable due to the fact that PoW is typically computationally feasible. Again in [4] is demonstrated that that the probability that an attacker may successfully change the content of a block decreases exponentially when new blocks are added.

(20)

3.2 Public and private blockchains 11

Fig. 3.4 BC structure proposed for Bitcoin

3.2 Public and private blockchains

One of the breakthrough of bitcoin was the ability to maintain a unique, coherent vision of the transactions into the system. In bitcoin anyone can create and invoke transactions and anyone can add blocks of transactions to the blockchain. All this operations can be done without the permission of higher authority. For this reason, the bitcoin blockchain can be seen as the grandfather of public, or ’permissionless’ blockchains. In general, inside a public blockchain, anyone can write data to it just by running a free software, without signing up. Conversely, private blockchains, or ’permissioned’ blockchains, limit the access, both in read and write, to a restricted, known set of participants. This means that participants are linked to identities inside the system and that each operation is signed using those identities. The following table summarizes the main differences between public (permissionless) and private (permissioned) blockchains.

PUBLIC BLOCKCHAIN PRIVATE BLOCKCHAIN Anyone can write Limited set of entities can write

Anyone can read Read-access is configurable

3.3 Hyperledger project

Hyperledger project is an umbrella project of open source blockchains and related tools, started in December 2015 by the Linux Foundation, to support the collaborative development

(21)

of blockchain-based distributed ledgers. Hyperledger was born focusing its attention on a set of goals:

• Create enterprise grade, open source, distributed ledger frameworks and code bases to support business transactions

• Provide neutral, open, and community-driven infrastructure supported by technical and business governance

• Build technical communities to develop blockchain and shared ledger POCs, use cases, field trails and deployments

• Educate the public about the market opportunity for blockchain technology

The overall projects is composed by a set of frameworks, that can be used depending on the application requirements. Each one of the framework is supported by a tool that accelerates the developing phase and facilitates the reuse of building blocks. Fig. 3.5 provides an overview of the Hyperledger project.

Fig. 3.5 Hyperledger project

3.4 Hyperledger Fabric

Hyperledger Fabric is a blockchain framework implementation that allows components, such as consensus and membership services, to be plug-and-play. Hyperledger Fabric leverages container technology to host smart contracts called “chaincode” that comprise the application logic of the system. The goal of Hyperledger Fabric is to provide an efficient and easy to

(22)

3.4 Hyperledger Fabric 13 use blockchain framework which is oriented to business. In general, an enterprise-oriented blockchain technology needs to satisfy some properties:

• Participants must be identified/identifiable • Networks need to be permissioned

• High transaction throughput performance • Low latency of transaction confirmation

• Privacy and confidentiality of transactions and data pertaining to business transactions The biggest reason that encourages enterprises to use Hyperledger Fabric instead of other technologies is that the others are typically adapted for enterprise use, whereas Hyperledger Fabric has been designed for enterprise use from the outset. Fabric has a highly modular and configurable architecture, enabling innovation, versatility and optimization for a broad range of industry use cases including banking, finance, insurance, healthcare, human resources, supply chain and even digital music delivery. In addition, Fabric has been the first blockchain technology that enabled the creation of smart contracts using general-purpose programming languages such as Java, Go and Node.js. The Fabric platform is permissioned, so blockchain participants are known to each other. One of the most important of the platform’s differen-tiators is its support for pluggable consensus protocols that enable the platform to be more effectively customized to fit particular use cases and trust models. In fact, different consensus strategies can be selected simply by changing configurations during the development phase.

3.4.1 Hyperledger Fabric Architecture

In this section the main components of Hyperledger Fabric will be first introduced and then put together in order to provide a complete vision of the system architecture.

Hyperledger Fabric CA

Hyperledger Fabric CA is responsible for creating all the cryptomaterial needed in order to correctly run the blockchain system. In Hyperledger every single operation in the network must be cryptographically signed using certificates. Certificates can be generated by using external tools like OpenSSL or using a third party that operates as a certification authority. Hyperledger Fabric CA allows you to generate certificates. Certificates are ’per user’ and they may contain additional attributes that define the set of permitted operations for a certain user of the blockchain system. The chaincode is able to read the attributes contained in the

(23)

certificates and to grant permissions to users. Certificates are immutable and this makes the process very secure.

Once a user has been registered, the corresponding cryptomaterial is generated. The crypto-material of a certain user defines its identity inside the system. The operation of generating certificates is also called ’enrollment’. Summing up, certificates are used in order to track actions of users inside the blockchain system and they can be generated as preferred. The usage of Fabric CA is strongly recommended.

Peers

The peer is the place in which the ledger (the blockchain) is stored. The SDK (the entry point of the blockchain system) receives input from the users and routes transaction proposals to the peers. At this point, peers simulate the transaction execution and return the obtained result. A blockchain network contains multiple peers. The number of peers to be installed is a critical parameter since it impacts the system throughput. Increasing the number of peers improves the system throughput due to the fact that more transactions can be handled concurrently. When a peer receives a block of transactions, it applies a verification step and proceeds appending the block to the ledger.

Ordering Service (Orderer)

It is the art of the consensus algorithm. Its main role is to provide order of operations. Before anything is committed it must pass in the Ordering Service that creates the block that will became part of the blockchain. The Ordering Service creates orders in transactions, creates the block that, when full, is routed to the peers. In other words, the main task of the Ordering Service is to decide which operation happens before or after another operation. It is able to manage the concurrency problem, the double spending problem and also security. During development, a single Ordering Service is enough. An Hyperledger Fabric architecture that presents a single Orderer is called ’Solo’. A single Orderer represents a single point of failure, in production you need to instantiate multiple Ordering Services.

NOTE: HFCA, peers and ordering services run inside Docker containers. (see Sec. 5.4.1) Channel

It is one of the most important concepts behind Hyperledger Fabric. A channel can be seen as a completely separate instance of Hyperledger Fabric. A channel is completely isolated. Data are exchanged between parties passing through channels. In other words, a channel puts in communication different parties (the so called organizations) that allowed to exchange informations under some conditions that are defined at the moment in which the channel is created. The channel configuration is stored inside the first block of the blockchain.

(24)

3.4 Hyperledger Fabric 15 Chaincode

Chaincode is a smart contract. It is a program that implements the business logic. The only thing that can manipulate the blockchain is the chaincode. As previously mentioned, Hyperledger allows developers to write the chaincode using general purposes languages (like Go or JavaScript). A chaincode is installed in each peer that belongs to the channel to which the chaincode is referred.

3.4.2 Transaction flow

In this section the entire flow of a transaction will be demystified: from the moment in which the transaction is invoked from a blockchain user, until the moment in which the ledger state is updated according to the data contained in the transaction. Fig. 3.6 represents an overview of the transaction flow. In the following, each step is explained.

• (A): a user generates a transaction and send it to the blockchain system passing through the network entry point: the SDK. In a typical scenario, the SDK is interfaced with a REST API through which a user can execute a curl command.

• (B): the SDK, once received a transaction, generates a transaction proposal specifying all the needed arguments.

• (C): the transaction proposal is sent to one or multiple peers.

• (D): peers accept the proposal and simulate it. An endorsement response is generated from the peers. It contains the simulation result, together with all the cryptomaterial needed in order to correctly sign the operation.

• (E): the SDK collects all the endorsement responses coming from the various peers. An invocation request is generated and routed to the Orderer.

• (F): the Orderer verifies all the cryptomaterial and verifies the homogeneity of the endorsement responses returned from the various peers. Since peers are kept in synch, the same response is expected. A peer that returns an unexpected response may be out of synch or compromised. If everything is ok, the Orderer sends the data to every single peer of the network that will update the state of the ledger.

The figure wants also to highlight the fact that, in the case in which multiple organizations are involved (with multiple Orderers), informations are continuously exchanged in order to kept in synch the entire network. A user that wants to update the ledger can access the blockchain network passing through one of the entry points provided from the various organizations.

(25)

Fig. 3.6 Transaction flow overview

3.4.3 Consensus

As well known, a blockchain application comprises multiple parties with conflicting business objectives. Participants store transactions inside the ledger that must be validated and ordered following specific rules. The key aspect behind the blockchain is that all the parties agree on a single state of the ledger, so there are no different versions of the database. In order to create unique version of the ledger, consensus algorithms are exploited. In the following section the main consensus algorithms will be presented and compared in terms of performance and application scenarios. Explanation will be mainly focus on the algorithms used in the different frameworks provided by Hyperledger. In particular the following consensus algorithms will be discussed:

• Proof of Work (PoW) • Proof of Stake (PoS) • Kafka

• Practical Byzantine Fault Tolerance (PBFT)

At the end of the section a schematic comparison between the various algorithm will be presented.

Proof of Work (PoW)

(26)

3.4 Hyperledger Fabric 17 behind the Bitcoin technology [1]. In this scenario parties (miners) are involved in the consensus and they must solve a cryptographic puzzle to “mine” a block in order to add it to the blockchain. This process requires an immense usage of energy and computational capabilities. The puzzle consists in finding a couple of text-nonce that, once hashed, begins with a number of zero bits. When a miner solves the puzzle, it presents the block to the network for verification. Verification of a block is an extremely simple process. Once a block is validated, it is added to the blockchain. PoW provides Byzantine fault tolerance, but unfortunately there are some issues related to it. First of all, it is a very inefficient process because lots of resources are wasted during the execution. Another issue is related to the fact that organizations with powerful machines have an higher probability to mine the block. This makes PoW-based blockchains not decentralized as desired.

Proof of Stake (PoS)

Proof of Stake was proposed as an alternative to Proof of Work. The significant aspect that differentiates the two processes is related to the amount of required resources. In fact, PoS is a lot more resource-friendly than PoW. In PoS the creator of a new block is chosen in a deterministic way, depending on its stake. In other words, a participant can mine or validate a block depending on how many assets it owns. Also this mechanism is not perfectly decentralized, by nature. In fact, it is sufficient for a malicious entity to take the control of the network simply by owning the 51% of the assets in the network. PoS is used in Ethereum (ETH).

Kafka

Kafka is the Hyperledger Fabric ordering mechanism that is recommended for production use. This ordering mechanism utilizes Apache Kafka, an open source stream processing platform that provides a unified, high-throughput, low-latency platform for handling real-time data feeds. In this case, the data consists of endorsed transactions and RW sets. The Kafka mechanism provides a crash fault-tolerant solution to ordering. The crash-tolerance mechanism comes into play by replication of the partitions among the multiple Kafka brokers. Partitions are sets of contents that share the same topic. In Hyperledger a partition is represented by transactions belonging to a group of clients that share the same channel. Practical Byzantine Fault Tolerance (PBFT)

Practical Byzantine Fault Tolerance (PBFT) is an alternative to Kafka in Hyperledger Fabric. This mechanism provides byzantine fault-tolerance, differently than Kafka that provides only crash fault-tolerance. PBFT requires that, given f faulty peers, they are less than one third of the overall number. So, the network consists of at least n=3f+1 peers. In [2] Sukhwani et al

(27)

Table 3.1 Comparison of consensus algorithms

CONSENSUS APPLICATION PROS CONS Proof of Work

(PoW) Bitcoin Provides Byzantinefault-tolerance. Scales well with the number of nodes

Energy expensive. Mining requires lot of time

Proof of Stake (PoS) Ethereum Resource-friendly,

Fast Subject to 51% at-tack Kafka Hyperledger Fabric Provides crash

fault-tolerance, Fast Doesvide notByzantine pro-fault-tolerance PBFT Hyperledger Fabric Provides Byzantine

fault-tolerance Does not scale wellwith number of peers

prove that this consensus mechanism does not scale well with the number of peers, becoming a performance bottleneck in terms of time needed to reach consensus.

Comparison

These are only few of the many consensus mechanism that are available in the literature. In principle there is no an always-right consensus to apply because it must be chosen according to the specific requirements of the developed application. Both performance and security requirements must be taken into account when selecting the most appropriate one. Table 3.1 wants to summarize the pros and cons behind the previously described methods.

(28)

4. A blockchain case study: traceability

and certification of EVOO

4.1 Introduction

Blockchain is going to be adopted in many application scenarios. From one side it is able to offer new security features like ensuring immutability of transactions and the elimination of a single point of failure in the network. From the business point of view it is becoming a sort of “mark of warranty”. This does not mean that blockchain is applicable in every scenario because in order to use it, a technician must control that the context of application is suitable and able to positively respond to a set of questions. The schema in Fig. 1 represents a simplified blockchain decision tree. So, before deciding to use a blockchain, a technician must evaluate the real impact that its adoption will have on the application scenario. Actually many industries are adopting blockchain without really understanding the key aspects behind this technology. In the rest of the thesis, the attention will be focus on a real case study that is suitable for the application of a blockchain technology and that can really obtain advantages from its adoption. The next paragraph will introduce the case study that will be at the base of this work: the digital traceability and certification of extra virgin olive oil.

4.2 Traceability and Certification of Extra Virgin Olive Oil

The traceability and certification of extra virgin olive oil (EVOO from now on) is a suitable use case for the adoption of a blockchain. First of all it involves different parties that share the same interest (the support for an efficient supply chain) and that in principle have conflicting objectives (their own profits). This first principles are able to explicitly and positively respond to the questions 2 and 3. In this supply chain we will consider 3 different parties:

• Farmers: the ones that produce the raw material (olives)

(29)

Fig. 4.7 Blockchain decision tree

• Couriers: the ones that transport both raw materials and products • Sellers: the shops owners

It is evident that also the question number 4 can be easily confirmed due to the big differences between the involved parties. The positive response to question number 1 can be achieved by focusing the attention on the final goal of the application: a consumer must be able to access the story of the product that it is going to buy. In order to provide this feature, each single product must be associated with a digital profile that tells its history. In the specific scenario of EVOO, the label will provide smart access to all the informations related to the product from the field of origin to the shelf, passing through the maker and the conservation methodologies. At the state of the art this informations are typically not completely available in most cases or at best shared in many sites. This is why there is a need for a common shared database. The hardest question is for sure the number 5. It can be reformulated as “Why data immutability offered by blockchain is needed?”. Before answering to the question, an additional step can be done by focusing the attention on the business scenario. Why one of the parties may be interested in changing something inside the distributed database? And the reason is always the same: moneys. The mutation of a past transaction may represent an economical advantage for one of the parties and a potential damage for another one. Some

(30)

4.3 Production process 21 examples will be successively highlighted in the next sections. This consideration is sufficient to answer the question number 5. The question number 6 refers to the fact that a blockchain represents the log for a business scenario where transactions respect specific business rules (also called business logic). A business scenario that is not enough stable may potentially represent an economic damage to the entire organization due to continuous redefinitions of the business logic. In the EVOO case study, a stable business scenario will be assumed. This assumption does not represent an approximation of the real case, but it can be considered as realistic assumption. All the previous discussions have shown that the use case is suitable for the adoption of a blockchain solution. In the following sections the reader will get more details regarding the use case, both from the production process and the application point of views.

4.3 Production process

The following section will describe the production process of the EVOO. The entire process will be first decomposed in macro subprocesses which will be successively examined in their details. Six main subprocesses were identified:

1. Olive farms: the production process of the raw material (olives) 2. Olive harvest: the garbage collection process

3. Olive transportation: the movement of the raw material from the farmer to the maker 4. Olive oil production: the entire transformation process from raw material to final

product (EVOO)

5. Packaging: the bottling and conservation process

6. Olive oil transportation: the movement of the products from the maker to the shops The flow diagram in Fig. 4.8 represents the order in which the subprocesses are executed and the entity that will be responsible for the correctness of the procedure.

As said before, macro subprocesses can be divided in subprocesses. For example, the oil production phase is composed by many steps like the crushing, oil storing or decanting processes. In order to correctly monitor the life cycle of the EVOO and obtain a real indication about the product quality it is important to deeply understand every single process by detecting possible critical actions that affect the quality. In principle, data will be extracted from every subprocess, but it is important to understand what kind of informations are needed

(31)

Fig. 4.8 Olive oil production process flow diagram

and how they must be obtained. The identification of the critical steps in the overall process will support the selection of the IoT sensors that will be installed along the supply chain.

4.3.1 Olive farms

The olive cultivation is one of the most critical subprocesses. It obviously affects the quality of the final product. There are many factors that affects the quality of the olive: meteorological conditions (e.g. temperature, humidity), the treatment (e.g. chemical products, air pollution), field conditions (e.g. chemical composition). Olive quality strictly depends by these factors, in fact they can be used as a reference point to estimate the quality of the final product. In conclusion, the olive farms subprocess can be divided in the following tasks:

• Weather condition monitoring • Field condition monitoring • Treatment monitoring

Every task must be continuously executed during the entire farming process in order to create a significant farming profile for the raw material: olive farming profile (OFP).

(32)

4.3 Production process 23

4.3.2 Olive harvest

Another very important aspect that affects the quality of the oil is the way in which harvest is performed. First of all, the period in which harvesting is performed became critical:

Period Effect Economical impact Too early Poor olive performance Production reduction

Too late Loss of olive integrity Price reduction

As summed in the previous table, it is important to perform harvesting in the right moment in order to maximize profits. The chose of the wrong moment may represent a potential loss of tens of thousands of euros for a big olive farmer. Another important factor is the storing time for the harvested olives. In principle they must be stored for a maximum of three days after the beginning of the harvesting phase. Otherwise their integrity collapses causing a loss of quality. Last but not least, the method of harvesting represents a fundamental aspect of the harvesting process. In principle there are two different methods: by hand or by using specific machines. As better explained in [6], the usage of machines increases the percentage of acidity and the peroxide value of the olives. Results are reported in the following table:

Harvesting method Acidity(%) Peroxide Value(per Kg) By hand 1,8733±0,014 5,6933±0,003

Machine 2,0633±0,009 6,4400±0,023

Values were obtained by evaluating three different samples of olives from two different varieties. Summing up, three main factors affect the quality of the product during the harvesting phase:

• Period of harvesting • Harvesting time interval

(33)

• Harvesting method

These parameters will create the olive harvesting profile (OHP).

4.3.3 Olive transportation

During transportation olives must be conserved in a controlled environment. Temperature of conservation is a critical aspect for the quality of the product: every 10 degrees of temperature reduction the metabolic process is reduced from 2 to 3 times. In order to reduce the olive deterioration process olives must be conserved at low temperatures. The temperature will be monitored during the entire transportation process from the farmer to the maker.

4.3.4 Olive oil production

The olive oil production process is composed by many subprocesses each of one must be monitored in order to understand the product quality. During the entire process, olives are subject to multiple transformations. The following subprocesses were individuated:

• De-leafing and washing • Crushing

• Malaxing • Decanting • Separation

Fig. 4.9 represent the oil production process.

Fig. 4.9 Olive oil production process

Each single step is performed by using a different equipment and must be executed following specific rules that govern the production. In order to obtain a product of quality there are some parameters that must be respected and monitored. The following table shows the criterions that must be respected during the different phases:

(34)

4.3 Production process 25 Phase Metric Reference value

De-leafing and washing Water temperature < 30°C

Crushing Temperature < 27°C

Malaxing Temperature < 27°C

Decanting Temperature 21°C

Separation -

-As shown, the key parameter behind the olive oil production process is the temperature. High temperatures may degrade the quality of the final product. The set of data coming from the different sensors installed in the olive oil production supply chain will constitute the olive oil production profile (OOPP).

4.3.5 Packaging

The packaging phase can be decomposed in two main sub phases. • Storing

• Bottling

The storing phase is responsible for the correct conservation of the product. Its objective is to preserve the characteristics of the product: color and scent. In order to obtain a good preservation of the product, its temperature must be kept constant (15°C) before and after the bottling phase. The informations coming from the conservation of the product will constitute the olive oil conservation profile (OOCP).

4.3.6 Olive oil transportation

As in the case of olive transportation phase, the product must be conserved in a controlled environment during the movement from the maker to the shops. Ideally temperature must be

(35)

kept constant at 15°C during the entire transportation phase. The combination between this information and the informations coming from the olive transportation will constitute the olive oil transportation profile (OOTP).

The following image summarizes all the previous steps. As shown, all the data coming from the different processes will be stored inside the blockchain.

(36)

4.4 Sensing 27

4.4 Sensing

As said before, the goal of the project is to provide a user with an exhaustive description of the product by telling its history from the field to the market. This objective can be achieved by extracting data from the processes of farming, harvesting, production, transportation and conservation. All the data will became part of the same shared database, the blockchain. Some data will be manually inserted from qualified employees during the supply chain, whereas other data will be automatically obtained by enabling sensing. Measures like temperature, humidity or air pollution will be monitored using smart devices that will be able to measure the quantities of interest and to store them in the blockchain. The entire process will be completely automated in order to increase efficiency on the entire supply chain. The previous paragraph is now used as a support for understanding what types of sensors are needed and where should they be placed. In principle, sensors will be placed in the following locations:

• Fields • Trucks

• Olive oil mills • Basements

4.4.1 Temperature monitoring

The key parameter te be monitored during all the processes is the temperature. Sensors for temperature measurement will be installed in everyone of the previously cited locations. The olive oil production is not an extremely critical process: a variation of 1 or 2 degrees does not affect the product quality in a catastrophic manner. For this reason, simple and low cost sensors can be used to measure this parameter. An extremely accurate sensor is not required. The usage of low cost sensors may represent a relevant cost reduction due to the huge number of sensors that must be installed to monitor the entire environments, especially in the field. In order to choose the most appropriate temperature sensor some application-specific parameters must be considered. Some questions must be taken into account:

• What is the desired temperature range?

(37)

• Are there any performance and cost constraint?

Obviously the answer may change dependently from the specific process: the monitoring of a chemical process temperature requires different features with respect to the monitoring of a private house temperature. The following table represents a comparison between different types of temperature sensors. It can be used as a support for deciding what type of sensor is the most adequate for a specific task.

Criteria RTD Thermistor Thermocouple IC sensor Temperature range(°C) [-250, +750] [-100, +500] [-267, +2316] [-55, +200] Accuracy Best Calibration-based Good Good Linearity Good Worst Good Best Sensitivity Less Best Worst Good Power consumption High High Low Lowest Cost $$-$$$ $-$$$ $$-$$$ $ Texas Instruments data

Let’s take a deeper look at the cited properties:

Temperature range is the interval of temperature values in which the measurement can be taken.

Accuracy is the value difference between the real value and the one at the output of the sensor.

Linearity is the ability of a sensor to have a transfer function almost linear (close to the ideal one).

Sensitivity is the minimum input of physical parameter that will create a detectable output change.

Power consumption is the energy spent by the sensor to perform its task.

When taking a decision on which type of sensor to use, a good developer should take into account all these factors by analyzing the specific application environment. For the use case treated in this thesis, the usage of IC sensors is the most convenient one due to its low price and suitable performances.

(38)

4.4 Sensing 29

4.4.2 Chemical composition monitoring

Another fundamental aspect to be monitored during the olives farming process is the chemical composition of the environment and of the land. As previously mentioned, some parameters like the air pollution and the chemical treatments affect the quality of the product. There are actually a huge span of sensors that are able to measure the presence of chemical substances in the air, but their technical details are out of the scope of this work. An important aspect that can be simply monitored is the air pollution. Currently, many cities over the world adopted some of these sensors in order to monitor the quality of the air inside the town. The actual situation is that they use big and costly sensors that do not provide a sufficient amount of data in order to obtain a real representation of the air quality into the town. The next step will be the usage of many sensors of typically small dimensions and low cost, that can provide the granularity needed to begin to understand the real ambient conditions. There are several sensors currently available:

• Electrochemical sensors: based on a chemical reaction between gases in the air and the electrode in a liquid inside the sensor

• Photo ionization detectors: ionises volatile organic compounds and measures the resulting electrical current

• Optical particle counters: detect particulate pollution by measuring the light scattered by particles

• Optical sensors: detect gases like carbon monoxide and carbon dioxide by measuring the absorption of infrared light

The following table summarizes the parameters that can be monitored using the previously cited types of sensors:

Sensor Measure Response time Cost Electrochemical sensor NO2,SO2,O3,NO,CO 30-200s 50-100C

Photo ionization detector VOC few seconds 400 C Optical particle counter PM 1s 300C Optical sensor CO,CO2 20-120s 100-300C

(39)

4.5 Threat Model

After discussing all the details related to the use case, a threat model of it must be provided. Threat modeling works to identify, communicate and understand threats and mitigations within the context of protecting something of value. Typically, a threat model includes:

1. A description / design / model of what you’re worried about (already done in the previous sections)

2. A list of potential threats to the system 3. A list of assumptions

4. A list of actions to be taken for each threat

4.5.1 Threats identification

As explained in the past sections, the entire production process of Extra Virgin Olive Oil (from the plantations to the shops) will involve multiple parties with, typically, conflicting objectives. For example, a party may be interested in giving false statements to take advantages from its lie, or it can be interested in tell the truth and change its version later. The described use case is full of situations in which parties may be interested in doing malicious actions. In addition, threats may come from the outside: a malicious entity, external to the system, that has the objective of compromising the correctness of the system. From now on, threats will be distinguished in two main categories:

• From inside the system: the ones coming from malicious clients

• From outside the system: the ones coming from external entities to compromise the system correctness/availability

Internal threats

In the presented use case, a participant of the system may be interested in degrading the reputation of another participant. Assume the case in which a farmer A wants to devalue the product of another farmer B. The easiest way to do that is to impersonate the identity of farmer B and starting to transmit data that nominally degrade the quality of the product. Fig. 4.11 represents the case in which a malicious participant tries to transmit data associated to an asset that is not on its ownership (a plantation in the specific case). The system must be able to avoid a situation like this one, by adopting specific, predefined access control rules.

(40)

4.5 Threat Model 31

Fig. 4.11 A malicious entity tries to impersonate someone else

Another typical scenario is related to an entity that may be interested in changing, in a malicious way, data inside the system. In this situation two different situations may happen:

• The malicious participant wants to change its own data

• The malicious participant wants to change data of another participant

Both situations may hide different reasons, but they can be solved using the same solution: enforcing immutability of data. Fig. 4.12 reports an example of the first type of situation, the one in which the owner of the data (Farmer X) may be interested in changing something to take advantage w.r.t. another participant.

(41)

Let’s describe step by step the situation in Fig. 4.12:

• A: Farmer X invokes a transaction to inform the system that it is going to transfer 50 tons of Olive to Courier Y.

• B: Farmer X physically transfers the 50 tons of olives to Courier Y.

• C: Courier Y verifies on the system that the received asset corresponds to the one specified on the system.

• D: Courier Y starts the shipment.

• E: During the shipment, Farmer X maliciously modifies the data on the system, changing the weight of olives from 50 tons to 100 tons.

• F: Courier Y invokes a transaction to inform the system that it is going to transfer 50 tons of Olive to Maker Z.

• G: Courier Y physically transfers the 50 tons of olives to Maker Z.

• H: Maker Z verifies on the system that the received asset corresponds to the one specified on the system.

When checking the correctness of data, Maker Z founds some inconsistencies because Farmer X declares 100 tons, whereas Courier Y declares only 50 tons. Someone is giving a false statement, but from the Maker Z p.o.v the two situations cannot be distinguished. External threats

External entities may be interested in compromising the correctness of the system. In the presented use case, two main ways of corrupting the system exist:

• Delete/compromise/steal data • Compromise the system availability

In the first case, an adversary may be interested in performing malicious actions w.r.t. the storage system. It may be interested in deleting or changing data to compromise the system reputation, or steal data for any type of reason. In addition to enforcing the data immutability, the system must provide also secure data storing.

(42)

4.5 Threat Model 33 The system availability is a fundamental property, especially in business scenarios. The loss of availability may potentially represent a catastrophic economical damage. Denial of Service (DoS) attacks represent the most severe threat for the system availability. Due to their varying nature, DoS attacks are really dangerous and difficult to be handled. A good practice is to avoid single point of failure, by replicating or distributing the system.

4.5.2 Assumptions

For our case study, the following statements will be assumed:

• Informations will be sent in a secure manner: there is no way for an adversary to compromise the communication between participants and the system.

• The site(s) that will host the system are trusted: they operate without malicious scopes w.r.t. the system users.

• Sites trust each other: in a distributed system, the sites that host the system does not operate in a malicious way w.r.t. other sites.

The first assumption has been done because it is out of the scope of this thesis work. It can be achieved by enabling secure communication over the network. The second assumption is a realistic one: a server that provides a service typically does not operate in a malicious way w.r.t. its clients. Finally, the third assumption is the strongest one, especially in cases in which sites have conflicting objectives (like in this case). The impact of this last assumption on the system specifications will be better demystified at the end of the chapter.

4.5.3 Countermeasures

Once identified, threats must be handled by adding mitigation strategies to the project. A mitigation strategy is a countermeasure that reduces or inhibits the effects of a malicious attack. Adding a mitigation strategy means adding features and code to a project. Before presenting the needed mitigation strategies, the main categories of threats must be introduced:

• Spoofing: an attacker impersonates someone else (Fig. 4.11).

• Tampering: an attacker modifies informations in a illegitimate manner (Fig. 4.12). It is also known as ’sabotage’.

• Repudiation: legally speaking, repudiation of a contract means a refusal to perform the duty or obligation owed to the other party. In this case, non-repudiation refers to a

(43)

situation where a statement’s author cannot successfully dispute its authorship or the validity of an associated contract.

• Information disclosure: an attacker illegitimately obtains sensitive data that can compromise the security or privacy of systems and persons.

• Denial of Service: an attacker compromises the system’s availability.

The following table summarizes the just described threats with their property and mitigation approaches:

THREAT PROPERTY MITIGATION APPROACH Passwords

Spoofing Authentication Multi-factor auth Digital signatures Access Control Rules Tampering Integrity Digital signatures

Hashing Repudiation Non-repudiation Digital signatures

Access Control Rules Information disclosure Confidentiality Encryption

Access Control Rules Denial of Service Availability Filtering

Redundancy

4.5.4 Enforcing trust between organizations

Previously, mutually trust between organizations has been assumed. This assumption may be not always true due to conflicting business objectives. In a blockchain-based system, the way in which consensus is reached became a fundamental aspect: the selection of a certain consensus algorithm, instead of another one, may require strongest assumptions on the threat model. In the specific case of enforcing trust between organizations (the different entities that belong to the supply chain: farmers, makers, couriers, sellers) a byzantine fault tolerant algorithm is sufficient. Hyperledger Fabric solves this problem providing an implementation of PBFT algorithm.

(44)

5. Project definition and implementation

The present chapter will go through all the phases for the definition and implementation of the project. Starting from the analysis of the case study presented in the previous chapter, a formal definition of the project entities, components and functionalities will be given. Hyperledger Composer can be used to define a logical model containing the rules that dominate the business case. The model represents the way in which parties exchange assets and how data will be stored, maintained and reached, but also the access policies (who can do what). The rest of the chapter will first introduce the main components behind Hyperledger Composer and successively threat the modelling and implementation phase.

5.1 Hyperledger composer components

As explained during the discussion regarding the usage of blockchain technologies in business environments, a suitable application scenario consists in two or more parties that share the same database with conflicting interests from the business point of view. Inside Hyperledger these parties are identified asorganizations. Practically speaking, this application scenario will be composed by four parties:

• Farmers Organization • Makers Organization • Couriers Organization • Sellers Organization

An organization has the responsibilities of submitting transactions, creating new partici-pants and enable them to submit transactions on the blockchain by creating the corresponding crypto material. Organizations can independently develop any kind of application that can be used from their participants in order to communicate with the blockchain. Organizations are the only entities that are allowed to deploy the business network. Once organizations are

(45)

identified, many other parts must be defined. The business network contains the definition of the following components:

• Participants • Assets • Transactions • Queries

• Access Control

All of them will be defined using specific languages. The set of definitions will create the so called business network archive (BNA) that will be used to deploy the business network. Here follows a description of the previously cited components:

Participants:

Participants are the members of the network and are identified using an ID. A participant submits transactions (exchange assets, stores data, etc). Each submitted transaction is signed by means of the private key of the participant that invokes it. A participant cannot create other participants.

Assets:

Assets are goods, services or properties belonging to participants. They are associated with participants or with other assets and are identified using IDs. Example of assets are houses, coins, devices or batches of olive (as in this case study).

Transactions:

Transactions are the mechanism through which participants can interact with assets. A conveyancing is traced using a transaction invoked by a participant that owns the asset of interest.

Queries:

Queries are used to return data from the blockchain. A query is invoked using the Hyper-ledger Composer API.

Access Control:

(46)

5.2 Definition of components 37 For example, only the owner of a vehicle can transfer ownership of that vehicle.

5.2 Definition of components

5.2.1 Participants

In the presented use case participants are represented by the various farmers, makers, couriers and sellers that partecipate to the supply chain process. Each one of these participants will be authorized to invoke transactions passing through its reference organization. For example, a ‘farmer A’ is authorized to write on the blockchain from the ‘Farmers organization’ and so on.

Fig. 5.13 Business network architecture

When a transaction is invoked by a participant, permissions are checked and business logic is applied in order to verify the correctness of the transaction. If the transaction is valid it is signed and added to the blockchain.

5.2.2 Assets

All the remaining data that must be stored in the shared database will be modelled as assets. Some of them will be created and exchanged between parties, whereas others will not be exchanged. Summing up, there will be two different types of assets: exchangeable and non-exchangeable assets.

(47)

Exchangeable assets:

• Batch of olives: this asset can be initialized by a farmer, specifying its ID, its farming and harvesting process IDs and a set of attributes (e.g., creationDate, year, ...). During the process it is associated with informations regarding its shipment and its production process.

• Product: this asset can be initialized by a maker, specifying its ID, its batch of reference, its basement of reference and a set of attributes (creationDate). During the process it is associated with informations regarding its shipment.

Non-exchangeable assets:

• Plantation: it is created by a farmer. Contains informations regarding the owner and a set of attributes (latitude, longitude). It is identified through its ID.

• Farming process: it is created by a farmer. Contains informations regarding the plantation of reference and a set of attributes (year). It is identified through its ID. • Harvesting process: it is created by a farmer. Contains informations regarding the

plantation of reference and a set of attributes (begin, end, harvesting method). It is identified through its ID.

• Batch shipment: it is created by a courier. Contains informations regarding its creator, a set of references to batches to which it is dedicated and a set of attributes (begin, end). It is identified through its ID.

• Production process: it is created by a maker. Contains informations regarding its creator, the batch of reference and a set of attributes (begin, end). It is identified through its ID.

• Basement: it is created by a maker. Contains informations regarding its owner and a set of attributes (latitude, longitude). It is identified through its ID.

• Product shipment: it is created by a courier. Contains information regarding its creator, a set of references to products to which it is dedicated and a set of attributes (begin, end). It is identified through its ID.

• Sensor measurement: it can be created by all the parties in order to store informations regarding measurements performed during the various subprocesses. Informations

(48)

5.2 Definition of components 39 contained in a sensor measurement asset depend by the process to which it refers to. A better definition will be provided successively.

• Shop: it is created by a seller. Contains informations regarding its creator and a set of attributes (e.g., latitude, longitude, name). It is identified through its ID.

• Order: it is created by a seller. Contains informations regarding the shop of reference and a set of attributes (e.g., quantity of products, creation date). It is identified through its ID.

5.2.3 Transactions

Participants interact with the blockchain by invoking transactions. A transaction consists in writing data in the database. For example, in cryptocurrencies a money transfer consists in submitting a transaction with all the informations related to this operation like the identifiers of the two parties, the amount of money and the timestamp related to that operation. In the presented use case, lot of transactions will be submitted by different parties. Obviously, different parties will invoke different types of transactions (e.g., a maker will not be able to transmit informations regarding the farming or harvesting processes). In the following description, transactions will be presented by indicating their descriptions and the parameters that must be specified for the correct submission.

1. create new Plantation (newPlantation)

• Description: creates a new instance of ’Plantation’ asset

• Parameters: requires an identifier, latitude and longitude coordinates. 2. create new Farming Process (newFarmingProcess)

• Description: creates a new instance of ‘FarmingProcess’ asset.

• Parameters: requires an identifier, the plantation identifier to which it is referred, the year of reference.

3. start Harvesting Process (startHarvestingProcess) • Description: sets the harvesting begin field.

• Parameters: requires a timestamp in which the transaction is submitted. 4. end Harvesting Process (endHarvestingProcess)

A blockchain-based system for IoT-aided certification and traceability of EVOO