InvestigatingtheApplicabilityofBlockchainandSmartContractsRobinWesterlund DecentralizedReservationofSpatialVolumesbyAutonomousVehicles

Full text

(1)

Master of Science in Engineering: Game and Software Engineering June 2020

Decentralized Reservation of Spatial

Volumes by Autonomous Vehicles

Investigating the Applicability of Blockchain and Smart

Contracts

Robin Westerlund

(2)

This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfilment of the requirements for the degree of Master of Science in Engineering: Game and Software Engineering. The thesis is equivalent to 20 weeks of full time studies.

The authors declare that they are the sole authors of this thesis and that they have not used any sources other than those listed in the bibliography and identified as references. They further declare that they have not submitted this thesis at any other institution to obtain a degree.

Contact Information: Author(s):

Robin Westerlund

E-mail: rowe15@student.bth.se

University advisor: Professor Kurt Tutschku

Department of Computer Science

Faculty of Computing Internet : www.bth.se

(3)

Abstract

Background. Due to the rising popularity of autonomous unmanned vehicles, and the lack of well-defined rules to follow, a solution is needed when the physical space is crowded to a point where it becomes a hazard. Partitioning space discretely is cur-rently done in some cases, allowing vehicles to reserve partitions to operate within. This idea is expanded upon to ultimately propose a blockchain-based solution to the inefficiency of safety margins.

Objectives. The main objective was to explore whether a blockchain-based system can be used by vehicles to automatically reserve the volumes of space they need for a limited time. The solution to congestion becomes a method for vehicles to commu-nicate between each other to exchange the remainder of their reservations once they are no longer needed, even while disconnected from the main blockchain network, in exchange for the same currency used to reserve the volumes.

Methods. An Ethereum private blockchain network is set up, and a smart con-tract is developed and deployed onto this blockchain. An emulation program used the smart contract functions to reserve and exchange volumes to evaluate the func-tionality, several isolated tests evaluated the network performance, and aspects that could not be tested were theoretically analyzed.

Results. The system functions as intended, although a level of trust is required during exchanges. There is no risk of two vehicles reserving the same volume at the same time. The results indicate that some performance aspects will be affected by an increasing number of users, although the entire effect can be placed on synchro-nization time if the network parameters are adjusted. This likely affects the overall efficiency but not as much as it would with the original parameters.

Conclusions. The proposed solution is viable to use, although further development is necessary before it is ready for release. The necessity currently is not evident, although projections suggest that this solution, or a similar one, will be necessary in the future.

Keywords: reservations, smart contracts, blockchain, zero-trust.

(4)
(5)

Sammanfattning

Bakgrund. På grund av den ökande populariteten av autonoma obemannade for-don, och bristen av väldefinierade regler att följa, behövs en lösning när det tillgäng-liga fysiska utrymmet används så mycket att det blir en fara. Diskret uppdelning av utrymme är något som har gjorts tidigare i några fall, för att låta fordon reservera dessa delar för att få vara i dem. Den idén utvecklas vidare för att föreslå ett sys-tem baserat på blockkedjeteknik som bidrar med en lösning till ineffektiviteten som säkerhetsmarginaler medför.

Syfte. Huvudsyftet var att utforksa möjligheten för autonoma fordon att använda ett blockkedjebaserat system för att reservera utrymmen de behöver automatiskt under en begränsad tid. Lösningen till trängselproblemet är ett sätt för fordon att kommunicera med varandra för att utbyta reservationer som fordonet inte längre behöver trots att det finns tid kvar, även utan uppkoppling mot huvudnätverket, i utbyte mot samma valuta som används för att reservera utrymmena.

Metod. Ett privat blockkedjenätverk skapas med Ethereum, och ett smart kontrakt utvecklas och läggs upp på blockkedjan. Ett emulationsprogram använder det smarta kontraktets funktioner for att reservera och utbyta utrymmen för att utvärdera funk-tionaliteten, ett flertal isolerade test utvärderar nätverkets prestanda, och aspekter som inte kunde testas analyseras teoretiskt.

Resultat. Systemet fungerar som tänkt, dock behövdes en nivå av tillit mellan for-don under utbyten. Det finns ingen risk att två forfor-don reserverar samma utrymme under samma tid. Resultaten indikerar att vissa prestandaaspekter kan påverkas av ett ökat antal användare, men hela effekten kan placeras på synkroniseringstiden om nätverksparametrarna ändras. Detta skulle då troligtvis påverka effektiviteten över-lag, men inte lika mycket som det hade gjort med de ursprungliga nätverksparame-trarna.

Slutsatser. Den föreslagna lösningen är möjlig att använda, men vidareutveckling behövs innan lösningen är redo att användas. Den nuvarande nödvändigheten är inte uppenbar, men det förväntade läget antyder att denna eller en liknande lösning kommer vara nödvändig i framtiden.

Nyckelord: reservationer, smarta kontrakt, blockkedja, noll förtroende.

(6)
(7)

Acknowledgments

I would like to thank Dewire1, specifically Johanna Edström, for the opportunity

to work with them, and making the thesis work more interesting and educational than I would have expected. Special thanks to my supervisor Johan Deckmar for the insightful ideas, tips and the overall subject knowledge I lacked initially, aside from the very helpful regular meetings.

A big thank you to my supervisor at Blekinge Institute of Technology, Professor Kurt Tutschku, without whom the scientific aspects would likely not have met the same standards. Even though the subject may have been further from his area of expertise than expected, I could not have asked for a better supervisor.

Additional thanks to family and friends, especially my partner Jenny, for enduring my lengthy rants on various problems, and continuously reading new additions to the report looking for any mistakes I may have missed.

1https://www.dewire.com/

(8)
(9)

Contents

Abstract i Sammanfattning iii Acknowledgments v 1 Introduction 1 1.1 Background . . . 1

1.2 Physical Volume Reservation . . . 2

1.2.1 Blockchain . . . 3

1.2.2 Vehicular Communication for Volume Exchanges . . . 5

1.3 Thesis Outline . . . 6

2 Related Work 7 2.1 Volume Reservation . . . 7

2.2 Decentralized Applications . . . 8

2.3 Smart Contract Automation . . . 9

2.4 Traffic Synchronization and Communication . . . 10

2.5 Summary . . . 11

3 Method 13 3.1 Research Questions and Motivation . . . 13

3.2 Limitations and Considerations . . . 14

3.3 Technology and Methodology . . . 15

3.3.1 Development Methodology . . . 16 3.3.2 Blockchain . . . 16 3.3.3 Smart Contract . . . 17 3.3.4 Emulation . . . 19 3.4 Evaluation . . . 22 3.4.1 Functionality . . . 22 3.4.2 Hardware Requirements . . . 24

3.4.3 Abstraction of Vehicle-to-Vehicle Communication . . . 25

3.4.4 Blockchain Network Performance . . . 25

3.4.5 Security . . . 27

(10)

4 Results and Analysis 29

4.1 Functionality . . . 29

4.1.1 Standard Volume Reservation . . . 29

4.1.2 Vehicle-to-Vehicle Exchange . . . 30

4.1.3 Emulation Performance . . . 33

4.2 System Resource Consumption and Performance . . . 36

4.2.1 Storage Requirement . . . 36

4.2.2 Computational Complexity . . . 37

4.2.3 Data Package Size . . . 38

4.2.4 Synchronization Time . . . 38

4.2.5 Smart Contract Execution Cost . . . 39

4.2.6 Transaction Throughput . . . 40

4.3 Additional Parameter Review . . . 41

4.3.1 Communication Parameters . . . 41

4.3.2 Synchronization Time . . . 42

4.4 Analysis . . . 43

4.4.1 Security . . . 43

4.4.2 Safety . . . 43

4.4.3 Technology Readiness Level . . . 44

5 Discussion 47 5.1 General Volume Reservation . . . 47

5.2 Vehicle-to-Vehicle Volume Exchange . . . 49

5.3 Performance . . . 50

5.4 Security . . . 52

5.5 Functional Viability . . . 53

5.6 Benefits . . . 53

5.7 Summary . . . 54

6 Conclusions and Future Work 57 6.1 Future Work . . . 59

6.1.1 Present and Future Necessity . . . 59

6.1.2 Solution Comparison . . . 59

6.1.3 Extended Testing . . . 60

6.1.4 Traffic Management and Finance . . . 60

References 61

(11)

List of Figures

1.1 Conceptual image showing a 3x3 set of spatial volumes, where some are reserved by different actors, denoted by the colors red and green. White and grey volumes are not currently reserved. . . 3 3.1 Visualization of the simulation program. Vehicles (circles) travel along

their path rented through the smart contract on the blockchain. Note that the green vehicle exchanged one of their nodes with the pink vehicle. 21 4.1 Visualization of the logical protection against overlapping reservations. 29 4.2 Output of the test of logical protection against overlapping reservations. 30 4.3 Output of the test of whether two accounts could reserve the same

volume at the same time. . . 30 4.4 Output of the test of creating and signing a transaction offline, and

publishing it when the connection is back, with an intermediate step of attempting to publish the transaction offline. . . 31 4.5 Output of the test in which a different account from the one that

created and signed the transaction publishes the transaction. . . 32 4.6 Output of the test in which the creator of a transaction attempts to

invalidate the transaction it created. . . 32 4.7 The total time for vehicles to reach their destination based on the

distance, separated by the number of vehicles in the emulation the data is taken from, as well as the settings for the emulation. . . 34 4.8 Plots detailing the time it takes to attempt a reservation via algorithm

1. Separated into successes and failures, with and without outliers. . . 35 4.9 Plots showing the gas usage per transaction for 200 transactions on

different volumes, the same volume, and changing owner. . . 39

(12)
(13)

List of Tables

4.1 Average speed of vehicles in pixels/second for varying amounts of ve-hicles and different emulation settings. The data includes a confidence interval of 95% . . . 34 4.2 Block and average transaction size depending on the number of

trans-actions for RentNode. . . 37 4.3 Block and average transaction size depending on the number of

trans-actions for ChangeOwner. . . 37 4.4 Average time in seconds between one block and the next for each

node based on the number of nodes in the network and the number of transactions in the block. A confidence interval of 95% is applied to the average values. . . 38

(14)
(15)

List of Algorithms

1 Recursive function for volume reservation by vehicles. . . 20

(16)
(17)

Chapter 1

Introduction

1.1

Background

Autonomous unmanned vehicles (AUVs) are rising in popularity across several fields, ranging from military reconnaissance vehicles to postal delivery drones (e.g. Prime Air), or self-driving cars [15, 29]. Due to being a fairly new concept, there is no well-defined set of principles or rules to follow as there is for general car traffic [9]. As such, there needs to be a way to streamline the process of getting from one place to another, without human interaction. In developing a framework for AUVs to operate without disruption, the most important focus is safety. One might think that this is simply solved with collision aversion. However, if it becomes necessary to avoid a collision, the safety is already compromised. In such a situation, a gust of wind might be enough to cause a collision as vehicles would likely be close to each other at that point.

Should several AUVs be near each other, there is a need for them to keep a safe distance. This can be achieved by partitioning the physical space and only allowing one vehicle to inhabit a volume of space for a duration of time. Similarly to lanes on the highway, where a car can drive parallel to another in a different lane, knowing that there is no risk of collision thanks to the partition. Even though this example only has a divider in one dimension, it works similarly due to the driver’s responsibility of ensuring the lane next to them is free before switching. With space partitioning also comes the possibility of reserving a full route from start to finish, ensuring that no unexpected obstacles will appear during the trip, as long as every vehicle respects the reservation. In knowing that the path will be free for the duration of the reservation, the need for collision aversion technology may even be removed completely, unless the vehicle moves through dense areas. Partitioning physical space is already used as a means of increasing the safety for unmanned traffic, where actors may reserve volumes of space during some time [25, 18]. Note that certain traffic already abide by certain rules, such as road traffic and airplanes, and the intent is not to disturb or change those rules.

The main problem arises when several actors need to abide by the same set of rules. How the rules will be enforced, and how different actors will communicate when they have had no prior contact are two important questions. One solution may be to allow a central entity to control the reservation of space, while not allowing any vehicle to occupy that space if they have not reserved it. The question of enforcing this rule remains open, though that is outside of the scope of this study. A model like this brings its problems, such as the need for communicating with the central entity

(18)

2 Chapter 1. Introduction where it might not be possible. To create the proposed system for route reservations, it needs to be robust enough to not allow accidents to happen at any time, regardless of the reason. In a realistic scenario, a network operator would provide this service, while the authorities will control the space. Should other actors provide the same or a similar service, they would need to cooperate with the authorities as well, in order to not create any conflicts between the operators. Note that vehicles that are not autonomous that operate within the same space would have to follow the same rules as autonomous vehicles, although the solution is designed to work with autonomous vehicles.

This thesis proposes a decentralized approach for handling crossing paths of AUVs, specifically in the case of lacking communication with a centralized sys-tem, and possibly to replace the centralized approach entirely. This is accomplished through peer-to-peer communication using a zero-trust principle (explained in section 1.2.2 via blockchain technology, handling the reservation of space through smart con-tracts. Not only will this create a secure ledger of transactions within the blockchain, but it will also allow for a dynamic exchange of space in real-time between different vehicles, without requiring any prior contact or agreement.

1.2

Physical Volume Reservation

The specific problem being tackled in this study is the reservation of physical space for AUVs to occupy [25, 18]. A vehicle in this sense is any type of vehicle, e.g. drones, submarines, forklifts. The core concept of volume reservation is that a vehicle, or the owner, reserves a chunk of the space for a period to perform a task within the chunk. Having reserved that space, the vehicle does not need to expect disturbance from other vehicles, as they will have to wait for their turn to reserve the same space for themselves. For this experiment, physical space will be discretely divided into three-dimensional volumes with an arbitrary shape, as the solution only refers to them by three-dimensional coordinates.

Figure 1.1 shows how a discrete partitioning of physical space might look like. The white and gray volumes are not currently reserved, while the green and red volumes are. The green and red volumes may therefore only be inhabited by the corresponding vehicles. Another vehicle may reserve free volumes if they wish to do so, or wait until the reservation period has ended for the currently reserved volumes. As some vehicles are able to move in three dimensions, the solution will support three dimensions as well.

(19)

1.2. Physical Volume Reservation 3

Figure 1.1: Conceptual image showing a 3x3 set of spatial volumes, where some are reserved by different actors, denoted by the colors red and green. White and grey volumes are not currently reserved.

all vehicles to be connected to the server, or the internet, at all times. The peer-to-peer network solution will not only be more robust, working in any conditions aside from hardware malfunctions, but it will also reduce expenses in terms of hardware and the cost of reserving the space if they can sell it immediately after leaving if someone is willing to buy. The exchange of spatial volumes between vehicles is pos-sible to make while offline (disconnected from the main network) entirely using this approach, and all transactions will be stored immutably within a blockchain. The evaluation of the solution will be limited to an emulation of the functionality and isolated performance tests. The following sections describe the concepts and their purpose within the system.

1.2.1

Blockchain

(20)

4 Chapter 1. Introduction processing power of the miners in a proof-of-work network. For a proof-of-authority network, the block time is selected by the creator of the network. This project makes use of the Ethereum blockchain1 which introduces the concept of gas. For

each transaction, an amount of gas based on the processing power needed to execute the transaction is required. The price of a unit gas is chosen by the user making the transaction, and a higher gas price will prioritize the validation of that transaction, as validators recieve the payment in gas as a reward. In order to remove the possibility of transactions being published several times, Ethereum also uses a transaction nonce with every transaction, which is the number of transactions that user has done. Using a blockchain is suitable for decentralized applications due to the design following the aforementioned zero-trust principle, ensuring that sensitive information stays with the owner, with the only information being public is a user’s address, which is derived from the public key, which is used to prove that a transaction is signed with the private key associated with the address. The public key does become known once a transaction is made, however, it is regarded impossible to derive the private key from the public key, rendering the public key useless to an attacker that does not also have the corresponding private key [39].

Smart Contracts

A smart contract is a set of functions and state variables where the functions are called to change or query the state. Smart contracts are generally deployed on a blockchain. The idea of a smart contract came before the blockchain, however, blockchain technology proved to be a suitable platform to deploy these contracts on a larger scale [22]. An example of a type of smart contract prior to blockchain technology is ticket machines. When buying a ticket from a machine, the price is already set, and the machine will print the ticket once the buyer has signed the transaction (likely with their credit card PIN). The contract is smart, however, the buyer still needs to trust the owner of the machine, as well as the machine itself.

Smart contracts are made up of code, for example in the programming language Solidity, and deployed on a blockchain, for example, Ethereum [20]. Once deployed, they are public and cannot be altered, giving anyone a clear set of terms if they are interested in using it. It should be noted, however, that a smart contract is not inherently "smart", as the developer decides the terms which may be vulnerable to malicious actors. By design, should some part of a smart contract be vulnerable, the transactions are still validated and stored. This means that if a contract is exploited to steal currency, the transaction will be considered legitimate. In June 2016, the Decentralized Autonomous Organization (The DAO) was the target of an attack, resulting in a loss of approximately 60 million USD of their investors’ money [22, 35]. The anonymous nature of the blockchain made it impossible to identify the party responsible, however, the money was able to be tracked to a bank account. To recover the stolen currency, the Ethereum developers implemented a hard fork, making the blockchain split in two. This action was controversial. As users expect transactions to be final, the currency legally belonged to the thief and Ethereum technically stole from them. Naturally, due to being fairly new technology, the smart contract is not

(21)

1.2. Physical Volume Reservation 5 yet perfected, although the functionality is there in theory.

1.2.2

Vehicular Communication for Volume Exchanges

In order for vehicles to be able to exchange volumes, they will need a way to commu-nicate. Nodes in a blockchain will always hold a copy of the entire blockchain, which means that they will have the information necessary to exchange volumes locally. Therefore, they are able to exchange volumes while disconnected from the network if they can communicate in that situation as well. As opposed to the more traditional client-server architecture, where the client will send and receive data from a server, Peer-to-Peer (P2P) means that any actor will act as both a client and a server. In a client-server network, the client will need a connection to a server to communicate with other clients and to request or receive any service. P2P communication is ideal for this solution since two peers can communicate as long as they are within range of each other. In a blockchain network, P2P communication is key, as the network be-comes centralized once users are required to connect to a server [4]. Maintaining the decentralized aspect therefore is another motivation in using P2P communication.

Trust is important within a P2P network, especially for physical entities where their behavior depends on the information they receive. Huang and Fox defined trust as the combination of three components: Expectancy, Belief in expectancy and Willingness to be vulnerable for that belief [14]. Sumra et al. applied these components to vehicular P2P communication to quantify trust in a Vehicular Ad Hoc Network (VANET), and went on to propose three trust levels based on the aforementioned components: Strong Trust, Weak Trust, and Zero Trust [31]. For the proposed system in this thesis, there is zero trust between vehicles, as they will belong to different actors and therefore behave differently. The system will need to work in a way that is invulnerable to malicious actors, as well as providing unambiguous information that can be interpreted by any vehicle.

Zero-Trust Principle

Since the system is intended to support any willing participants, one might have doubts about the security. In a client-server network, the client only needs to trust the server, with the trust being required to use the offered services. However, in a peer-to-peer network, every client is a server as well, meaning trust would have to be placed with every peer that may be interacted with. Therefore, a suitable approach is to assume that no actor in the network should be trusted. The zero-trust principle also includes the assumption that the network itself is hostile, having internal and external threats at all times [11].

(22)

6 Chapter 1. Introduction the intent is only to pass the space. This introduces the problem of knowing which vehicle to contact. In a blockchain, the public key of the owner will be known, al-though an interested party will not know whom to contact. Mapping public keys to contact information will make the system vulnerable to attacks, although it would be a simple solution. A possible solution would be to broadcast a message asking for the owner of a specific volume, where the owner would respond with the status of the volume, being available or not, then establishing a connection for the exchange if available. Should the exchange pass, a signed receipt would be passed to the request-ing vehicle before closrequest-ing the connection, allowrequest-ing the new owner to prove ownership if necessary prior to the transaction being public. This approach is likely as secure as it will be, given the circumstances, but there may be room for improvement in the future.

1.3

Thesis Outline

This project aims to prove the concept of decentralized trading of volumes for au-tonomous vehicles using smart contracts via a blockchain network. The main focus will be to evaluate whether a system like this is viable in practice, as well as con-structing a method for secure offline trading in the case of lost connection. The thesis will adhere to the following structure:

• Chapter 2 - Related Work: Survey of past literature on the subject, pro-viding background to the problem area and existing solutions to consider. • Chapter 3 - Method: Documentation of the development process, as well as

any decisions and considerations made during the project along with motiva-tion. This section also describes which metrics are used to find the conclusion and why.

• Chapter 4 - Results and Analysis: Includes all data collected from testing the finished system, along with a detailed interpretation of the data, constitut-ing the basis for the answers to the research questions leadconstitut-ing to a conclusion. • Chapter 5 - Discussion: Argumentation regarding the validity and signifi-cance of the results, analysis of the method and its impact on the results, and interpretation of any anomalies that may present themselves in the results. • Chapter 6 - Conclusions and Future Work: The final verdict

(23)

Chapter 2

Related Work

This chapter will explore related work from the main concepts used to develop the solution. Due to the main concepts, or the application of them, are fairly new, it was impossible to find work that is directly related. While there is not currently a lot of work done, there is a clear demand for it. Aside from the attempts at au-tomating deliveries and reconnaissance, events such as The 2020 IEEE 91st Vehicular Technology Conference1 specifically solicits work in the area [15, 29]. Searching for

the topics together in several databases through Summon@BTH and Google Scholar produced no relevant results. Instead, searching for the topics individually yielded interesting work that aided directly in the design and evaluation of the developed solution. Instead of briefly describing many works that are not directly related, it was chosen to describe relatively few works that will directly aid the design in detail. The following sections explore the main concepts and explain their relevance.

2.1

Volume Reservation

An article by Roberta Fusaro et al. suggests solutions to problems arising when allowing unmanned aerial vehicles into existing airspace [10]. The article suggests that reserved airspace should not be reserved permanently, to improve capacity in general. They suggest a time-based separation to resolve conflicts between aircraft of different types, where an aircraft is given a set amount of time to pass a certain volume of airspace. It is noted, however, that a system like this is not entirely secure since that would require all air traffic to be connected to the system and the density of the traffic needs to be low enough to be able to route around it. Therefore, a system for automatic collision avoidance is still required. It is hypothesized that the separation in volumes over time improves the efficiency of the usage of airspace, while not compromising the safety as long as there is a defined order of yielding when traffic cannot be avoided. It is concluded that a system like this will improve the usage of unmanned aerial vehicles in both operative and emergency scenarios, although the procedure will need to be tested with more complex scenarios and the results need to be analyzed in-depth. The article relates closely to the proposed partitioning of volume and the expected benefit of doing so in the field of autonomous vehicles. Although the article only examines manually controlled aircraft, being remote-controlled unmanned aircraft and civil aircraft, the reservation of space over some time and the benefit in efficiency will carry over to the results of this thesis.

1https://events.vtsociety.org/vtc2020-spring/

(24)

8 Chapter 2. Related Work A method for Conflict Detection and Resolution (CDR) based on the expected future demand of Unmanned Aerial Vehicles (UAVs) is proposed by Ho et al. to ensure conflict-free paths before take-off [13]. The method is based on the reservation of airspace in 4DT (3D plus time Trajectory), as opposed to the traditional 3D, with the help of Multi-Agent Path Finding (MAPF) to account for other vehicles as well. Standard MAPF assumes that every agent starts at the same time, with a set start and goal, which poses a problem when UAVs may have different start times and may not have a set goal. The article examines the Sendai 2030 Model Case, which predicts up to 21, 000 operations per day of delivery service (being 13 hours) in an area of 14.35km ∗ 17.10km. A simulation shows the number of conflicts while using only in-flight CDR, being about 0.828 per operation or roughly 5 out of 6, demonstrating the need for pre-flight CDR. Ho et al. conclude that with a large volume of operations carried out by UAVs, simple 3D space reservation is not viable as the entire space would be reserved for the duration of the operation, limiting available space for others. The results do, however, only apply to the Sendai 2030 Model Case, which does not include the full complexity of air traffic. The article focuses on the implications of a higher volume of UAVs and stresses the need for efficient usage of space, which relates to the purpose of this thesis. They discuss discrete space partitioning as future work, called corridors in their case, which is what will be implemented for the evaluation of this system. The article does however only concern air traffic. While air traffic is the most common form of autonomous vehicle due to being relatively simple, this thesis intends to create a broad solution for any applicable case.

2.2

Decentralized Applications

(25)

2.3. Smart Contract Automation 9 execution, if a system such as this is to see any use. The benefits and detriments of using a DApp as opposed to a traditional application are also important to consider, which are outlined in this paper.

The use of blockchain technology for decision record-keeping in autonomous ve-hicles was explored by Sekan Ayvaz and Salih Cemil Cetin to irrefutably determine which vehicle is responsible in case of an accident between two autonomous vehicles [28]. The purpose is to hold the correct party responsible in case of an accident, as well as provide the necessary information to eliminate the possibility of a similar accident occurring in the future. The motivation for the research is the development of autonomous vehicles in recent years, which indicates that people soon will entrust their lives with machines, should they be safe enough. Since many manufacturers will have different components and algorithms, one vehicle’s decision making may conflict with another enough to cause an accident. The solution model, called "Witness-of-Things", combines distributed ledger technologies with vehicular communication, and stores all information on the blockchain, creating a tamper-proof, public record of events. The article discusses the potential drawbacks of a blockchain-based system, most notably the scalability with a growing blockchain and balancing mining diffi-culty between protection and validation latency. While a prototype is not developed, the theoretical model describes a system that can work to make vehicles "witnesses" and thereby improving the safety of using autonomous vehicles. Although smart contracts are not proposed as a means of using the blockchain, this article supports the idea of using a blockchain to keep tamper-proof records in a vehicle-to-vehicle scenario. Furthermore, it discusses the potential detriments of using a blockchain if a connection cannot be guaranteed, as well as if the computing power is limited. These points will have to be considered in developing the blockchain-based system for this thesis.

2.3

Smart Contract Automation

(26)

10 Chapter 2. Related Work There may, however, be a delay compared to traditional systems due to the time it takes to verify a block. The article concludes that a system similar to the one devel-oped may be used to improve patient privacy, as well as improve medical data storage with automated formatting, providing more reliable data for further research. While the topic of the article, being healthcare, does not relate to the topic of this thesis, the technology used is the same. The article shows that smart contracts are not only automated by default but may also be called automatically. Using smart contracts for autonomous vehicles will work in a similar manner, where the path planning soft-ware will call a contract to reserve space without any human interaction, aside from setting a destination.

Khaled Salah et al. conducted a review of the possibilities of combining Artificial Intelligence (AI) with blockchain technology, due to the decision-making capabili-ties of AI and the secure, record-keeping and trusted nature of the blockchain, as well as the possibility of automating transactions in a blockchain [27]. The purpose of the study is to evaluate if these two fairly new technologies may be combined into something more powerful, suggesting several applications of the combination as well as surveying existing decentralized AI applications. The article discusses how blockchain can improve (or transform) AI in several ways, such as improving trust, security and enhancing decision making due to the public and secure nature of the blockchain. The combination could also serve to improve efficiency in business with Decentralized Autonomous Organizations (DAOs) to avoid lengthy processes in transferring assets between stakeholders. The authors proceed to describe vari-ous applications for the combination of AI and blockchain, as well as the types of infrastructures to support them. Several challenges introduced by the combination are highlighted, such as privacy, scalability, and security, due to the nature of the blockchain being public, the entire blockchain needing to be stored locally, and the possibility of attacks. The possibility of attacks is larger with a smaller network since an attack with more than half of the network’s computing power will be able to modify the chain, given that a blockchain works on a majority consensus principle. The article concludes that the concept of combining AI with blockchain technology is still at an early stage, with several challenges needing to be solved before adopting the combination. It is important to consider the detriments of using a blockchain with actors powered by AI since their decisions are solely based on logic. Further-more, the challenges presented are valid for the proposed system in this thesis as well, although not to the general extent described, due to the information stored not being sensitive, for example.

2.4

Traffic Synchronization and Communication

(27)

2.5. Summary 11 while the following would communicate the price they were willing to pay. Should the number from the following vehicle exceed the number from the leading, the ve-hicles would determine if the maneuver was possible, and if so, the maneuver would take place. With this solution, it is possible to pay to reach a destination faster in dense traffic, and the time it takes to reach a destination becomes directly related to the price, provided that it is possible to execute the maneuver. The paper stud-ies the possible benefits of direct communication, as well as the idea of automated transactions between vehicles (although not suggesting a payment solution), which are two central topics in this thesis. It does, however, focus mainly on road-vehicles, and the simulation is performed assuming one lane where all traffic is moving in the same direction. Limitations include traffic laws, multiple lane problems, and various other cases only present in general car traffic, which will all be disregarded for this thesis.

Ranran Ding and Qing-An Zeng proposed a vehicle-to-vehicle (V2V) communi-cation system based on clustering, with the purpose of low-latency communicommuni-cation between vehicles to avoid traffic accidents [7]. The paper expresses the benefits of V2V communication overall and stresses the importance of real-time information ex-change due to the fast movements of traffic in most cases. Ding and Zeng developed a system for clustering vehicles in which each cluster elects a cluster head (CH) with the rest of the vehicles being cluster members (CM). Each CM periodically sends its location, speed, and identification to the CH, which then distributes the information to each CM. With this system, a vehicle can evaluate its current level of safety based on moving speed and distance to other vehicles. This could be used by manually operated and autonomous vehicles to reduce the risk of collisions. As stated, the paper addresses safety and efficiency through V2V communication, which are some of the main concerns of this thesis. While clustering might not be necessary in this case, the idea of safe distances as well as positional information relay will be vital to the success of any V2V communication system developed. Although this thesis will concern discretely divided volume, safe distances will need to be considered due to the edges of the volumes.

2.5

Summary

(28)
(29)

Chapter 3

Method

3.1

Research Questions and Motivation

This thesis aims to design and implement a blockchain-based system, and evaluate whether it can be used to handle spatial volume reservation of autonomous vehicles or not. This is done by gathering data from the emulation of the system as well as from isolated tests in a quantitative approach, as well as covering other aspects through existing work and theoretical analysis. The purpose of this system is to increase the overall efficiency and safety of all types of autonomous vehicles, as physical space can be traded between vehicles without prior agreements and trust. To perform the evaluation, a proof-of-concept system was developed with the core functionality a system like this would have, along with an emulation of autonomous vehicles with primitive path-finding to observe how the system works. The system’s performance, functionality, and security are evaluated and analyzed in order to answer the following questions:

1. “Can a blockchain-based decentralized system be used for automatic volume reservation by autonomous unmanned vehicles?”

2. “Can blockchain technology be used by autonomous unmanned vehicles to ex-change reserved space via a zero-trust peer-to-peer system while disconnected from the main network?”

3. “Will the performance of a blockchain-based zero-trust peer-to-peer system be adequate in relevant real-time scenarios?”

4. “What security risks would a blockchain-based zero-trust peer-to-peer system pose?”

Answering these questions leads to the conclusion of whether this type of system is viable for replacing the traditional approach or not. Should the prototype be successful, it will pave the way for this type of system to be further developed into what will be used by autonomous vehicles commercially. Analyzing the performance and security of the system highlights possible challenges in developing a system like this for further development in the same problem area.

(30)

14 Chapter 3. Method

3.2

Limitations and Considerations

This section will describe the limitations and considerations within different areas of the solution which will hinder the answering of the research questions in sections 3.1.

Testing

Testing with real vehicles was not possible with adequate realism. A practical test would require more than a few vehicles on a local network, as several factors would not be present in that case. However, as detailed in chapter 2, it is known that vehicles can communicate with each other. It is also known that an autonomous vehicle can follow a path to a destination, otherwise they would not be autonomous. This means that the functionality of the system can be proven without testing on real vehicles. The communication range of autonomous vehicles is important for the peer-to-peer aspect, although, in this project, the range is assumed to be adequate at all times. Different types of wireless communication will be discussed, along with their benefits and detriments, and the required range for the implementation can be calculated based on vehicle speed, the size of the volumes and the length of time a volume may be reserved for.

Time

Due to working with time, given that volume reservations are limited to the time they are given, there needs to be a precise way of telling the time. However, a blockchain only has the current block time available, as system times may vary and network users need to agree to the timestamp the block holds. Therefore, the time given by a smart contract is not the current time, but the current block timestamp1. This

limits the precision somewhat, although workarounds are made to ensure that the lack of precision would not cause conflicts.

Finance

The financial aspect needs to be considered as well, as the operator of this system will likely require payment for the service, or at least compensation for the processing power used to validate transactions. Transactions through a smart contract on a blockchain come with a cost (in gas), which is dependant on the complexity of the smart contract function [38]. While the caller of the function decides what they are willing to pay for one unit of gas, they still want to offer an acceptable amount, as mining nodes decide their minimum gas price when mining. Note that function calls that do not modify the state of the contract do not require a transaction, and therefore do not cost gas. This project will disregard the cost of the service itself, as the functionality is what the project evaluates. The cost from using gas will remain, and the usage of gas will be analyzed, although the cost of a unit of gas will be standardized and disregarded.

(31)

3.3. Technology and Methodology 15 Validation

The fact that a blockchain system depends on peers validating transactions and appending them to the blockchain (mining) leads to the requirement of such peers. Each vehicle may be required by the system to mine to mitigate this problem, or the involved actors may be required to set up mining nodes to be allowed to operate in the system. Either way, it is important to consider the ecosystem of a blockchain to correctly implement and maintain a decentralized application [2]. It is important to limit the number of transactions performed in total and to optimize the smart contract to require as little computing power as possible if a system like this is to attract users. Generally, function calls will, however, require accessing memory within the smart contract which takes significant time, and should also be avoided when possible.

Trust

As covered in chapter 2, it is also important to consider the required mining com-plexity, as there needs to be a balance between protection and validation latency [28]. However, using a consensus protocol that assigns one trusted node to validate a block at a given time, rather than making it a competition, removes the issue. The fact that vehicles need to break the privacy of the blockchain by establishing a vehicle-to-vehicle connection through the information given in the transaction history may be a security concern. However, being able to connect a transaction history to an actor in this particular system is no critical concern, as the transactions will not con-tain any sensitive information. The contact information of every actor being public may open the possibilities for attacks. An attack on an autonomous vehicle would, however, require that the attacker is within communication range as well as having something to gain from the attack, which is far-fetched. Additionally, vehicles will likely have some level of protection against connections not behaving as expected. This solution removes mining, and thereby the majority consensus requiring trust in a few nodes instead. This weakens the zero-trust attribute, and the system be-comes less decentralized. However, since the owner still would provide the service in a fully decentralized zero-trust system, there would still have to be some level of trust in that owner. Therefore, the owner of the system can be responsible for the validation of transactions, resulting in no apparent difference in the system’s trust requirement and centralization. The actors using the service through the system still would not have to trust each other when performing transactions with each other, as the transactions will have to be validated by the trusted party.

3.3

Technology and Methodology

(32)

16 Chapter 3. Method

3.3.1

Development Methodology

The system was implemented in an agile, iterative manner, to be able to deliver as much as possible in the given time-frame. Due to developing the system iteratively, it was also possible to change the design during development to create the a best func-tionally and structurally possible system. Isolating each component of the system opened the possibility of estimating the time to implement, although nothing could be said about the time to connect the components. The implementation of the emu-lation was done in three two-week sprints, following the SCRUM-methodology2. The

following three weeks after the implementation of the emulation included planning and implementing the tests, as well as running and measuring the results.

3.3.2

Blockchain

Due to the system requiring more complex transactions than the usual sending or receiving currency, a blockchain with full support for smart contracts was necessary. Therefore, the Ethereum3 blockchain was used. Ethereum allows for simple

deploy-ment of smart contracts, and also provides libraries for interacting with the deployed smart contracts for several programming languages [1]. Ethereum specifically was chosen due to its extensive documentation and user-friendly test environments, since the project is experimental.

The Ethereum blockchain can be deployed through various means for testing purposes. For this project, Puppeth was used for deploying an Ethereum blockchain with the Clique consensus engine [30]. The resulting blockchain is functionally iden-tical to the main Ethereum network, although with a different consensus protocol. While being fairly cumbersome to configure and deploy, it was important to test the system on a real blockchain as opposed to a simulated testing environment, such as Ganache4, due to simulators working perfectly in all conditions with no

synchroniza-tion or validasynchroniza-tion to worry about, while also abstracting most of the complexity of a real node. The blockchain was deployed with 3 sealer nodes and 10 regular nodes, all of which are pre-funded to allow for making transactions. The sealer accounts serve only to validate blocks, acting as authorities in the system and not vehicles. For each account, there is one node, as opposed to having one node with all of the accounts since each account would be on a separate machine in a real scenario. Each node in the blockchain represents one vehicle. A live system would likely use more than 3 sealer nodes, however, using more sealer nodes is only relevant when the sealer nodes cannot handle the processing of all transactions in a timely manner, which would not be a problem in this case. This emulation could, in fact, function with one sealer node, although it was decided to use several in case there is a behavioral difference. The emulation itself uses up to 10 vehicles in a 10x10x1 space, this is deemed enough to show the functionality. The smart contract supports a third dimension, but the emulation would be difficult to visualize in three dimensions. Using the Raft consen-sus protocol was considered, due to its speed and that it does not create empty blocks [21]. Raft has no protection against bad actors though and even allows changing the

2https://www.scrum.org/ 3https://ethereum.org

(33)

3.3. Technology and Methodology 17 transaction history. If all actors could be trusted, this would not be an issue. During the testing of the system, where all nodes are trusted, Raft could be used, but the integrity of the results would be compromised if a more efficient consensus protocol was used when it would likely not be used in practice.

The method of reaching consensus within a blockchain is typically a Proof-of-Work protocol, where nodes compete by solving mathematical problems with random inputs until the desired output is received [34]. By adjusting the difficulty it is pos-sible to control the average time for one solution to be found based on the network’s total computing power [16]. In this system, validation of transactions will need to be as quick as possible to reduce wait times and improve efficiency. Simultaneously, the scale of the network will be relatively small compared to other blockchain networks, which would increase the risk of attacks due to automatically following the decisions supported by the majority of the network. Rather than using Proof-of-Work with a low mining difficulty, a Proof-of-Authority consensus protocol is used, which is suitable to achieve high throughput and low latency [37]. By cycling through trusted nodes and assigning them to validate transactions, computing power is not a con-cern. Given the reward usually provided when validating a block, there is a financial incentive in keeping the privilege for the involved nodes. The security concern, in this case, comes from the trust in these validating nodes, although the privilege of validating transactions would be revoked for a node if foul play is detected. In this network, the identities of actors will not be strictly hidden, meaning that aside from revoking validation privilege from an actor that abuses the privilege, punishment may be administered outside of the network as well.

Each vehicle is expected to have a unique account in the blockchain, as the public address of the account identifies the owners of volumes. This means that a single actor with a hundred vehicles (e.g. a delivery company) will have to create and maintain the same number of accounts, although this will likely be done automatically. To be able to sign transactions created while disconnected from the main blockchain network, each vehicle will also have to have access to its private key, which needs to be handled with care as the public address along with the private key grants complete control of an account in a blockchain. The reasoning behind this is covered in section 3.3.4.

3.3.3

Smart Contract

The smart contract used is written in the programming language Solidity through the Remix IDE5 and provides the following functionality (x, y, and z are 3D coordinates

corresponding to a volume of space):

• void UpdateNode(x, y, z): Private function to clear memory of obsolete reservations to avoid unnecessary storage.

• bool CheckAvailable(x, y, z, start, end): Returns whether or not the given node has a stored rental overlapping the start and end times provided as a Boolean.

(34)

18 Chapter 3. Method • void RentNode(x, y, z, start, duration, ip, port): Calls UpdateNode followed by CheckAvailable, if available, store the given node, the caller’s public address, start and end times (end time being start+duration), and the contact information (IP and port) provided. Emits a Solidity event6 containing the

state of success in the transaction.

• Actor GetOwner(x, y, z): Returns the address and contact information of the current owner of the given node if there is one, and null otherwise.

• int GetEndTime(x, y, z): Returns the end time in POSIX time of the current active rental of the given node, or 0 if the node is not currently rented. • void ChangeOwner(x, y, z, newOwner, ip, port): Checks that the caller is the current owner of the given node, then assigns the node to the address newOwner along with the IP address and port provided. Emits an event stating whether it succeeded or not.

• void AddTimeToRental(x, y, z, duration): Checks that the caller is the current owner of the given node, then increases the rental time by the number of seconds given by duration if the current reservations on the volume allow it. Emits an event stating whether it succeeded or not.

The storage within the blockchain is solved by using a mapping7, which is

essen-tially a hash table, where a hashed value of a node’s coordinates serves as the key, and the value is a list of reservations of that node. Reservations are defined as a struct8

holding the coordinates, owner, start, and end times for the reservation. During the rental of nodes, UpdateNode is called to reduce the overhead in searching through reservations when checking if the node is available. This also serves to reduce the overhead in calling several other functions requiring a linear search through the list of reservations. Reducing the number of calls to UpdateNode is also important, however, to reduce the processing power used in the blockchain, which is why the function is called exclusively in RentNode. The contract uses an experimental feature allowing a struct as a return value for GetOwner, which Solidity stresses should not be used in a production environment. This is, however, adequate for a proof-of-concept as the system is not intended to be used outside of the simulations, and returning a struct is equivalent to returning a tuple9 (which is not experimental) without the effort

of creating one before the function returns. While it was not necessary to use this experimental feature, it behaves the same as the built-in functionality without the overhead of creating a new object to return as the structure returned only contains standard data types.

6https://solidity.readthedocs.io/en/v0.4.21/contracts.html#events 7https://solidity.readthedocs.io/en/v0.4.21/types.html#mappings 8https://solidity.readthedocs.io/en/v0.4.21/types.html#structs

9

(35)

3.3. Technology and Methodology 19

3.3.4

Emulation

The emulation consists of two programs, being a Vehicle program and a Simulation program, which communicate between each other using TCP/IP sockets. The rea-soning behind separating the emulation into different programs is to show that the system works as separate instances, supporting the idea of the system working on different machines. The programs are written in Python 3.710 as Python provides a

library for interacting with Ethereum called Web3.py11. The programs are described

in detail below.

Vehicle

A program that simulates the behavior of a simple autonomous vehicle. Given a vehicles current position and a goal position it calculates the shortest path to the goal along a two-dimensional grid. It attempts to reserve the cells in the grid using the smart contract, contacts the owner of the cell if the reservation fails, and if the owner is unable to release the cell the vehicle waits for a small amount of time before trying again. During each attempt to reserve a cell, the vehicle waits for confirmation by the blockchain before proceeding, as subsequent cells are not interesting until the current one is successfully reserved. Immediately upon successful reservation of a cell, the vehicle starts moving into the cell while internally keeping track of the remaining time of the reservation. The period that the vehicle requests for a cell depends on the total length of the path, as it is assumed that a longer path will increase the likelihood of conflicts. The movement is strictly limited to be entirely within reserved space only. Once the vehicle has completely left a cell, it is added to a list of cells that the vehicle is willing to exchange with others.

Reservations of volumes, including attempted exchanges with other vehicles in case of failure, is described in algorithm 1 using the contract functions described in section 3.3.3. If the volume is available it is reserved through the smart contract (lines 3-5). If it is not, an attempt is made to contact the owner and request an exchange (lines 6-22). Note that the owner is only contacted if the reservation is not made ahead of time (line 6). If it is made ahead of time, the owner at that time will not yet have passed it, and will therefore never agree to an exchange (lines 23-24). Should the connection fail or if the owner refuses the connection, the requesting vehicle waits for a period before trying to reserve the volume again (lines 14-17). If the exchange is successful, the vehicle proceeds as if the transaction is validated immediately, since it can not wait for validation if it is offline (line 18). This is not a problem, however, since it holds the signed transaction as proof that it is the new owner while trying to publish it periodically (lines 18-22). There is no reason for the publishing to fail, as the previous owner cannot sign the transaction without it being valid on their machine. Not shown in algorithm 1 is the owner side of the exchange as it only consists of the owner checking if they do not need the requested volume anymore, and if so, a transaction is built locally and signed by the owner and then sent. If the volume is not available for exchange, the owner instead sends a boolean false, which is also what is returned in the case of a failed connection when waiting

10https://docs.python.org/3.7/

(36)

20 Chapter 3. Method for a response.

input : 3D coordinates of the desired volume, start time and duration output: Boolean result

1 function ReserveVolume(x, y, z, start, duration) 2 end = start + duration

3 if contract.CheckAvailable(x, y, z, start, end) then 4 contract.RentNode(x, y, z, start, duration)

5 self.rentedNodes.append(x, y, z) 6 else if start ≤ time.now() then

7 owner = contract.GetOwner(x, y, z) 8 if not owner then

9 ReserveVolume(x, y, z, start, duration)

10 end

11 socket.Connect(owner)

12 socket.SendMessage(self, x, y, z) 13 signedTx = socket.GetResponse()

14 if not signedTx then // For failed connection or exchange.

15 wait(5 )

16 ReserveVolume(x, y, z, start, duration) 17 end

18 self.rentedNodes.append(x, y, z)

19 while not receipt do // Run on a separate thread. 20 txHash = blockchain.SendTx(signedTx)

21 receipt = blockchain.GetReceipt(txHash) 22 end 23 else 24 return false 25 end 26 return true 27 end

Algorithm 1: Recursive function for volume reservation by vehicles.

The reason for the transaction being created and signed locally is to handle the case of vehicles being offline during attempted exchanges. A signed transaction, even when not published, will function as a receipt in case a conflict occurs following the exchange. The responsibility lies with the new owner to publish the transaction when possible, rather than the previous owner, which removes the need for trust between the involved parties. However, creating and signing transactions offline requires each vehicle to have direct access to their private keys, either via an encrypted key file or in plain text.

(37)

ad-3.3. Technology and Methodology 21

Figure 3.1: Visualization of the simulation program. Vehicles (circles) travel along their path rented through the smart contract on the blockchain. Note that the green vehicle exchanged one of their nodes with the pink vehicle.

vanced path-finding redundant. In a realistic scenario, a vehicle would likely benefit from calculating alternative paths, however, while still checking the availability of the shortest path to maximize efficiency.

Simulation

The Simulation program consists of sockets to receive information from the Vehicle program, a connection to the blockchain to retrieve information on the owners of volumes, and a window with a grid to represent the volumes of space and the vehicles moving. The program receives the number of vehicles as an argument and starts the same amount of instances of the Vehicle program during the initiation phase. Within the program is a set of colors which correspond to different vehicles, and the vehicles are drawn as circles of their respective color. The smart contract is called to find the current owner of each cell in the grid, and colors the cells accordingly, with the default color being white.

(38)

22 Chapter 3. Method

3.4

Evaluation

To answer the research questions in section 3.1, several metrics were applied to evaluate the performance of the system. A theoretical analysis of the safety is also conducted to evaluate if and how the improved efficiency affects the safety of the vehicles using the system. In evaluating a system like this, several aspects need to be taken into account. The performance of the system and network is vital, as the goal is to increase efficiency in autonomous operations. The expected performance of autonomous vehicles is also important, especially in terms of communication, as a core part of the functionality is the possibility of offline exchange of volumes. Due to not having tested the system in a realistic environment, relevant vehicle performance is assumed based on current information, while the system and network performance is tested. Section 3.4.1 describes how the functionality will be tested and verified, while sections 3.4.2, 3.4.3, and 3.4.4 describe the performance metrics used along with motivations.

3.4.1

Functionality

In a proof-of-concept system, the functionality is arguably the most important as-pect. Therefore, several test cases were designed to verify that the system works as expected. An important function of the system is the ability to securely, and with-out prior agreement or trust, exchange reserved volumes while disconnected from the main blockchain network. Naturally, the system also needs to function in the general case as well. With a connection to the network, it should be possible for any number of actors to reserve any number of volumes from the central service provider at any time (not in the past) until any time in the future while being sure that they will be alone within that volume in the specified window of time. The tests performed are detailed below, with the main focus being testing the communication between clients and the smart contract, as well as the smart contract functionality. To verify that transactions performed in the tests are validated as expected, the transactions will be fetched from the blockchain along with the receipt and compared to the expected result. The contract functions CheckAvailable and GetOwner, as described in section 3.3.3, will also be used to verify that they behave as expected, creating a layer of abstraction between the client and the blockchain since vehicles will not have to store transaction hashes or query the ledger directly.

Standard Volume Reservation

In the normal case, a vehicle will perform a transaction with the smart contract to get permission to inhabit the volume for a specified window of time. After validation of such a transaction has been attempted, the vehicle can read the result of it through the receipt published on the blockchain. Preferably, the vehicle should check whether the volume is available to avoid unnecessary wait times, although this is not required. Answering the following questions will show whether the standard method of volume reservation works as intended or not, as they cover every scenario:

(39)

3.4. Evaluation 23 2. “Will two accounts reserving the same volume within the same block always

reject one of the transactions?”

3. “Is it possible to reserve a volume in advance while ensuring that no reservation made in the past or future will overlap in time?”

Offline and Online Volume Trading

Regardless of whether the parties in a vehicle-to-vehicle exchange are offline or online, the method of exchanging will remain the same. As the accepted transaction is never expected to fail, the method of building and signing a transaction locally serves to make the operation of vehicles more efficient. In this case, receiving a signed transaction is interpreted as a validated transaction immediately without waiting for it to be validated. Answering the following questions will determine whether this method may be used for offline transactions or not, as they cover every scenario:

1. “Can a smart contract transaction be created and signed offline, and then be published and validated correctly once the connection is re-established?”

2. “Can a smart contract transaction created offline by one account be published by a different account?”

3. “Can the account that created and signed a transaction prevent the transaction from being published by a different account?”

Emulation Performance

Aside from the specific functionality described above, which determines if the concept is viable, the implemented emulation is tested as well. While isolated tests are suitable for testing one specific function, the entire emulation shows how vehicles acting within the system may perform in a real-world scenario. To evaluate how the system performs overall, aside from visual observation, the following information will be collected from emulations run with the number of vehicles ranging from 2 to 10 with increments of 2:

• The time it takes for vehicles to reach their destination compared to the dis-tance.

• The time it takes to attempt to reserve a volume (algorithm 1).

The time it takes for a vehicle to reach its destination will naturally depend on the speed at which it moves. Therefore the time it takes to reach a destination for a vehicle will be measured in the following ways, and subsequently compared against each other:

• Regular: The normal restrictions described.

• Always exchange: Every attempted exchange passes.

(40)

24 Chapter 3. Method • Straight line: No path is required, straight line from start to goal.

The time it takes to reserve a volume will dramatically increase if the volume is already reserved by a vehicle that is not willing to exchange it immediately, which does not necessarily reflect a real-world scenario where a vehicle would likely recalcu-late the path rather than wait for the shortest path. Therefore, failed transactions as a result of the volume being unavailable will be timed separately, from the point of starting the algorithm to where it exits to restart. The waiting period after a failure will not be included in the timing. As it is explicitly set it may be manually added when processing the data.

3.4.2

Hardware Requirements

While the hardware is assumed to be adequate for the purpose of this experiment, it is important to consider if a system like this is to be used in practice at some point. The following metrics describe what the system will need in order to function properly in an autonomous vehicle.

Storage Requirement

The storage requirement for the system itself is important to note, since storage may be limited. However, due to a node in the blockchain needing to keep a local copy of the entire chain, the storage requirement will increase over time. To understand how the storage requirement scales, the size of every possible transaction within the contract is measured, along with the overhead when compiling a set of transactions into a block. This gives an estimate on the blockchain size based on the number of transactions, allowing estimates of storage requirements over time, based on the number of active users.

Computational Complexity

(41)

3.4. Evaluation 25

3.4.3

Abstraction of Vehicle-to-Vehicle Communication

This system requires vehicles to be able to communicate with each other. These metrics are used to determine if there are methods of communication that fit the specifications of the system, as well as how the system itself should handle com-munication in order to achieve the best performance. Even though the hardware specifications might indicate its viability for use within this system, it will not be tested in practice and therefore only speculated. The following sections describe the metrics and their purpose.

Communication Parameters

In sending data via peer-to-peer, there will be some level of overhead. In a network like this, delays may be acceptable when dealing with the exchange of volumes, but it is still desirable to minimize them. The overhead in communication will influence whether data is sent in fewer and larger chunks or more and smaller chunks, to optimize the efficiency of the network. Due to the overhead varying with different means of communication and protocols, and no specific requirement of either for this system, various means and protocols are reviewed in existing works.

Data Package Size

The size in bytes of data sent and received may impact the robustness of the system, due to the proposed solution occasionally requiring long-distance communication. The data package size is kept to a minimum for this reason, although in some cases the minimum size is relatively large. The largest transfer in this system is the finalization of a transaction since a signed transaction is sent to the receiver as a receipt of the exchange. A literature review will answer if the package size is detrimental to the functionality over various ranges.

Latency

Aside from the size of the data sent, the latency in communicating is also important. Latency is naturally impacted by the distance between two communicating peers, which will vary significantly in practice. Excessive wait times for responses are detri-mental to the overall efficiency of the system. The latency is especially important given that the key purpose of the system is improving the efficiency. The latency is analyzed to determine the speed at which an exchange is performed over vary-ing distances through various means of communication. Due to limited resources for testing various communication methods and protocols, this metric is collected through a literature review.

3.4.4

Blockchain Network Performance

(42)

26 Chapter 3. Method more users in synchronization time and throughput, and also evaluate how much it will cost to execute transactions within the system.

Synchronization Time

In a blockchain network, synchronization time refers to the time it takes for a block to be propagated to all the nodes in the network. Using a Proof-of-Authority consensus protocol, this time is less important than using Proof-of-Work, as blocks only need to synchronize between the sealer nodes to avoid splitting the chain as opposed to a network where any node can validate new blocks. However, regular nodes (vehicles) benefit from having a synchronized blockchain as well, since an older state of the blockchain may be misleading in terms of which volumes are reserved. The synchronization time will depend on the number of nodes in the network, as well as the distance between them. In the implemented system, the synchronization time will not accurately depict the real-world scenario, since the distance between nodes is negligible. However, the scaling of the synchronization time with increasing amounts of nodes can be analyzed, and the factor of distance can be included theoretically through a literature review. This metric will aid in finding an appropriate block time which ensures that the network is synchronized before adding a new block.

Smart Contract Execution Cost

When executing a state-changing smart contract function (a transaction), a price has to be paid depending on the complexity of the function. In the Ethereum blockchain, the complexity of a smart contract function is measured in gas, with the price of a unit of gas being set by the caller of the function. Validating nodes may ignore transactions that pay less for their gas, and thus the transaction takes longer to be validated if the gas price is lower. Since the validating nodes need to execute the same function to validate the transaction, the amount of gas needed is a measurement of the amount of processing power required to validate it. Therefore, to maximize the efficiency, the complexity of the smart contract functions need to be minimized, along with the number of transactions performed. Analyzing the gas used to execute the smart contract functions serves to optimize the efficiency of the system overall. Transaction Throughput

Figur

Updating...

Referenser

Updating...

Relaterade ämnen :