Fulltext PDF

Decentralized Item Sharing Powered by
the Blockchain and the Internet of Things
Lauritz Prag Sømme
Master of Science in Informatics

Submission date: June 2018
Supervisor: Jingyue Li, IDI
Norwegian University of Science and Technology

Department of Computer Science
This thesis is dedicated to everyone who made my five years as a student to some of the
best years of my life (so far).
Abstract
Technology is allowing more people to partake in the sharing economy. At the same
time, the internet of things is coming closer to become a reality. The blockchain has
shown that decentralized payment is possible without trust. Moreover, researchers sug-
gest that blockchain and IoT is a good match and that the sharing economy can make use
of blockchain based technologies. Current blockchain based sharing economy platforms
does not include data in price calculations.
This thesis reviews the top ten most valuable blockchain protocols, to further develop a
decentralized blockchain-based sharing economy platform. In addition, a user-test and an
evaluation of the platform is conducted to investigate the following research questions:
In a sharing economy platform for item sharing:
Research question 1: How can data be used in a decentralized sharing economy plat-
form to determine an accurate and fair price for both the renter and the lender?
Research question 2: How could such system provide real-time decentralized payment
through a blockchain technology?
Research question 3: How can real-time transactions with data provide real-time infor-
mation to a lender about the condition of its items?
Research question 4: How can data be stored on a blockchain to provide manufactur-

ers of items information about how their items are being used?
The thesis demonstrates that it is possible to create and use a blockchain based sharing
economy platform that makes use of the power of IoT and data, along with smart contracts
and the blockchain data structure. Also, this platform makes it possible to rent and lend
items, and receive payment based on how the renter used an item during the rental period.
This data is further used to supply the renter of the item with real-time information about
the condition and whereabouts, while it is being rented. Also, the platform allows for
third parties to purchase the data generated by the users of the platform, to improve their
products.
i
Sammendrag
Teknologien gjør at flere personer deltar i delingsøkonomien. Samtidig kommer Tingenes

internett nærmere til å bli en realitet. Blokkjeden har vist at desentralisert betaling er mulig
uten tillit. Dessuten foreslår forskere at blokkjeden og IoT er en god match, og at del-
ingsøkonomien kan benytte seg av blockkjede-baserte teknologier. Nåværende blokkjede-
baserte delingsøkonomiplattformer inkluderer ikke data i sine prisberegninger.
I denne oppgaven vurderes de ti mest verdifulle blockchain-protokollene. Dette gjøres

for å kunne utvikle en desentralisert blokkjedesbasert delingsøkonomiplattform. I tillegg
utføres det en brukertest og en evaluering av plattformen for å undersøke følgende forskn-
ingsspørsmål:
I en delingsekønomiplattform for deling av gjenstander:
Forskningsspørsmål 1: Hvordan kan data brukes i en desentralisert

delingsekønomiplattform for å fastslå en nøyaktig og rimelig pris for både utleier og lei-
etaker?
Forskningsspørsmål 2: Hvordan kan et slikt system tillate for desentralisert betaling i

sanntid via en blokkkjede teknologi?
Forskningsspørsmål 3: Hvordan kan transaksjoner med data gjort i sanntid gi sanntidsin-

formasjon til en utleier om hvordan den utleide gjenstanden blir brukt?
Forskningsspørsmål 4: Hvordan kan data lagres i en blokkjede for å gi produktprodusen-

ter informasjon om hvordan produktene deres blir brukt?
Avhandlingen demonstrerer at det er mulig å lage og bruke en blokkjedebasert

delingsekønomiplattform som benytter seg av IoT og data, sammen med smarte kontrak-
ter og blokkjede datastrukturen. Denne plattformen gjør det også mulig å leie og låne
gjestander, og motta betaling basert på hvordan leietakeren har behandlet gjenstanden i
leieperioden. Disse dataene brukes videre til å gi leietaker sanntidsinformasjon om tilstand
og oppholdsstedet til den utleide gjenstanden. Plattformen tillater også at tredjeparter kan
kjøpe dataene fra brukerne av plattformen, for å kunne forbedre sine produkter.
ii
Preface
First and foremost, I would to thank my supervisor Jingyue Li for his remarkable assis-
tance throughout the writing of this thesis.
I would also like to thank my family and Mari for providing moral support along the way.
Thanks to Chris, Rose, and Ulrik for feedback on the thesis.
This thesis concludes my five years as a student of Computer Science. And it was written
for the Department of Computer Science at Norwegian University of Science and Tech-
nology(NTNU) during the fall of 2017 and in the spring of 2018.
iii
iv
Table of Contents
Summary i
Summary ii
Preface iii
Table of Contents viii
List of Tables ix
List of Figures xii
Abbreviations xiii
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Scientific contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Sharing economy 5
2.1 Sharing economy business models . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Marketplace business model . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Access based business model . . . . . . . . . . . . . . . . . . . . 8
2.1.3 On-demand service provider business model . . . . . . . . . . . 8
3 Internet of things 9
3.1 Internet of things devices . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Wireless Sensor networks (WSN) . . . . . . . . . . . . . . . . . 11
v
3.1.3 Micro processor units (MPU) and microcontroller units (MCU) . 12
3.2 Internet of things and its applications . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Transportation and logistics . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Health-care . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Smart environment . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4 Personal and social . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 State of the art of blockchain technologies 19

4.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1 Cryptocurrencies . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2 Hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 General search process . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Question 1: How does the blockchain work? . . . . . . . . . . . . . . . . 23
4.4 Question 2: How does popular blockchain protocols work? . . . . . . . . 26
4.4.1 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.2 Ripple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.3 Cardano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.4 NEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4.5 Stellar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.6 IOTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.7 NEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.8 Comparison of blockchain technologies . . . . . . . . . . . . . . 36
4.4.9 Search process of popular blockchain protocols . . . . . . . . . . 39
4.5 Question 3: What are current applications of blockchain protocols? . . . . 40
4.5.1 Financial instruments . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.2 Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.3 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.4 Table of blockchain applications . . . . . . . . . . . . . . . . . . 42
4.5.5 Search process for applications of blockchain technologies . . . . 42
4.6 Question 4: How is the blockchain used or can be used with IoT in particular? 43
4.6.1 Question 4.1: How is the blockchain used with IoT in a sharing
economy context? . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6.2 Search process IoT and Blockchain, and IoT, blockchain and shar-
ing economy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Motivation and requirements for an IoT based sharing app with decentralized
payment 51
5.1 Limitations of existing IoT-blockchain SEPs . . . . . . . . . . . . . . . . 51
5.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.1 Machine-to-machine economy . . . . . . . . . . . . . . . . . . . 55
5.4 Empirical study of research questions . . . . . . . . . . . . . . . . . . . 56
5.4.1 Results question 1 . . . . . . . . . . . . . . . . . . . . . . . . . 57
vi
5.4.5 Notes from participants . . . . . . . . . . . . . . . . . . . . . . . 58
6 High level architecture and design 59

6.1 System concept description . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2 Business model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 IoT components in system . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4 System actors and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.1 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5 System features and use cases . . . . . . . . . . . . . . . . . . . . . . . 64
6.5.1 System features . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6.1 Use case 1: Put an item up for rent . . . . . . . . . . . . . . . . . 64
6.6.2 Use case 2: Rent an item . . . . . . . . . . . . . . . . . . . . . . 65
6.6.3 Use case 3: Charging a renter . . . . . . . . . . . . . . . . . . . 65
6.6.4 Use case 4: Show status of a rented item . . . . . . . . . . . . . . 66
6.6.5 Use case 5: Buy data about an item . . . . . . . . . . . . . . . . 66
7 Detailed design and implementation 67

7.1 System Inspiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.1 Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.2 How the smart contract is used in the prototype . . . . . . . . . . 68
7.2 System implantation user interface . . . . . . . . . . . . . . . . . . . . . 69
7.2.1 Registering and putting an up for rent . . . . . . . . . . . . . . . 69
7.2.2 Renting an object . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.2.3 Show status of Object . . . . . . . . . . . . . . . . . . . . . . . 71
7.2.4 Buy data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3 Smart contract implementation and code: Data structures and functions . 71
7.3.1 The ”dataWeight” array . . . . . . . . . . . . . . . . . . . . . . 79
7.3.2 Important functions . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3.3 web3.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8 Evaluation and discussion 83

8.1 User-testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.1.1 user-testing: Renter . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.1.2 user-testing: Lender . . . . . . . . . . . . . . . . . . . . . . . . 85
8.1.3 user-testing: Third party . . . . . . . . . . . . . . . . . . . . . . 86
8.1.4 General comments . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.2 Discussing the prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.2.1 Research question 1 . . . . . . . . . . . . . . . . . . . . . . . . 87
8.2.4 Privacy and security . . . . . . . . . . . . . . . . . . . . . . . . 91
8.2.6 General problems . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.3 Choice of technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.3.1 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
vii
8.3.2 Web3.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.3.3 Truffle framework . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.3.4 Ganache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.4 Other problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.4.1 Problem: Running an Ethereum client on a smart phone . . . . . 96
8.4.2 Problem: Paying for smart contract usage and data storage on the
Ethereum blockchain . . . . . . . . . . . . . . . . . . . . . . . . 96
8.4.3 Possible solutions: StorJ . . . . . . . . . . . . . . . . . . . . . . 97
8.4.4 Possible solutions: IOTA . . . . . . . . . . . . . . . . . . . . . . 97
9 Conclusions 101
9.1 Research question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.5 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Bibliography 105
Appendix 119
A Smart contract code 121
B User interface code 125
viii
List of Tables
4.1 Bitcoin block structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Bitcoin block header structure . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 A comparison of the different blockchain or blockchain alike technologies 37
4.4 Table of different applications of blockchain technologies in different areas 42
5.1 Possible sensor data measurements for different items . . . . . . . . . . . 53

5.2 Machine as its own class in the economy . . . . . . . . . . . . . . . . . . 55
5.3 Machine as a supplement to the sharing economy . . . . . . . . . . . . . 55
7.1 Explain variables in the the struct ”Object” that represent an item . . . . 77
7.2 Shows get functions I reused or edited . . . . . . . . . . . . . . . . . . . 78
7.3 Shows get functions that I added and the edited function ”registerObject” 78
ix
x
List of Figures
2.1 Sharing economy business models sorted by industry . . . . . . . . . . . 7
3.1 The different visions that IoT consists of . . . . . . . . . . . . . . . . . . 10

3.2 A small RFID tag with a grain of rice for scale. This type of small tag can
be implanted in household animals . . . . . . . . . . . . . . . . . . . . . 11
3.3 An RFID tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 A microcontroller unit produced by Arduino. This board have built-in
WiFi, and can run Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 The difference between a microcontroller unit (MCU) and a micro proces-
sor unit (MPU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Applications domains and relevant major scenarios for IoT . . . . . . . . 14
4.1 A message M is hashed by hash function H, and a hash value h is returned.

h can uniquely identify M. . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 How a data integrity check is performed with hashing algorithms . . . . . 21
4.3 Simplified Bitcoin Blockchain . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Smart contract system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 This is how IOTAs DAG, the Tangle, looks like. Each node represent a
transaction. And the green ones are confirmed transactions, and the red
ones are awaiting confirmation. A transaction is confirmed only if all tip
nodes (the grey nodes) directly or in-directly point to it. . . . . . . . . . . 34
4.6 Backside of the tamper-proof Wabi label . . . . . . . . . . . . . . . . . . 45
4.7 Figure of Andreas Bogner, Matheiu Chanson and Arne Meeuw’s decen-
tralized application with caption:”DAPP in use: The owner of the smart
contract registers device by scanning a barcode with a numerical id (left
screen). After scanning the same barcode on a registered device, the app
displays the rental conditions to the interested renter (right screen).” . . . 48
4.8 The figure shows how many percents of people are willing to share their
assets for financial gain per continent. . . . . . . . . . . . . . . . . . . . 49
4.9 How Slock.it picture bike rental through the USN . . . . . . . . . . . . . 50
xi
6.1 How the different actors in the system are related to each other . . . . . . 62
6.2 Figure show how a user would rent an object . . . . . . . . . . . . . . . . 63
7.1 Figure showing the architecture of the prototype. All interactions with the
system included the use the smart contract’s function. Third parties read
data off the blockchain, without the need for the smart contract . . . . . . 69
7.2 Screenshot of the prototype showing registration of an item . . . . . . . . 70
7.3 Screenshot of the prototype showing a renter who are about to rent an item 73
7.4 Screenshot of the prototype showing the view for the renter after it has
started renting the item . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.5 Screenshot of the prototype showing information about a rented item . . . 75
7.6 Screenshot of the prototype showing an interface a third party would ac-
cess in order to purchase data . . . . . . . . . . . . . . . . . . . . . . . . 76
8.1 Prototype’s architecture if implemented with IOTA . . . . . . . . . . . . 99
xii
Abbreviations
SEP = Sharing Economy Platform

DAG = Directed Acyclic Graph
IoT = Internet of Things
B2B = Business-to-business
C2C = Consumer-to-consumer
B2C = Business-to-consumer
GPS = Global Positioning System
EVM = Ethereum virtual machine
SHA256 = Secure hashing algorithm
dBFT = Delegated Byzantine Fault Tolerance
FBA = Federated Byzantine Agreement
RFID = Radio frequency identification
ICO = Initial coin offering
MCU = Micro controller unit
MPU = Micro processor unit
GDPR = General Data Protection Regulation
xiii
xiv
Chapter 1
Introduction
Sharing economy is an economic model that allows people to rent or borrow assets from
each other. The sharing economy model is often used when someone owns an asset that is
not completely utilized. Sharing economy is based on the use of peer-to-peer transactions
effectively removing intermediaries in the value chain [1]. Although sharing economy is
not a new concept, it has become increasingly popular in the past decade [2]. This increase
in popularity can be explained by the new ways of utilizing technology and the creation of
various platforms which enable sharing economy interactions [3]. These platforms have
been developed into apps and websites, making sharing economy platforms (SEP) more
accessible than ever.
In parallel to the development of SEPs, a new technology paradigm has emerged, the
Internet of Things (IoT). IoT is envisioned as physical devices connected to each other,
and interacting with each other in a global network. These devices can range from a reg-
ular computer to sensor devices and GPS technology. A device is an IoT device as long
as it is connected to a network, and can communicate with other devices. IoT is has been
recognized as one of the most critical technologies for future development, and is gaining
vast attention in various industries [4] The reason for this attention is the promise of new
interactions and the integration of different actions in companies processes. This will al-
low a company to investigate the efficiency, profitability and other aspects of its processes,
more precise and thorough. Ultimately, IoT enables a company to run its operations with
vast knowledge of each of its processes.
In 2009 a decentralized crypto-currency was proposed by Satoshi Nakamoto. The pa-

per introduced the concept of a decentralized money transferring system in a peer-to-peer
network. Bitcoin: A Peer-to-Peer Electronic cash system describes a system with a cryp-
tocurrency using a distributed ledger to keep track of transactions made with its crypto
coins. The distributed ledger described in the paper is the foundation for this system to
work and is called a Blockchain. The blockchain allows for storing data on a ledger,
with pseudo-anonymized users, while being immutable and viewable to all users [5]. The
1
Chapter 1. Introduction
blockchain itself, and its properties have inspired many new cryptocurrencies and systems,
for instance, Ethereum. The Ethereum blockchain allows for more than just keeping track
of transactions. The Ethereum blockchain allows its users to put code on it and run it. This
feature allows for the creation of smart contracts, which have many useful applications.
Another example is IOTA, not using a blockchain, but a Directed Acyclic Graph (DAG)
named Tangle. A DAG has many of the same properties as the blockchain. However, due
to its structure, it allows for other interesting interactions, especially regarding IoT devices
(hence its name) on the transport layer.
1.1 Motivation
Time-sharing (for profit) has been a concept in sharing economy platforms for some time
now. For instance, AirBnb, a SEP for renting out your property when you are not using
it, i.e., fully utilizing your property. Nabobil (neighbor car) is a SEP that allows for your
neighbors to share a car together. Also, another trend is the use of Tool Libraries, a library
where you lend tools instead of books, in turn, you do not need to buy your tools to get a
job done, lend them instead. It is the concept of time-sharing in SEPs I want to address
in this thesis, along with the possibilities blockchain technologies and IOT can give SEPs.
Blockchain technologies allow for peer-to-peer transactions, sharing economy is based on
peer-to-peer transactions. Blockchain technologies can be used with IoT devices, and IoT
devices can be used in sharing economy platforms. I want to combine these to make a SEP
for renting out none-utilized tools. However, where does IoT come in?
On AirBnb platform you rent property on a daily basis, on the Nabobil platform you rent
the car on an hourly basis, and in the tool libraries, you can borrow a tool for week [6]. I
found it interesting that tool libraries have such long lending time. Because in some cases
you only need to use a tool for a few hours. With the case of tool libraries you also need to
get to the tool library. And what if your neighbor or someone nearer than the tool library
has the exact tool you need? Why couldn’t you borrow it from them instead, saving the
C02 emission you would spend on getting to the tool library along with other expenses.
Also, if you only use your tool for a couple of hours, or minutes, why should you need to
hold it for a full week? Of course, tools get worn down, and since you are borrowing the
tool from a private person, it is fair that the person should get compensated. But for how
much? A days use? But what if you use your tool for only 25 minutes, then a days use is
not fair. This is part of the problem I want to address.
Researchers have already combined the blockchain and sharing economy, however, not
with IoT and data [7]. A start-up has also tried the combination with IoT, but without
using data generated from IoT devices in their system [8]. I want to enable renting and
lending of items without the need for centralization, like tool libraries. Making a system
that allows for decentralized item renting and sharing. I want people to lend items to oth-
ers, and get compensated for the exact usage of the item. This is where IoT comes in. I
want to place sensors on items to measure how they are being used while being rented.
And with the data generated from the items while being rented, take it into the price cal-
culations. In turn the lender can be paid by the data, and the renter pays an accurate price
2
1.2 Objectives
and fair price. I also want this data to be sent in real to the lender of the item. For making
the lender be able to continuously monitor the condition of its items. I want to develop an
SEP that calculates exact item usage and make payment through blockchain technology,
essentially allowing everyone to become a tool library, and profit from it. Also, I want to
make use of the data that is generated, and enable third parties to purchase data generated
by the item’s IoT device.
Therefore, I want to make a prototype of a sharing economy platform for item sharing
and show:
Research question 4: How can data be stored on a blockchain provide manufacturers

of items information about how their items are being used?
1.2 Objectives
The overall objective of the thesis is to assess the research questions. Also, show that the
combination of IoT, blockchain and sharing economy is possible.
1.3 Scientific contribution

• Demonstrating how data from IoT devices could be a part of the calculation of cost
in an SEP that enables the sharing of objects.
• Demonstrating how a blockchain technology can be used in an SEP using data gen-
erated from IoT devices for its cost calculation.
• Demonstrating how sending and storing of data on a blockchain can allow for close
to real-time monitoring of items
• Demonstrating how sending data in transactions on a blockchain may generate data

that is useful, and easily accessible for many parties.
• In addition, contrasting and comparing the top 10 cryptocurrencies, and elaborating

on how they function and what use cases they have.
3
Chapter 1. Introduction
1.4 Method
In order to assess the research questions, I perform a review of blockchain protocols. Next,
I perform a comparison of the blockchain protocols to find a suitable protocol to develop
a SEP with. To further assess the research questions I develop an SEP, which uses data
for price calculations, and can send real-time decentralized payment and data, and enable
third parties to purchase the data generated in the SEP. In addition, I perform a user-test
and an evaluation of the SEP, discussing its difficulties and challenges.
1.5 Limitations
Research material and papers are gathered exclusively from NTNU school library [9],
Google.com, and scholar.google.com.
State of the art of blockchain technologies is limited to the top 10 most valuable cryptocur-
rencies on coinmarketcap.com as of 16.01.2018 [10].
Price calculation of cryptocurrencies in this thesis is limited to the timeframe of 01.02.2018-
01.06.2018 unless another date is explicitly stated.
1.6 Document Structure

Background information related to the sharing economy and the Internet of Things is found
in chapter 2 and chapter 3. Alternatively, or for further reading, one may read the paper
[11] about the sharing economy. And the papers [12] and [13] about the Internet of things.
A review of blockchain technologies is in chapter 4. Motivation and research questions
are further elaborated on in chapter 5. The high-level architecture of the SEP developed
for this thesis is described in chapter 6, followed by detailed design and implementation
description of the SEP in chapter 7. A user test and discussion of the SEP is in chapter 8.
And lastly, chapter 9 is conclusions.
4
Chapter 2
Sharing economy
The internet have seen many stages of development since its beginning in 1995. They
include different steps of evolution in electronic, mobile and social businesses. In addition
to creating new business models, social networks have emerged making for a paradigm
shift from owning to using goods and services. Sharing economy, unlike the traditional
market model, is based on the use and sharing of products and services among others. This
model has been around for ages in many different domains. Sharing resources in business
is known as business-to-business (B2B) sharing, examples of these could be the sharing
of machinery in industries. Another model is known like the business-to-consumer (B2C)
like video, video game and car rentals, along with libraries and swimming pools. And the
sharing economy has recently spread to the consumer-to-consumer (C2C) model.
Three possible drivers have been identified for this development:
• Change in consumer behavior: Convenient, cost-efficient and ecologically friendly

services have become more attractive for many consumers. This has caused a change
in consumer behaviour.
• Social networks and electronic markets: Due to people linking themselves with oth-
ers through social media, consumers are able to find people who are willing to share
their goods and resources among each other. Along with electronic market platforms
that reduce the formerly high search and transaction cost.
• Mobile devices and electronic services: Due to mobile platforms high accessibility,
have enabled devices to access the ”app economy.” Making it convenient to access
different applications made for consumer-to-consumer interaction, accompanied by
the use of electronic devices such as key cars, or other technology.
Along with the rise in popularity of the sharing economy, comes a survey promising high
revenue gains with this financial model. The survey from 2015 [14], of American con-
sumers suggest that sectors within travel, car sharing, finance, staffing, music and video
streaming will increase their revenues by 320 billion USD from 15 billion USD within
5
Chapter 2. Sharing economy
few years. The survey also states that in 2014, 21% of American consumer used sharing
economy based services, and this number is expected to increase to 45% in 2015. Start-up
companies stand for a large proportion of innovation in the sharing economy [14]. These
companies usually have the role as an intermediary between consumers, allowing for a
convenient method for sharing resources and services. Examples of these start-ups could
be Uber: a platform for consumers and companies with a car to run a taxi service. Another
one could be AirBnB, a platform for renting out your property to others. Also, WeWork,
a platform for sharing workspaces with others. All of the above mentioned start-ups are
currently worth more than 1 billion USD. However, start-ups are not the only ones making
sharing economy platforms. IKEA has for instance made an online platform, allowing
their customers to exchange used furniture over their website. Some companies also co-
operate with start-ups, like General Motors who invested 3 million USD in the car rental
start-up Turo. Also, non-profit organizations are starting to explore the sharing economy,
by further developing their previous model. Among these are the tool libraries. Instead of
lending books, you can lend tools instead.
Sharing economy is gaining popularity, and is becoming a profitable market model for
many. As described, the large adoption of sharing economy services is mainly due to de-
velopment in technology, allowing consumers to take part in the sharing economy easier.
Allowing consumers to participate in the sharing economy have also made a change in
consumer behaviour, and people are seeking out new ways to use sharing economy [11].
In the next section I will discuss relevant sharing economy models and platforms.
2.1 Sharing economy business models

There are mainly three underlying business models in the sharing economy. These three
are identified as: Marketplace, Access-based and On-demand Service Provider -business
models. These business models are identified across many industries and companies with
their SEPs. The different business models do not belong to a specific industry; this means
that companies in the same industry are using different business models. An example of
this is in the transportation industry. The company, Didi Chuxing, Grab, Uber and Lyft are
all in the transportation industry, however Didi Chuxing and Grab utilize an On-demand
service provider business model, while Uber uses a Pure marketplace business model, and
Lyft uses a community marketplace business model [15].
2.1.1 Marketplace business model

The marketplace model in the sharing economy is based on the matching of supply and de-
mand. The matching of supply and demand is provided by the companies online platforms,
that fulfills the role of a marketplace. The sharing economy company and its platform act
as the middleman between those who have excess capacity of goods, services or assets
(supply side), and those have the capacity to pay and consume what the supply side sells
(demand side). To the sharing economy company (SEC) the most important element of
the marketplace business model is the platform the sharing economy company provides
to the two groups of participants. This is because they charge the users, usually on either
6
2.1 Sharing economy business models
[15]
Figure 2.1: Sharing economy business models sorted by industry
7
Chapter 2. Sharing economy
the supply or the demand side, through their platform to make money. In the platforms of
marketplace business model based SECs, customer relationships are typically automated
or semi-automated. The marketplace business model can be divided into three sub-classes:
pure marketplace, community marketplace, and service marketplace. The variations be-
tween these sub-classes depend on what role the SEC take in its platform. In the pure
marketplace, the SEC’s role is only to provide the platform for the users. In the service
marketplace, the SEC provide additional services to both parties. In the community mar-
ketplace, the SEC offers extra benefits for using their platform, to build a good community
surrounding the services in the marketplace [15].
2.1.2 Access based business model

In an access-based business model, the customers are not split between supply and demand
side. In this business models, the customers are all on one side. The fundamental is that
you offer something and get the same thing you offer in return. The SEC Fon is based on
this business model. Fon is a worldwide WiFi provider. To use other peoples WiFi, you
got to share your WiFi with others [15].
2.1.3 On-demand service provider business model

In the sharing economy, On-demand service provider is the last category of business mod-
els. The key aspect of this business model is that all services are served on demand from
consumers. This business model has two distinct groups, unlike the access based business
model. The On-demand service provider model is usually based on a traditional business,
but with a technological upgrade. An example might be Grab or Didi Chuxing. Grab,
and Didi Chuxing are apps connecting potential passengers to professional drivers, essen-
tially replacing the call center operated by a taxi service, or act as a supplement to the call
center.The difference between Uber and these platforms is that Grab and Didi Chuxing is
connecting professional drivers to consumers, while Uber are connecting casual drivers to
consumers [15].
8
Chapter 3
Internet of things
The expression Internet of things have several meanings, but they all revolve around the
same concept: that IoT includes a global and dynamic network of interconnected ob-
jects with capabilities like sensing, communication, networking, and processing that links
the virtual world with the physical world. The expression was first coined about objects
with radio frequency identification (RFID) connected to the internet, by Kevin Ashton
in 1999 [16]. RFID may contain different types of information; however, all RFID in-
struments contain a uniquely identifiable identification. Therefore, an IoT device is a de-
vice that is uniquely identifiable, connected to the internet and have the capabilities listed
above. The development of IoT is fueled by technology like Bluetooth, RFID, WiFi, em-
bedded sensors and actuator nodes. The internet led people to connect to each other, and
now the next revolution is things connecting to each other. Over the past years, the number
of IoT devices have accumulated quickly, reaching over 9 billion interconnected devices
in 2011. This number is still growing, and it is expected that the population of intercon-
nected devices will reach at least 24 billion by 2020. The internet of things will provide
automation and new business models in many business areas and industries [13].
IoT can be divided into three visions: things-oriented, network-oriented, and semantic-
oriented. The network-oriented vision refers to the infrastructure and connectivity aspects
resulting from the web of things. The things-oriented vision is related to physical items
like embedded devices or things such as sensors and actuators that respond to stimuli in
their environment. These include items such as RFID, near field communication (NFC),
sensing platforms, and wireless identification. The semantic vision includes the process-
ing and analysis of data gathered by these devices, along with storing and management of
this data. These three visions are what makeup IoT [12]. How the different visions overlap
and makeup IoT can be seen in figure 3.1.
3.1 Internet of things devices

This sections will describe technologies that is central to the IoT.
9
Chapter 3. Internet of things
[12]
Figure 3.1: The different visions that IoT consists of
3.1.1 RFID
RFID is a key component in IoT. RFID usually consist of one or more readers and many
RFID tags. A tag is characterized by the ability to uniquely identify the objects, the things,
and even living beings the tag is applied to. A reader can trigger the transmission of the
RFID tag. The then reader receives the tag and is by that able to identify the object the tag
is on. The reader does not need to be in the line of sight to the RFID tag, to read it. Thus
RFID let us map real-world items into the virtual world, and allow us to monitor objects in
real time that is out of sight. These features can be used in wide range of applications, in
different sectors and business areas. Physically, an RFID tag is a small microchip attached
to an antenna. This antenna may both receive and transmit signals. The microchip and the
antenna are packed together into what look like an adhesive sticker (see figure 3.3). RFID
tags come in many different sizes, with the smallest one being as small as 0.4 mm x 0.4
mm x 0.15 mm, in comparison a grain of rice is approximately 512 mm long and 23 mm
thick [17] (see figure 3.2). An RFID tag can be either passive, semi-active or active. The
most common of the three is passive. A passive RFID tag is not able to transmit its ID by
itself but is in need of harvesting the energy an RFID reader emits. When the RFID tag has
sufficient energy, it will send its ID. This interaction between a passive RFID tag and the
RFID reader may take place with up to five meters of distance between the two. The active
and the semi-active RFID tags have batteries of their own and is, therefore, able to supply
themselves with power during the interaction with an RFID reader, however they use their
batteries differently. The difference between an active RFID tag and a semi-active tag is
that the semi-active tag uses power from its battery while receiving a signal but still harvest
10
3.1 Internet of things devices
[18]
Figure 3.2: A small RFID tag with a grain of rice for scale. This type of small tag can be implanted
in household animals
energy when sending one. An active tag draws powers from its battery when sending and
receiving signals [12].
3.1.2 Wireless Sensor networks (WSN)
Wireless sensor networks is also an important technology in play when it comes to IoT.
Sensor networks can cooperate with RFID systems to track the status of things better, like
the location, movement, and temperature of certain objects. The sensor networks interact
with the environment surrounding the items tagged with the RFID and act as a further
bridge between the physical and digital world. Sensor networks consist of any number
of sensing nodes communicating wirelessly in a multi-hop fashion. These sensors use
low-power, low bit rate communications in a wireless personal area network (WPAN) to
communicate their data. Multi-hop means that the sensors use each other to relay their
information further. There may be a very high amount of sensors in a sensor network. A
node in a sensor network may be a sensor, or special nodes called sinks. Each of the nodes
in the network reports their sensing to the sinks in the network. Research suggests that
there is great potential in combining RFID and sensor networks [12].
11
[19]
Figure 3.3: An RFID tag
3.1.3 Micro processor units (MPU) and microcontroller units (MCU)
[20]
Figure 3.4: A microcontroller unit produced by Arduino. This board have built-in WiFi, and can
run Linux
Sensors and actuators are required in the IoT to form the link between the digital and
physical world. As we know, a sensor senses, and converts the surrounding environment
12
3.2 Internet of things and its applications
into analog or digital signals, while an actuator interacts with the environment based on
a sensors signals. An example of an actuator could be an automatic fire extinguisher,
acting on a signal sent from a fire detector. However, this signal needs to be processed
first. The next step in the architecture of the IoT is the MPUs and MCUs units that bridge
the sensors and the actuators together, by receiving signals, computing them, and sending
signals back or to somewhere else. In the fire extinguisher scenario, the signal from the
fire detector is first sent to an MCU or an MPU, which determine if it wants to send a
signal to the actuator to activate it or not. Both MPUs and MCUs are specifically designed
for real-time systems. Typically MPUs and MCUs are designed to perform a specific task,
meaning that input and output to and from the MCU or the MPU are predefined [21]. The
difference between an MCU and MPU is that the MCU has integrated Ram, CPU, Rom
(and more..), while the MPU only contain a CPU, thus needing the addition of peripherals,
and other components to perform its tasks (see figure 3.5).
[22]
Figure 3.5: The difference between a microcontroller unit (MCU) and a micro processor unit (MPU)

IoT offers a huge potential in many different domains and environments. Many of which
include new applications that could affect our daily lives: when at home, at the gym,
when sick or at work. These applications are fairly undiscovered, and are currently only
available to a tiny part of our society. Also, most items in the different environments we
find ourselves in are not ”smart” yet with the help of IoT. Making items smart have the
potential to improve many aspects of different domains in our society. These domains are:
• Transportation and logistics domain
• Healthcare domain
• Smart environment (home, office, plant) domain
13
• Personal and social domain.
Some of these applications are directly applicable or close, however many applications
may not apply to our society until a later time (see fig 3.6). This is due to our societies and
technology are not ready for deployment. In these sections, I will only describe short to
medium term applications of IoT [12].
[12]
Figure 3.6: Applications domains and relevant major scenarios for IoT
3.2.1 Transportation and logistics

IoT has a lot of potential within logistics, especially when it comes to real time informa-
tion about objects in a supply chain. With the use of RFID tags and readers, is is possible
to get real-time monitoring of every link the supply chain. The limitations of which supply
chains this applies to are few, and it is likely that that IoT is applicable to multiple parts of
supply chains related to: raw material purchasing, production, transportation, distribution
and sale, after-sales services and many more. The implementation of IoT in logistics may
offer the different parts in the supply chain low latency if something were to go wrong. For
instance, Walmart uses such technology in order to always be able to serve their products
to their customers, essentially never running out of stock of anything. This technology
does also give the consumers the possibility to view information about their ordered items
in real time, and more general information. [12].
Assisted driving is another application of IoT in this domain. Cars, trains, and buses
may be equipped with sensors. Roads and rails may also be equipped with sensors and
processing power resulting in better safety and navigation for all participating in the rail or
14
road system. Examples of functions could be collision avoidance systems, automatic park-
ing, and automatic driving on highways for cars. This is a functionality that exist in for
instance most Tesla cars [23]. This technology could also benefit governmental services
in both tracking of illicit activities, but as well as roadmap optimization in relation to ex-
panding the road networks. Also in relation to transportation, information about the state
of the local traffic, may allow transportation handlers to choose optimal routes for delivery.
Monitoring and adjustment of food can be done with IoT. Keeping food fresh on its travel
to the store, making sure no food has gone bad during its travel by adjusting different pa-
rameters concerning the surrounding environment of the food items. This will improve the
efficiency of the food supply chain.
Mobile ticketing and augmented maps for tourist are also applications that could be possi-
ble in this domain [12].
3.2.2 Health-care
The key benefits of IoT en health-care is the tracking of people (staff and patients) and
objects, identification and authentication of people, automatic data collection and sensing.
Tracking is aimed at identifying people or objects in motion. This includes real-time

position monitoring. This could help hospitals improve workflow, by checking this data
in order to find choke points and affability in their buildings. Also, the tracking of objects
conditions would help the hospital keep inventory, check availability of machines and ob-
jects, as well as scheduling maintenance for their different machines. Also, tracking of
tiny equipment needed in surgeries, could prevent left-ins during surgery.
Identification of patients with IoT could prevent incidents harmful to the patients. Ex-
amples of harmful incidents could be wrong drug, dose or procedure given to a patient.
Or in other scenarios, loss of identification of infants. Identification and authentications
through IoT would also make hospitals safer inf the matter of the security: of patients,
personnel, important instruments and products.
In relation with data collection in hospitals, IoT aims to reduce time spent on manual
data registration, reducing workload on the hospitals staff, enabling them to do more im-
portant tasks. This functionality also relates to the integration of RFID technology with
health information, and the hospitals facilities.
Lastly, sensing in health care system could provide valuable information concerning pa-
tients health and diagnostics. Sensors could provide real-time monitoring of patients health
indicators. This could be combined with monitoring of patients compliance with different
medication, and could be used to adjust the well being of the patient. This monitoring
could be done remotely, enabling patients to be treated remotely [12].
15
3.2.3 Smart environment

The idea of smart environments is making the environment surrounding us easy and com-
fortable in different contexts. IoT will make the objects in our surrounding environment
intelligent, making tasks for us easier and more comfortable. Among these environments
are: at the office, at home, in an industrial plant or in a leisure environment.
Making homes and offices more comfortable could be achieved by installing sensors and
actuators in them. These sensors and actuators could control different aspects of these
environments based on sensing in them. Room temperature, air quality, room lighting can
be controlled by the sensors and actuators in relation with outdoor weather changes. An
example could be to have light shine brighter in the day. Also, it could make it easier to
adjust these factors to users own preferences. Monitoring of energy usage and adjusting
to it could also be done. An example could be that in tall building, heat tend to build up in
the upper floors, with sensors and actuators in place, the building may distribute the heat
evenly across all floors, instead of using energy to heat lower floors and using energy to
cool upper floors.
In industrial plants, deploying RFID tags on the objects being processed could supply
valuable information about bottlenecks of production, do in production quality control.
In addition, such system could acquire other information about the production, in order
to give staff better assessment basis in their decisions, especially in potential emergency
situations.
Other uses in relation to smart environments could be smart museums and smart gyms. In
smart gyms exercise machines could record your sets and repetitions automatically for the
user, eliminating the hassle of manually recording such information themselves. Also this
information could be view by a personal trainer afterwards, and could be used in order to
give better guides to the exerciser. In museums scannable tags could be placed near the
different attractions, making for a more interactive museum visit. In addition, actuators
could be activated in order to heat or cool rooms to what experience the museum wants
to give its visitors. An exhibition about the ice age could have a colder and windy inside
environment, and an exhibition about the pyramids, could have a warm and dry inside
environment [12].
3.2.4 Personal and social

In the personal and social domain, applications of IoT is in relation to peoples social life
and social interaction. The ideas is that IoT may help people interact with each other and
maintain and build relationships.
IoT may become an enabler of social networking. The idea is to have automatic updates
about our real-life activities posted on social media like Twitter or Facebook. RFID may
generate events about people or places, these events are further posted to social media in
order to give users real-time updates about what is happening around them and with the
people they know. These events will allow users to more closely follow their friends ac-
tivities, and participate in them
16
By having RFID tags on our things, people can easier identify things they have lost, or
things that have gotten stolen from them. The RFID tags can be activated by RFID readers
in our surroundings, ultimately this will allow us to check where we last had a thing before
we lost it. Concerning theft, sensors may know where the user usually is, so if readers read
an item from the user at a location the user normally wouldn’t find itself, the user will be
notified [12].
17
18
Chapter 4
State of the art of blockchain
technologies
The overall goal of in this thesis is to develop and make a sharing economy platform using
IoT and blockchain technology. To answer the research question the thesis, I had to do a
review of relevant blockchain technologies. This review will be done on the most valuable
blockchain technologies by their market cap. There are several different implementations
of the blockchain, each with its framework for using their technology. Researchers have
reviewed some of these technologies, but the majority is not researched at all, making ref-
erences for each technology of varying quality. I will research the different blockchain
technologies applications, and how they work. Along with other technologies that rely
on the blockchain data structure. Also, I will look into the blockchains use cases, and its
uses with IoT technology and devices. In other words, I want to understand the different
blockchain technologies to find which one I deem the most useful for the goal of this the-
sis. To do this, I have made five Questions for the review of blockchain protocols:
• Question 1: How does the blockchain work?
• Question 2: How does popular blockchain protocols work?
• Question 3: What are current applications of blockchain protocols?
• Question 4: How is the blockchain used with IoT in particular?
• Question 4.1: How is the blockchain used with IoT in a sharing economy context?
Structure of chapter 3:
Section 4.1 give some background information needed to understand how the blockchain
works. Section 4.2 discuss the search process in general for this chapter. Section 4.3, 4.4,
19
Chapter 4. State of the art of blockchain technologies
4.5, 4.6 and 4.6.1 answers the different question. Section 4.3 include a comparison matrix
of the different blockchain technologies written about in its section. Also, at the end of
each section, you may read about how I found the references I needed to answer each of
the questions.
4.1 Background
4.1.1 Cryptocurrencies
Coinmarketcap.com is a website that lists different cryptocurrencies. So far coin market
cap lists over 1300 different cryptocurrencies. Usually, each currency has their own pur-
pose and usage. The first cryptocurrencies were focused on simple peer-to-peer payments,
however, later on, there has been a rise in currencies which does more than just that. There
are currencies for tracking of pharmacy products with IoT devices like Modum [24], and
there are currencies like Dentacoin [25] which focuses on improving dental care around
the world, making it affordable through crowd power, the currency Tron aims to build a
tipping service for social media content, entertainment content, and streaming [26]. Cur-
rencies like Bitcoin, Litecoin, Bitcoin Cash, Dash and Monero and others, focus on de-
centralized peer-to-peer payments with each having their very own implementation of the
blockchain. Currencies like Ethereum, Cardano, NEO, RootStock, and Namecoin also
allow for decentralized peer-to-peer payment, but also focuses on the usage of smart con-
tracts, which allows their users to store code on their blockchain and have it run for a fee.
Many cryptocurrencies use the blockchain in some way or another; however, there are
exceptions. IOTA for instance uses a direct acyclic graph (DAG) in order to do transac-
tions [27]. The currencies usually have a surrounding system enabling the functionality
they promise to serve. Some of the currencies are coins, meaning that they have their very
own blockchain, some of the currencies are tokens which depend on another currencies
platform to operate, usually being Ethereum. All of these currencies’ tokens or coins are
traded at an open market and prices for each can be view at coinmarketcap.com [28].
4.1.2 Hash functions

Generally, a hash function takes any data of any length as input and transform the data
with a deterministic mathematical function. A hash function can be used to map data of
arbitrary size to data of fixed size. The output of a hashing function can be mapped back to
the original input, without necessarily letting us reconstruct the original product. Different
hashing algorithms will give different output with a variety of different properties. For
example in searching, hashing may speed up such process by indexing data in an array,
then search for the hashed string in the array with hashed data will indicate where the data
is stored in the array [29] [30]. A cryptographic hash function can provide assurance of
data integrity. A cryptographic hash function can be used to make a fingerprint of some
data. This is useful in the way that you can check the fingerprint of the data, to assure that
the data has not been tampered with. If the data have been tampered with, the fingerprint
will not be valid. This also applies when the data is not stored securely, you will always be
20
4.1 Background
[31]
Figure 4.1: A message M is hashed by hash function H, and a hash value h is returned. h can
uniquely identify M.
able to recalculate the fingerprint of the data, to check if it matches the old fingerprint. If
the fingerprints match, the integrity of the data is not impaired in any way. A cryptographic
hash function is not the same as encryption. A cryptographic hash function only makes a
”digest” of the original data in a one-way function, making retrieval of the original data
not possible. In a symmetric encryption function, one will be able to retrieve the original
data [32].
[31]
Figure 4.2: How a data integrity check is performed with hashing algorithms
21
4.2 General search process

To conduct the study of the blockchain and chain technologies, I decided to limit my re-
search to the top ten most valuable blockchain technologies. The reason for this is that
there currently over 1300 blockchain technologies, and to research, all of them would be
too extensive for this thesis. These ten are Bitcoin, Ethereum, Ripple, Cardano, NEM,
Bitcoin Cash, Litecoin Stellar, IOTA, and NEO. I have decided to leave Bitcoin Cash and
Litecoin out of the review because they only focus on value transfer similarly to the Bit-
coin implementation. To conduct the study of the basic implementation of the blockchain
I used the official white paper for Bitcoin, where the blockchain data structure was first de-
scribed supplemented with Andreas M. Antonopoulo’s work, describing Bitcoin [33]. The
book describes the blockchain and Bitcoin from a technical perspective, which it is useful
to understand how the blockchain function. The book was also useful with reference to
how other technologies function that make use of the blockchain data structure.
To conduct the study of the different blockchain technologies I started by using each tech-
nologys white paper, to then look for other research, to then look for articles, to then look
for news articles if no sufficient research were found. Many of these technologies are fairly
new; thus not much research exists on them. The release date of the technology is pos-
sibly a good limiter while searching for information on each of the papers. For instance,
Ripple and its coin XRP was released in 2012, no research on ripple was found before its
release. In addition to the technologies being new, many of the names of the technologies
have similar names to other research topics. Ripples is listed as its own topic in the NTNU
school library research database [9], and contains 1944 hits. Looking through 15 pages
of results, not a single paper was found on Ripple. Searching for just NEO in the NTNU
school library yielded 200 000 hits. I tried searching for NEO blockchain which yielded
86 hits. Of the 86 hits, only eight were peer-reviewed, and of these eight none were about
NEO. Of the 86 hits, 69 of them were newspaper articles; however, these were actually
discussing NEO. This is a general problem when researching the topic of cryptocurrencies
and blockchain technologies. Bitcoin, blockchain and Ethereum yield relevant papers and
research when searching in the NTNU school library databases [9], this is most likely due
to their age, they are no longer newcomers in the crypto and blockchain world. Also, the
names of these technologies are unique compared to the other technologies, yielding more
relevant search results. Another problem was the names of the different blockchain tech-
nologies. IOTA, for instance, is not solely related to IOTA as a blockchain technology but
also related to ultrasound technology [34], quantum physics [35] and more making it more
difficult to find relevant research even with different filters in place.
As the search results vary from technology to technology, so does the quality of the sources
I am using to research the different technologies. Each technology’s white paper was dis-
covered using Google with this string [Blockchain technology] white paper. The source
of each white paper is from the official company or foundation that owns the blockchain
technology. Some scientific papers were found on Bitcoin and Ethereum by searching
using their names as search words in the NTNU school library databases. In addition to
research other technologies making use of the blockchain I used these strings in Google:
blockchain-based applications, blockchain applications, and blockchain apps. And lastly, I
22
4.3 Question 1: How does the blockchain work?
used the string [Blockchain technology] IOT in NTNU school library [9], Google Scholar,
and Google.com to research blockchain technologies and IoT. To find more information
about the different blockchain and chain technologies the search word: ”[Blockchain tech-
nology] overview” was used. Further, references used in this information was also taken
into account when assessing their functionality and features. Also, official developers
guides from the blockchain technologies were used to supplement the information from
the white papers. This was done because the white papers usually describe a vision for the
blockchain technology, not the actual implementation, or at least not the state the technol-
ogy is in at the current time. The white papers are several years old, and changes may have
been done in the meantime.

Bitcoin Overview
• Was the first cryptocurrency and the first implementation of the blockchain
• Name of coin: Bitcoin (BTC)
• Consensus algorithm: Proof-of-work
• Is mineable
• Does not have a smart contract platform, has a high adoption in the crypto sphere,
and is capable of maximum seven transactions per second.
The Blockchain was first presented in the paper Bitcoin: A Peer-to-Peer Electronic Cash
System in 2009 by an unknown author under the pseudonym Satoshi Nakamoto [5]. It
describes a peer-to-peer currency system that allows for secure cash transaction over the
internet without the need for a financial institution as a middleman. This made possible
by a new data structure, also describe in Satoshi’s paper, named the Blockchain. The
blockchain enables the cryptocurrency Bitcoin (and others) to exchange its coins securely
across the internet. Like in the name, the blockchain consists of blocks that are chained
together. This is done by hashing the data of the new block, with the hash of the previous
block. Each block contains transactions in the Bitcoin network and each block in the chain
is linked to the previous block. With the creation of a new block, it is appended to the last
one, forming the blockchain. An easy way to look at the blockchain, is to look at it as an
immutable (except for the block thats forming to be added to the blockchain) transparent
database that contains the entire transaction history of all Bitcoins ever made, which in
turn enables the users to know what balance of coins each of its users has.
A user in the Bitcoin blockchain consist of a key-pair. A Bitcoin address consist of ran-
domly generated keys, a private one and a public one. The public one is the users Bitcoin
address. Other users of the Bitcoin protocol use their public address to receive Bitcoins.
And the private key to send Bitcoins. For sending Bitcoins, a user signs the transaction
with its private key. The other users verify the transaction by using the public key of the
23
user that sent the Bitcoins. The blockchain consist of blocks of transactions chained to-
gether. All of the blocks are structured by the same rules, and it is this structure that allows
for the chaining. A block consists of primarily four fields: Block size, block header, trans-
action counter and transactions. The block size field is 4 bytes, the block header field is
80 bytes, transactions counter field is from 1 to 9 bytes, and the transactions field vary
with how many transactions there are in the block 4.1. The block header field is calculated
based on six other fields 4.2. The block size field describes how large the block is with 4
bytes. The block header is the identifier of the block and is made up of a hash. The hash
is generated with the Secure Hash Algorithm (SHA-256) [36]. The SHA-256 generate an
almost unique fixed-size 256-bit hash. SHA-256 is a strict one-way function and is always
a 256-bit binary value.The block header is 80 bytes and is calculated based on three sets of
block meta-data. The first one is a reference to the last block in the blockchain and is the
hash of the previous block, effectively linking the new block to the last one. The second
set is data related to the mining competition: the difficulty, timestamp, and nonce. The
third piece of meta-data is the Merkle root tree of the current blocks transactions. The data
structure is used to effectively summarize all transactions in the current block into a hash.
Size Field Description

4 bytes Block Size The size of the block, in bytes, following this field
80 bytes Block header Several fields form the block header
1-9 bytes Transaction counter How many transactions follow
Variable Transactions The transactions recorded in this block
Table 4.1: Bitcoin block structure
Size Field Description

4 bytes Version The Bitcoin Version Number
32 bytes Previous Block Hash The previous block header hash
32 bytes Merkel Root A has of the root of the merkle tree of the block’s transactions
4 bytes Timestamp The timestamp of the block in UNIX
4 bytes Difficulty Target The difficulty target for the block
4 bytes Nonce The counter used by miners to generate a correct hash
Table 4.2: Bitcoin block header structure
When a block is going to be added to the blockchain, it needs to mined. Mining is done
by a mining node in the Bitcoin network. The mining node is responsible for compiling a
block based on the definitions of the Bitcoin blockchain protocol. The mining node needs
to fill out the two tables 4.1 and 4.2 to mine a block onto the blockchain. First, the node
needs to add the version number describing the block structure version. Next, the node
needs to add the hash of the Previous block, and this is the hash of the previous block’s
header. Next, the mining node acquires a number of un-mined transactions and generated
a Merkle tree for these transactions, to then store the Merkle tree root of the result. The
24
Merkle tree root summarizes all the transactions of the block. Then the mining node will
add the timestamp encoded as UNIX epoch timestamp. As Satoshi et al [5] describes, a
block should take at least 10 minutes to mine. Moreover, to keep the block mining time
at 10 minutes, the difficulty has to be adjusted accordingly. The difficulty target is set
according to what mining power there is in the network at the current time, that will result
in a 10 minute mining time of a block. So, the next for the mining node is to add the
difficulty based on the power of the network. The last step is to add the nonce, which is
initialized to zero. With all the fields filled, the mining process can start. The goal of the
mining process it to find a value for the nonce that results in a block header hash that is
less than the difficulty target. Brute forcing different nonce values to do this process. A
mining node typically needs to test billions to trillions of nonce values before finding a
satisfactory value. This is done by incrementing the nonce, to then hash the block header
repeatedly. By doing this, you are doing the proof of work described by Satoshi et al. [5].
When the right hash is found, it is broadcast to the network, verified by the network, and
the block is added to the blockchain [37]. Following the block header, comes the transac-
tions counter described with 1-9 bytes, and after that is all of the blocks transactions.
From this description it may seem that it only takes 10 minutes to do a transaction with the
Bitcoin protocol. However this is not the case. Because of latency in the system, not all
miners will receive the same transactions at once. Meaning that miners will try mining dif-
ferent blocks onto the blockchain. It is not allowed to add a transaction to the blockchain
that is all ready on the blockchain. Meaning that a miner may spend unnecessary com-
puting power on mining a block with a transaction that becomes added to the blockchain
before the miner is done finding the right nonce value. Another possibility is that two
blockchains are formed, when two miners add two different blocks at once. The Bitcoin
protocol have rule to solve such problem. When two or more blockchains are formed, it
is the longest blockchain that is valid. When the blockchains are equally long but with a
different block at its tip, it is up to the miners to decide which blockchain they want to con-
tinue the mining process with. When either one of the blockchains gets a block attached
before the other one, this blockchain becomes longest one, and miners will choose this one
to continue mining with. However, dual blockchains makes it possible that transactions
that were mined onto the blockchain that not became the longest one, becomes invalid be-
cause they are not on the longest blockchain. This means that they have to be mined onto
the new blockchain to become valid. As a safeguard for this, a transaction is only consid-
ered confirmed when it is at a six block depth. Meaning that a user must at least wait an
hour (10 minutes x 6 blocks) to be certain that its transaction if confirmed. A scenario like
this is also possible in other blockchain technologies, where block size and block mining
time is different. For instance, in the Ethereum blockchain a block takes on average 14
seconds to mine, making a scenario of having several blockchains in the network more
likely. Therefore users have to wait 12 blocks in order to be sure that their transaction is
confirmed. There are also other mechanisms in Ethereum mining that are more optimized
than in the mining of the Bitcoin Blockchain.
In summary, users make transactions, miners gather transactions into blocks, make calcu-
lations with the blocks finding the right hash for the block, getting the network of miners
to verify that their calculations are correct, add the block to the blockchain.
25
This is in the core of the blockchain data structure. However, different blockchain based
technologies may have different implementations of the blockchain. Variations could be in
block size, block structure, the proof that the miners need to perform, hashing algorithm,
difficulty, having mining and not having mining, mining time and more.
In general Blockchain protocols usually consists of nodes in a network. Nodes are ei-
ther worker/miner nodes or just normal user nodes. All nodes in the network have a public
address, and a secret private address. A blockchain protocol usually has a token or a coin
to do transactions with. Also, the addresses of the users are used to sign transactions to
show proof of ownership and the origin of the token/coin. However, this is not enough to
conduct a transaction. To do transactions, the worker nodes in the network must first form
transactions into blocks, and conduct some kind of proof in order to reach a consensus of
which blocks that should be added to the blockchain. This process is called mining. De-
pending on what consensus algorithm a blockchain protocol has uses, is what decides how
the worker nodes are reaching a consensus of which blocks and essentially which transac-
tions to add to the blockchain. The blockchain is an open ledger accessible to all nodes
in the network, and combined with a consensus algorithm is what makes the blockchain
protocols decentralized.
[38]
Figure 4.3: Simplified Bitcoin Blockchain
4.4 Question 2: How does popular blockchain protocols

work?
4.4.1 Ethereum
Ethereum overview
• Is blockchain based
• Name of coin: Ether (ETH)
26
4.4 Question 2: How does popular blockchain protocols work?
• Consensus algorithm: Proof-of-Work (will transition to Proof-of-stake in the future)

• Is mineable
• Have a smart contract platform, high adoption in the crypto sphere, and is capable
of 15 transactions per second.
Ethereum is based on the idea that the blockchain is not only useful for money transfer
only, but for other things as well. Instead of having a blockchain protocol designed for
one particular purpose, the Ethereum protocol is designed in a general way, that allows
its users to design different applications and protocols with the Ethereum blockchain at
its base. Ethereum is a blockchain, like Bitcoin, but with additions. The additions are
a built-in programming language called Solidity, and that anyone can create an applica-
tion with any rules when defined as a contract. In the Bitcoin blockchain, there is only
one type of account. However, the Ethereum protocol allows for two types of accounts:
A user account, which is similar to Bitcoin’s user account, and a Contracts account. A
user account sends Ether back and forth on the Ethereum blockchain, like with the Bit-
coin blockchain. And Ethereum user accounts can send transactions to contracts accounts.
A contracts account is an Ethereum account controlled by a piece of code that is on the
Ethereum blockchain.
A contracts account have an address on the Ethereum blockchain and are made by do-
ing a transaction with code inside it, with no recipient address. The code is put on the
Ethereum blockchain. After that, you can send Ether to the transaction with the code in-
side of it to have it run by the Ethereum network, more specifically the Ethereum Virtual
machine. The Ethereum protocol has the capability of executing a virtual computer in a
distributed and open manner. This is the Ethereum Virtual Machine (EVM). The programs
run by the EVM are called Ethereum smart contracts. The EVM that runs the Ethereum
smart contracts is made up of all the computers mining the smart contracts of the Ethereum
blockchain. The Ethereum smart contracts are put onto the Ethereum blockchain, making
the code immutable and public. This makes the smart contracts and its code trustworthy.
The smart contracts can be written in different programming languages. Among this are
Solidity, LLL, and Serpent with Solidity being the most popular programming languages
for the EVM. The code written in any of these three languages is not directly put on the
Ethereum blockchain. First, it’s compiled into EVM bytecode, and then the bytecode is
put onto the Ethereum blockchain. It is possible to write EVM bytecode directly; how-
ever, this is rarely done. Running your code on the EVM is not free, you have to pay some
Ethereum, known as gas, each time your contracts run. The gas price to run contracts on
the EVM fluctuates with the demand for computing power from the EVM [39]. The gas is
paid to the nodes in the Ethereum network that runs the contracts on the EVM.
A big difference in Ethereum from Bitcoin is the smart contracts. However, there are
also other differences. Ethereum uses a different hashing algorithm called Ethash, instead
of Bitcoins SHA256. Also, Ethereum’s mining algorithm is set up in a way that requires
the miners of Ethereum to fetch random data from the EVMs state, computing transactions
selected randomly, from the last N block in the blockchain and returning the hash of the
result. Due to this, Ethereum miners need to able to compute any kind of computation, and
27
they need to store the entire state of the Ethereum blockchain. Ultimately this removes the
possibility to make specialized hardware to mine Ethereum, enabling more people to take
part in the mining process, which in turn makes Ethereum more decentralized. Ethereum
does not have a block size for its blocks. Ethereum’s gas price decides the block size, and
the miners decide the gas price. If there are many un-mined transactions in the network,
block size will increase, gas price will go up because miners have to do more work, if
there are few transactions in the network block size may be decreased, and gas price will
go down because there is less work for the miners [40].
[41]
Figure 4.4: Smart contract system
4.4.2 Ripple
Ripple overview
• Name of coin: Ripples (XRP)
• Consensus algorithm: Federated Byzantine Agreement (FBA)
• Not mineable due to consensus algorithm
• Does not have a smart contract platform, high adoption in the crypto sphere, and is
capable of 1500 transactions per second.
• Banks want to use it for the international transfer of money
Ripple is a money transfer and payment system inspired by the blockchain [42, p. 24]. The
purpose of Ripple is to challenge the current global payment systems, which according to
28
Ripple is partially non existing, ineffective, convoluted, expensive, and inaccessible to

consumers and businesses. Ripple also state that current systems have low speed, limited
transparency, high cost, low connectivity and tractability for all of its users. This impacts
banks, businesses, and consumers. All of these problems are what Ripple intend to fix with
their coin XRP and the functionality of their network [42, p. 4]. Ripples coin is named
XRP, and it is transferred across Ripples ledger. However, unlike Bitcoin and Ethereum
this process is not done with mining. The transactions in the Ripple network does not use
any proof for its transactions. Transactions in the Ripple network is based on trust among
its nodes by the use of the Ripple Consensus Algorithm. It means that the nodes in the
Ripple network needs to be trusted because it is the nodes in the network that decided to-
gether which transactions are valid or not. Which is why decentralizing the Ripple ledger
is much more difficult, because it matters who are running the nodes you trust.
Ripple ledger or the XRP ledger is a shared, global ledger open to every participant in
the ripple network. And each participant can trust the XRP ledger because its made by
already trusted nodes. This shared ledger is a series of individual ledgers, which each of
the Ripple nodes keep locally. Transactions in the ripple network update the different ac-
count’s balances, then the balances are stored in the Ripple ledgers. This is unlike Bitcoin,
where only transactions are stored, and each user has to calculate the balance of Bitcoin
the other users have themselves. When new transactions are added, a new ledger is made,
this ledger is called an open ledger. After some time the open ledger is closed and awaits
confirmation from the network. When the consensus algorithm confirms the closed ledger
it becomes validated, it is at this time the information in the ledger is guaranteed to be cor-
rect and immutable [43]. Each of these ledgers functions like a block in the blockchain.
They have some sort of unique ID and a unique hash which identifies the content of the
ledger. The ledger is connected to the last ledger, like in the blockchain, with the hash of
the previous ledger. And when a ledger is validated by the consensus of the nodes in Rip-
ples network, it is added to the global ledger of validated ledgers. You can say that Ripple
is a ledger-chain. Because Ripple’s way of consensus does not include mining, makes the
Ripple network capable of handling 1500 transactions per second. Ripple also makes for
the possibility to make private networks within the Ripple network. This is done by hav-
ing two or more parties trusting each other in sending and receiving among themselves.
If nodes in the Ripple network can give assurance that they have a stable balance of other
types of currencies than XRP, they can send these type of assets across the Ripple network,
if the receiving party trusts them [44].
In summary, Ripple is a tool to move XRP or different assets globally without the need
for expensive bank systems. Ripple is not mineable. Instead, it uses trust among its users
to confirm transactions, with the Ripple consensus algorithm, which in turn make it less
decentralized than Ethereum and Bitcoin. Ripple focuses on well-established institutions,
which wants to move assets across borders inexpensively.
4.4.3 Cardano
Cardano overview
29
• Is blockchain based and may support multiple blockchains in the future
• Name of coin: Ada (ADA)
• Consensus algorithm: Proof-of-stake
• Does not have a smart contract platform yet, but will in the future
• Medium adoption in the crypto sphere, and is currently capable of 5-7 transactions
per second.
The motivation behind Cardano is to change the way cryptocurrencies are designed and
developed. Cardano wants to make a sustainable ecosystem for its users and systems want-
ing to integrate blockchain technology. Cardano is an open source project and started with
a list of ideas, design, and engineering best practices. From this list of ideas and practices,
the Cardano team set out to research cryptocurrency literature, resulting in an extensive
library of research papers. And then again, resulting in a decentralized public blockchain,
with the cryptocurrency ADA. Because of their extensive research, Cardano deems them-
selves as a platform that is based on a scientific philosophy. The Cardano cryptocurrency
is similar to Ethereum in the way that Cardano is also a smart contract platform. However,
Cardano seeks to deliver more advanced features and to eliminate the problems they see
with Ethereum. Bitcoin was the first generation blockchain, Ethereum the second, and
Cardano is the third generation blockchain. What this means is that Cardano have the
advantage of hindsight, learning from earlier adoptions of the blockchain, making the Car-
dano platform better suited for handling issues of the past blockchain protocols. Resulting
in a different blockchain protocol than for instance Ethereum.
Cardano’s first difference with Ethereum and Bitcoin is that it makes use of another con-
sensus algorithm. Cardano uses a Proof of stakes algorithm called Ouroboros, instead
of proof of work. Ouroboros is mathematically proven to be secure, and have been ex-
tensively peer-reviewed with many Universities taking part in its development [45] [46].
Ouroboros works that the Cardano network selects a node randomly to confirm the next
block. This node gets a reward from confirming this block. The selection process is based
on how many Cardano tokens you hold. The more tokens you have, the more likely you
are to be selected for the block confirmation. This also allows for token holders to pool
their tokens together to increase their chances of getting selected for the block confirma-
tion and getting the block reward. So instead of having a lot of processing power, like with
the proof of work, you need to have many tokens to confirm blocks. Proof of stakes does
not require the computational power race to get to confirm a block, along with little need
for large-scale computing resources, making PoS more scalable and energy efficient [47].
In Ethereum smart contracts and normal transactions are not separated, in Cardano, this is
not the case. Cardano is separated into two layers, The Cardano Settlement Layer (CSL)
and the Cardano Control Layer. The Cardano Settlement Layer is responsible for handling
the token economics and user account’s balances. In other words, the Cardano settlement
30
layer is made for handling Cardano’s token, ADA, and its users, the basic value trans-
fer. The Cardano Control Layer is where all the smart contract functionality of Cardano
exist, along with other functionality like digital identity. The advantages of separating
Cardano into these two layers is that you do not need metadata for doing transactions, like
in Ethereum and others. Moreover, it allows for updating the two layers separately, not
putting the other layer at risk [48].
4.4.4 NEM
NEM overview
• Is blockchain based
• Name of coin: Xem (XEM)
• Consensus algorithm: Proof-of-importance
• Does not have a smart contract platform
• Low adoption in the crypto sphere
NEM stands for the New Economy Movement and is blockchain protocol intended to sup-
port the blockchain economy. In its basic form, NEM is just another blockchain based
cryptocurrency. However, it integrates technologies from other cryptocurrencies such as
Bitcoin and academic research in network theory, with a coin named XEM. The primary
contribution NEM gives in the landscape of cryptocurrencies, is NEM’s consensus algo-
rithm named Proof of Importance (PoI). Proof of Importance consensus algorithm also
seeks to eliminate the difficulties and challenges of Bitcoin’s and Ethereum’s proof of
work. Ultimately making the NEM blockchain protocol environmental friendly and sus-
tainable concerning Bitcoin’s scaling and power issues. NEM’s PoI is similar to Cardanos
PoS, except it does not solely rely on the balance of the nodes confirming the transactions
in the network. PoI wants to rewards other behaviors in the network that are believed to be
positive for the economy of NEM. The NEM protocol wants to reward active nodes in the
network at the expense of the inactive ones, along with dampening the effect that the rich
would get richer, which is usually the case with PoS. Also, NEM wants to function as the
core ledger of data systems. NEM does not have smart contract functionality [49, p. 16]
[50, p. 1].
The way of making a block with the NEM protocol is called harvesting. To harvest trans-
actions into blocks, the miner must prove its importance. First off a node needs to have at
least 10,000 XEM to eligible to be a part of the PoI calculation. Next, the account must
have transferred an amount of at least 1000 XEM, and this must have happened within the
last 30 day or 43200 blocks. Also, the 10,000 XEM must be vested, which means it must
have stayed at the same address for some time. Your XEM becomes vested at a rate of
31
10% per day, which means that for instance, 20000 non-vested XEM in your wallet will
become 10000 vested XEM within seven days. When a transaction is made the first node
in the network notify nearby nodes about the transaction. At some time the information
about these transactions will reach a node with at least 10000 vested XEM, this node will
then generate a block and receive the transaction fee that the block pays. The more trans-
actions a node completes, the higher importance the node gets, which in turn enable the
node to harvest and create new blocks [51] [50, p.27].
NEM also allows for messaging across its network in three different ways: encrypted, un-
encrypted or hex messaging forms. No XEM transaction needs to be done for the message
to reach its recipient in the XEM network. This could be used for secure communication
and other blockchain-based applications. However, to send these messages, you must pay
at least 1 XEM in fees, or more if the messages are encrypted. NEM also allows for Mul-
tisignature transactions. This means that a certain transaction from a certain account needs
to be signed by a given number of accounts associated with the account to broadcast the
transaction to the network and to ultimately become confirmed and put on the blockchain.
The account that eventually does the transactions after enough of the associated accounts
signs, is called a Multisignature account. Since a Mulitsignature account requires other
accounts to sign its transactions, means that if one account associated with the Multisig-
nature accounts loses its wallet through a hack, no XEM can be spent from that wallet
without the other accounts, which are associated with the Mulitsignature account, signing
transactions from it. This is also useful for protecting community-held funds, in the way
that many users must agree upon where the funds should, if the majority does not agree,
the transaction do not get enough signatures, and is therefore not sent [50, p.12-13].
4.4.5 Stellar
Stellar overview
• Was originally a fork of the Ripple protocol
• Name of coin: Stellar Lumens (XLM)
• Consensus algorithm: Federated Byzantine Agreement (FBA)
• Low adoption in the crypto sphere, and is capable of 4000 transactions per second
The background for the creation of Stellar is similar to Ripples. Stellar wants to make
a fast financial network open to everyone which solves the problems with the current
financial systems. Stellar describe the current financial systems as a system with slow
transaction speed, high cost, and high maintenance. Stellar wants to solve this with the
power blockchain technology, their new model for consensus called federated Byzantine
agreement (FBA), along with the Stellar Consensus Protocol (SCP). Stellar also state that
their protocol avoids problems that the Bitcoin protocol has, especially in relation to en-
ergy consumption and high latency of transactions. Also similar to Ripple, Stellar want to
32
let financial institutions issue tokens representing fiat currency [52, p.1]. Many similarities
can be drawn to Ripple, when it comes to Stellar, Trustlines are one of these. Trustlines
in Stellar is a relation between two or more actors. A trustline is made when an actor can
guarantee for a certain asset, like fiat, Lumens (Stellars native coin), gold or other physical
assets, and the other party trust this actor [53]. Trustlines between more parties is called
a Quorum slice. Within the quorum slice, the actors can trade assets between each other
without the consensus of the entire Stellar network. The entire network of nodes is called
the Quorum, hence the name Quorum slice which is just parts of the network [52, p.4].
Trustlines and Quorum slices and the consensus protocol (with variations) is also found in
the Ripple Protocol. This is likely because the first implementations of stellar was a fork
of the Ripple network, and had a high resemblance to the ripple protocol [54] Stellar also
allows for Multisignature accounts like with the NEM protocol, apart from that Stellar has
only minor smart contract alike functionality, due to its designers believing that smart con-
tracts with high functionality like Ethereum could expose the Stellar network to security
and instability issues [55]. Their philosophy is that users of the network will use the Stel-
lar Protocol and network as backbone infrastructure for asset transfers within applications,
this is another reason for the Stellar protocols few smart contract options [56].
4.4.6 IOTA
IOTA overview
• Not blockchain based, instead it is based on a directed acyclic graph named The
Tangle
• Name of coin: IOTA (IOTA)
• Consensus algorithm: DAG
• Not mineable due to its structure
• Low adoption in the crypto sphere, and may be capable of 71 000 transactions per
second with higher adoption.
The creation of IOTA has similar motivation as many other cryptocurrencies: to eliminate
flaws with the Bitcoin protocol. IOTA is focused on eliminating flaws in the Bitcoin proto-
col concerning transaction fees, transaction speed, scalability, and other problems related
to Bitcoin’s crypto mining-economy. IOTA have a coin, named IOTA, which is specifi-
cally designed for the IoT industry. Along with their coin comes their surrounding system
allowing for making transactions, named the Tangle. The tangle is not blockchain based.
The Tangle is a Directed Acyclic Graph (DAG). In Tangles DAG nodes only have edges
directed to older nodes than themselves. Each node has two edges pointing to two older
nodes in the tangle. Moreover, each node in the Tangle is a transaction, where the newest
node, confirms the second newest nodes and so on. When a node has at least to two edges
from a newer node, it is confirmed. The tangle will always have tips or a tip. A tip is
an unconfirmed node. When new transactions are added, they will make an edge/edges
33
pointing at the old tip/tips. When the old tip gets two or more edges from new nodes/-
transactions, it is confirmed. This is what makes IOTA scalable. The more transactions
that are getting added to the tangle, the faster transactions will get confirmed, unlike the
Bitcoin protocol where the transaction speed is static, and you may wait a long time be-
fore your transactions get confirmed. In Bitcoin, you have to wait for at least six blocks
mined to be sure that your transaction is legitimate. In IOTA you measure the integrity of
each transaction by its nodes cumulative weight. The cumulative weight is the sum of all
nodes in the network pointing directly or indirectly to a specific transaction. This means
that the more transactions that get added, the more integrity, the older transactions get.
Due to transactions confirming the latter once, IOTA does not need mining and therefore
have no fees for doing transactions in its network [27, p.1-3]. However, to do a transaction
with the Tangle the sender of a transaction must do a PoW. This PoW is only done once,
and only by the sender of the transaction. This type of PoW is not the same as the BTC
or Ethereum PoW. Since the PoW is only done by one actor, and not the entire network,
no computational power is left unspent. This small PoW in IOTA is done to attach the
transaction to previous ones and to prevent malicious spamming of the Tangle [57],
[58]
Figure 4.5: This is how IOTAs DAG, the Tangle, looks like. Each node represent a transaction. And
the green ones are confirmed transactions, and the red ones are awaiting confirmation. A transaction
is confirmed only if all tip nodes (the grey nodes) directly or in-directly point to it.
This allows IOTA to do microtransactions. In the cryptocurrency markets, IOTA is

sold in MIOTA, and one MIOTA is one million IOTA. A microtransaction in the tangle
must at a minimum consist of one IOTA. Let’s say 1 MIOTA is worth 1 dollars, this would
allow us to send 1/1000000 of a dollar, which is not possible with the Bitcoin protocol,
and other cryptocurrencies. At IOTAs current states the DAG is not entirely decentral-
ized. This is due to the 1/3rd transaction attack. This means that an attacker could forge
1/3rd of the transactions in the tangle. This would lead to the confirmation of non-legit
transactions. The size of the tangle mitigates this attack, however, the tangle does in its
current state not have enough transactions to do so. Therefore each transaction must pass
through what IOTA calls a Coordinator, which controls transactions for malicious activity.
Once the Tangle is large enough, the Coordinator will be removed, and the tangle will be
completely decentralized.
The micro-transactions in IOTA is a fundamental feature, in the matter of IoT technol-

ogy. The IOTA foundation is picturing the IOTA and The Tangle as the backbone for the
new IoT industry. The idea is to send data from IoT devices, between other IoT devices,
34
and other machines. The data is sent in transactions in The Tangle with IOTA’s coin,
with practically no cost [59]. IOTA also promise the ability to transfer data securely and
un-tamperable through the Tangle [60] [61]. There are rumors that IOTA will have some
Smart contract functionality, something IOTA does not have at its current state [62].
4.4.7 NEO
NEO overview
• Is blockchain based, and have two coins in its ecosystem
• Name of coins: NEO (NEO), NeoGas (GAS)
• Consensus algorithm: Delegated Byzantine Fault Tolerance (dBFT)
• Not mineable due to its consensus algorithm
• Does have a smart contract platform
• Medium adoption in the crypto sphere, and may be capable of 10 000 transactions
per second
NEO is a blockchain protocol, formerly known as Antshares [63], with the goal of trans-
forming real-world assets into digital ones. NEO wants to do asset record keeping with
e-contracts. With Bitcoin the goal is to transfer values, NEO wants to bridge values and
financial systems with the digital world. NEO promises a long list of features, with the
most notable ones being Smart Contracts, Digital identity, and digitally programmable as-
sets [64]. Some of these features are also found in the Ethereum protocol, and the two is
therefore often compared with each other. NEOs smart contracts have great variety in how
many programming languages you can write them in. Some of them are C#, Java, C/C++,
JavaScript, and Python. The reason for this is NEOs goal of making digital assets avail-
able to everyone [65]. The smart contracts run on NEO’s Universal Lightweight Virtual
Machine, NeoVM, similar to Ethereums EVM. NEO also has its own tokens called NEO
(NEO), and NeoGas (GAS). NeoGas is distributed to the holders of NEO over a period
of 22 years. The GAS tokens are meant for making an economic incentive for the users
in the NEO economy to the different services that users supply. These services could be
bookkeeping, storage of tokens, and the execution of smart contracts. Similar to Ethereum
you pay gas for your contracts to be executed, or your transactions to be confirmed with
Ethereum, in NEO they made an individual token for this type of actions [64].
NEO uses Delegated Byzantine Fault Tolerance (dBFT) algorithm to reach consensus in
their network. It is somewhat similar to the PoS algorithm in the way that it is the token
holders who confirm transactions. However, in NEO, token holders select a bookkeeper
that they support by voting for it. This is the delegation process. The most voted for book-
keepers, through Byzantine Fault Tolerant, reach consensus and generate new blocks. In
the NEO dBFT, the generation of a new block takes about 15-20 seconds, giving a transac-
tion throughput of 1000 transactions per second. However, the NEO team states that with
more optimization the NEO dBFT could reach a transaction per second of 10000. The
35
NEO dBFT combines digital identity technology, which allows bookkeepers in the NEO
ecosystems to have real name identities associated with individuals or institutions. This
can allow for interactions like freezing, revoking, inheriting, and retrieving assets due to
judicial decisions regarding the assets. This is what makes NEO capable to register digital
assets [64].
4.4.8 Comparison of blockchain technologies
36
Name Bitcoin Ethereum Ripple Cardano NEM Stellar IOTA NEO
Blockchain based Yes Yes No Yes Yes No No Yes
Consensus algorithm PoW PoW FBA PoS PoI FBA N/A dBFT
Transactions pr second (TPS) 2,3 [66] 8,5 [66] 11,81 [67] 5-7 [68] N/A 1000-3000 [69] 2,4 [70] 1000 [71]
120-71 000
TPS max 7 [72] 15 [73] 1500 [67] N/A 3000 [49, p. 7] 4000 [69] 10 000 [78]
[74] [75] [76] [77]
Transaction fees Yes Yes Yes Yes Yes Yes No Yes
Mineable Yes Yes No No No No No No
Smart contracts No Yes No Not yet No No No Yes
Adoption High High High Medium Low Low Low Medium
Scalability Low Medium High High High High Very high Very high
Table 4.3: A comparison of the different blockchain or blockchain alike technologies

Explanation and discussion of matrix
Explanation for Blockchain based: This describes if the protocol is blockchain based or
not. The exceptions in this section are Ripple, Stellar and IOTA. Ripple and Stellar use
a structure very similar to the blockchain structure but are technically not blockchains.
IOTA uses a DAG.
Explanation for Consensus algorithm: Some of the different blockchain and chain pro-
tocols use different algorithms to reach consensus in their network. PoW: Proof-of-Work,
FBA: Federated Byzantine Agreement, PoS: Proof-of-Stake, PoI: Proof-of-Importance,
DAG: Directed acyclic graph, dBFT: Delegated Byzantine Fault Tolerance
Explanation for transactions per second and TPS max: Each blockchain protocol has a
theoretical max transactions per second and a current transactions per second. There are
usually variations in block size and consensus algorithm that are the deciding factors when
calculating the theoretical max transaction speed. Some protocols may reach the theoreti-
cal max speed, and some protocols may never reach it. Bitcoin’s theoretical max is seven
transactions per second, and this is the number you get when you assume that a transac-
tion only has one input and one output (which is usually not the case [79]), however during
Bitcoins lifetime, this transaction speed has never been observed [80]. This is also because
priority is given to transactions that yield higher transaction fees, making transactions pay-
ing lower fees left out of blocks, and may therefore never get confirmed. On the contrary,
we have Ripple. Ripple has a theoretical max transactions speed of 1500 transactions per
second. However, the transactions in the Ripple network has so far never needed this high
throughput [67]. Because of the differences between theoretical transactions speed and
maximum transaction speed I have decided that the table describes the current transaction
speed of the blockchain protocol, as well as their theoretical max. It is also important to
note that the transaction per second does not reflect when users receive coins through the
different blockchain systems. With Bitcoin, for instance, a user must wait for at least six
blocks after its transaction is confirmed to be certain that the transaction will stay on the
blockchain. As we know, block confirmation time on the Bitcoin blockchain is usually
around 10 minutes, making a user wait at least 60 minutes to receive its coins.
Explanation for transaction fee: Most blockchain and chain protocols usually have some
transaction fee to get your transaction confirmed. Some transaction fees are insignificant,
like with the Stellar protocol, where sending XLM only costs 1/100000XLM ∗ number
of operations of your transaction (One XLM is currently worth 0.23 USD) [81]. In con-
trast, historical data on Bitcoin transaction fees show that the average transaction fee has
fluctuated between 1 dollar and 55 dollars during 03.2017-03.2018 [82].
Mineable or not: The definition of Mining is doing a proof of work [83]. Other coins
have mining alike functionality, however, it is technically not mining. For instance, with
the Cardano protocol, you can confirm transactions by staking your coins, you receive an
amount of ADA for doing so. The amount you receive is the transaction fee. However, no
new token is generated by this. Also, confirming transactions in PoS does not require any
significant amount of computing power or calculation.
38
Explanation for smart contracts: Simply stating whether or not a blockchain protocol has a
smart contract platform or not. Ethereum and NEO are the only blockchain protocols with
smart contract functionality at the current state. Cardano is developing a smart contract
platform, but this is yet to be released.
Explanation for adoption: the adoption level is estimated by highest transaction volume
and highest trade volume in dollars. The best indicator would likely be transaction vol-
ume, however for many of the blockchain protocols these numbers were hard to come by.
Bitcoin, Ethereum, and Ripple had the highest adoption of all of the blockchain protocols,
both in the transaction volume and trade volume [84] [28]. When taking trade volume
into considerations for the other protocols Cardano and NEO had approximately double
the trading volume of NEM, four times the trading volume of Stellar and IOTA, with IOTA
having the lowest volume. The trading volume gives us an idea of adoption. However, a
protocol could have a higher transaction volume without an increase in trade volume.
Explanation for scalability: Scalability is likely one important factor to run an IoT plat-
form on top of a blockchain protocol. The easiest way to determine scalability lies in the
potential transaction max. Again, some of these numbers are unlikely ever to be reached
by its blockchain protocol, and other numbers are from statements or white papers from
the blockchain protocols developers.
4.4.9 Search process of popular blockchain protocols

To get the basic understanding of each technology, I started by seeking out the white papers
written by their founders and creators. For general information about Bitcoin and the ba-
sic implementation of the blockchain: I searched for blockchain whitepaper at google.com
yielded 11 million hits. The first hit was from the Bitcoin project, the original publisher of
the Bitcoin white-paper, this was the paper I chose to use for answering the first RQ. Along
with the book Mastering bitcoin, was found by searching for block header on google.com.
This search word was used to find more in-depth knowledge about the structure of the
blockchain.
Ethereum: found ethereum.org through google.com by searching for ”ethereum.” ethereum.org
lead to Ethereums official GitHub repo. From there I found their official paper describing
their technology [85]. Also related to the same search word I found a Youtube video of the
founder of Ethereum explaining its features and functionality [86].
Ripple: searched for ”ripple white paper” at google.com, found three relevant documents.
Three from ripples official site: a technical paper on the Ripple protocol, official documen-
tation for the ripple system, and a high-level solutions guide, both published by Ripple.
Lastly, the Google search also revealed Ripples initial white paper, released before their
ICO [87] [42] [88].
Cardano: searched for ”Cardano white paper” at google.com. Found official website for
Cardano, ”cardanohub.com,” found the white paper in the white paper sections of their
page [89], along with five academic papers listed in their ”academic papers” section [90].
NEM: searched for ”nem white paper” at google.com Found the official website for NEM
and their white paper along with full documentation for the project [49] [91] [50]
39
Stellar Lumens: searched for ”stellar white paper” found white paper at official site [52].
IOTA: searched for ”iota white paper” found white paper at official site [27].
NEO: searched for ”neo white paper” found white paper at official site [64].
4.5 Question 3: What are current applications of blockchain

protocols?
In the book, ”Research Handbook on Digital Transformations” by F.Xavier Olleros and
Maijinda Zhegu [92], discusses different aspects of the today’s digital transformation.
Among their topics is the blockchain, along with the Bitcoin protocol, Ethereum protocol,
and others. In addition, different applications of the blockchain are listed and described.
F. Xavier Olleros and Maijinda Zehgu divide the applications of the blockchain primarily
into three different categories: Financial instruments, Crypto-governance instruments, and
Other instruments. Based on their categorization I will describe some of the applications
of the blockchain.
4.5.1 Financial instruments

The most basic application of the blockchain protocols is encrypted value transfer. Also,
all of the blockchain protocols covered, have this functionality with their token or coin.
However, there are variations. The basic implementations, are the mineable value transfer,
with some anonymity, and is protocols like Bitcoin, Litecoin, and Bitcoin cash. Other
protocols do value transfer but focusing on complete anonymity, like Monero [93] and
Zcash [94]. Further, we have Stellar and Ripple that allows for value transfer, but also
allows for real-world asset to be transferred with their protocol (like gold or fiat currency).
4.5.2 Governance
The governance category covers the functionality of blockchain protocols or blockchain
based systems that goes beyond pure financial related usage. After the release of the Bit-
coin protocol, most innovations in the blockchain sphere have happened in this category.
Subcategories of Governance blockchain applications can be Data Storage, Smart Con-
tracts, Digital identity and Voting systems. These applications are not strictly tied to its
subcategory and may share functionality with other protocols. An example could the be
the usage of Ethereum smart contracts to do voting [95]. Usually, blockchain protocols do
have some kind of token or coin, which makes it possible to transfer value with all of them.
However, in many of these protocols, the tokens or coins are needed to make transactions,
and the transactions are needed to make use of the functionality that the blockchain proto-
col offers. For instance, with the Ethereum protocol, you need Ethereum to activate smart
contracts. This is not unique to Ethereum. There are blockchain protocols like Emere-
coin (a fork off litecoin) that have many different services aimed to be decentralized, all of
which you have to pay for with their Emercoin. Some of Emercoins services are decentral-
ized -storage, -advertising, -SSL based authentication, and -SSH management and access
control. Among its users are Deloitte Ukrainian office, which develops an Emercoin-based
40
4.5 Question 3: What are current applications of blockchain protocols?
document management system. The Russian Railways uses the Emercoin blockchain to
record data for the Russain Railways freight shipping e-marketplace [96]. Emercoin also
offers a decentralized storage solution. This functionality is found in other blockchain
protocols as well, like Storj, Sia, and Maidsafe. They all work in a way that somewhat
similar to striping in a NAS, except it is across other peoples computers and disks, instead
of your local disks. So in the different networks with the different blockchain protocols,
each user make their disk space available for storage, in turn, they get tokens or coins.
There are different cryptographic algorithms in store for each of the protocols, making the
data stored for the users inaccessible to the people that host the data. This is made possible
with the use of the blockchain. This description is a general explanation of decentralized
storage and may vary from protocol to protocol [92].
The smart contract approach in the blockchain sphere is based on the idea that the net-
work of nodes connected to the protocols blockchain is running code from the blockchain
together. There are different approaches for running smart contracts in the different pro-
tocols like described with Ethereum and NEO. And smart contracts is at the core of other
interesting functionality in blockchain technology. For instance electronic voting. There
are several issues, and problems with e-voting, one of them are storing and tallying cast
votes. As we know, the data on a blockchain is to a high degree immutable, making it op-
timal for storing votes. This would mean that if the blockchain were to be mined correctly
and safely, the integrity of the votes stored on it would be very high. Moreover, due to the
nature of the blockchain being transparent, people would be able to follow the voting pro-
cess, and other important principals in voting would be fulfilled. Also, blockchain voting
with smart contracts would allow for even better security, and integrity when voting [97].
This has been tested by Patrick McCory and his team showing that smart contracts on
Ethereum can do electronic voting securely with high integrity on a small scale [95]. This
is a great example of how smart contracts enable different usage of the blockchain, and
blockchain protocols.
4.5.3 Other
There are also blockchains protocols that fall outside of these two groups. Example of
these could be the blockchain based systems Omni and Bitmessage. These blockchain
protocols are made for message sending, in a decentralized and secure manner [98] [99].
Other protocols could be OpenBazaar which is a fully decentralized marketplace, with no
fees for its users, and all payment is made through cryptocurrencies. GridCoin is another
blockchain protocol which serves a scientific purpose. It is based on the idea that the
computation done on the Bitcoin blockchain is a waste of energy, and that this energy and
computing power could be used for something better. With the GridCoin protocol you lend
your computing power to different scientific project that can make use of decentralized
computing power. In turn you get GridCoins. The GridCoin protocol have been used in
calculations for cancer research, AIDS and malaria related medicine research, the mapping
of the Milky Way and cracking of Enigma machine codes. GridCoin uses a combination of
Proof-of-stake and Proof-of-Research in order to reach consensus in its network [100] [92,
p. 241].
41
4.5.4 Table of blockchain applications
Financial instruments Governance Other

Data storage:
Value transfer:
Emercoin Crypto communcation:
Bitcoin
StorJ Omni
Lite Coin
Sia Bitmessage
Bitcoin Cash
Maidsafe
Smart contracts:
Anonymous coins:
Ethereum Decentralized market place:
Monero
NEO OpenBaazar
Zcash
Cardano
Real world assets: Digital identity:
Scientific purposes:
Ripple NEO
GridCoin
Stellar BitID
Voting systems:
Ethereum
Nxt
BitCongress
Table 4.4: Table of different applications of blockchain technologies in different areas
4.5.5 Search process for applications of blockchain technologies
To answer Question 3, I used the string ”Applications using blockchain technology” in

Google and Google Scholar. From the results I decided on using the book ”Research
Handbook on Digital Transformations by F.Xavier Olleros and Maijinda Zhegu [92] that
discussed the use of different applications of the blockchain. The book’s overview of
use cases and sectors for blockchain technologies was adequate to answer my question.
Further, citations related to the different usages of the different blockchain technologies
and information about the different blockchain technologies from this book were used to
give better insight in the technologies use cases, but also in discovering more use cases
not mentioned in the book. Among these was the discovery of the privacy and anonymous
focused blockchain technologies. I found more information about these by looking up
”monero white paper” and ”zcash white paper” in Google. These strings led us to find
the official white papers of both Monero [93] and Zcash [94]. The citations used in the
book was a blockchain technology named Emerecoin [96]. The rest of the references for
answering question 3 was found in the book.
42
4.6 Question 4: How is the blockchain used or can be used with IoT in particular?
4.6 Question 4: How is the blockchain used or can be

used with IoT in particular?
The blockchain could be included in the different perspectives of IoT, namely internet-
oriented and semantic-oriented, i.e., in the infrastructure of IoT and data handling and
analysis [13]. Researchers and companies have realized this, and have in turn started to
investigate and develop its possible usages. What these researchers and companies have
investigated is what I will write about in this section.
”Blockchains and Smart Contracts for the Internet of Things” is a paper from IEEE dis-
cussing the possible use and usages of Blockchain in IoT solutions [101]. It is stated that
IoT should make a shift towards a decentralized architecture, in order to be sustainable.
Because the current centralized IoT models have a high cost due to maintenance. Es-
pecially considering the distribution of firmware and software updates after the devices
have been discontinued by their manufacturers [102]. There is also a lack of transparency
and trust between users and IoT devices. For instance with smart TVs sharing viewing
habits without the user knowing of it [103]. Veena Pureswaran proposes that IoT de-
vices integrated with a blockchain would make for a trustless peer-to-peer model, and
with the blockchain would be able to operate transparently, and transfer and distribute
data securely [102]. Based on some of these problems and ideas, ”Blockchains and
Smart Contracts for the Internet of Things” propose and discuss IoT systems integrated
with blockchains and smart contracts. Already existing systems and their ideas include
firmware authentication system for IoT devices, a device to device economy, smart con-
tracts connected to physical locks, supply chain security and distributed power generation,
all with the help of the blockchain [101].
One of the ideas of the paper is about firmware and software updates of IoT devices.
A common problem in the IoT sphere is non updated IoT devices not cooperating properly
with other devices, along with the issues that non-up-to-date firmware or software on a
device is a security risk. To solve this problem IEEE writers propose the idea of connect-
ing all devices in an IoT system to a blockchain. Then the manufacturer would make and
deploy a smart contract on this blockchain, allowing the devices to store the hash of the
latest firmware update. The devices would need to check if their firmware is up to date
with another smart contract in the network. This is done by using the smart contract to get
the hash of the latest firmware update, if the devices hash does not match the hash returned
by the smart contract, the devices would need to update. The first devices to update would
receive the update straight from the manufacturer, and the other devices would only need
to connect to other devices with the hash of the new firmware, which they got from the
smart contract, and receive the update from them. This means that if a device is segregated
from the network, it would be able to join the network and get the newest update of the
firmware. This would all happen automatically, without the need for user interaction. And
with the use of a blockchain with a cryptocurrency, the devices with the newest firmware
could charge the other devices with older firmware for sending them the newest version,
effectively making a device-to-device economy and market. IoT devices connected to a
blockchain with a cryptocurrency would be equivalent to giving IoT devices a bank ac-
43
count. IoT devices could then expose their resources to other devices and the user making
money from their abilities, like in the example above [101, p.2298].
Slock.it is another interesting IoT blockchain interaction. Slock stands for smart elec-
tronic lock, and it is the combination of smart contracts and physical locks. If you have a
device that carries the right token, you can physically open the door with the Slock on it.
Such token can be bought on the Ethereum blockchain. A Slock can be placed on cars, on
doors to real estate, on lockers, or anything else that uses a lock. So let’s say a user wants
to rent a car or a house, he would buy a token or get a hold of one through a smart contract
that counts time use for instance. Then the user would use the token on the Slock to gain
access to the house or the car. Afterward price for the rental is calculated, and the user
spends his Ether [8].
To turn away from fossil fuel and non-environmental energy, neighborhoods over a wide
area in Brooklyn, New York has started to use solar panels to power their homes. Also,
the solar panels of the different neighborhoods are connected to the Ethereum blockchain.
The idea is that, that not all solar panels are getting shone upon every time of the day, this
lost energy would need to be compensated for by using other sources of energy. However,
in the Brooklyn case, solar panels that generated more power than was consumed, can
sell their excess power to households who have less efficient panels. These transactions
and transfers of energy are done automatically by the devices, with smart contracts on the
Ethereum blockchain [104].
Wabi is a crypto token especially designed for securing consumer products. Wabi was
made as an answer to various food scandals, production of fake goods and fake pharma-
ceuticals in third world countries [105]. Among the food scandals that inspired the product
is the Chinese milk scandal in 2008, where six babies died, and 54,000 babies were hos-
pitalized, and the reputation of Chinese food exports was damaged. At some point in the
supply chain of the milk products, the organic compound Melamine was added to the milk.
Melamine is sometimes illegally added to food products to increase their apparent protein
content [106]. Melamine can cause kidney stones and renal failure and is not approved by
the Worlds health organization or national authorities [107]. The addition of illegal sub-
stances to food products, replacement of real products with fake once, and the production
of fake products are problems tied or solvable with adequate supply chain security, and
this is what Wabi wants to do. Wabi is divided into two parts, a blockchain, and a physical
RFID label with anti-copy functionality, connected to their blockchain. The idea is that
for each step in the supply chain the Wabi RFID label is scanned, and a transaction is done
on the Wabi blockchain, with the RFIDs chips unique id. The scanner of the product is
the one mining the Wabi blockchain and is awarded Wabi tokens. When the product is
scanned throughout its way in the supply chain, consumers can scan the label when the
product is in the store shelf, to check the origin of the product, and whether or not the
product is compromised. The label is also made in such a way that it becomes secure to
tampering by easily breaking when handled too roughly [108].
44
[108, p.11]
Figure 4.6: Backside of the tamper-proof Wabi label
IBM has been researching IoT with blockchain integration at least since 2016 [109].
IBM states that even though blockchain has gained a lot of attention in the financial sphere,
the blockchain may be the way to go in order develop decentralized IoT solutions, coor-
dinating devices as well as facilitating transactions between them. IBM see a lot of new
possibilities by combining IoT and blockchain, pointing out possibilities in different indus-
tries. The different industries were Supply chain, automotive, energy and utilities, health-
care, home automation and other industries. Other companies like Chain of things [110]
and filament [111] have also identified some of these possibilities, along with the other
companies previously discussed IoT blockchain solutions [112]. The automotive indus-
try is already implementing IoT devices in their products. One of these could be the use
of sensors in users cars. The sensor measure how good the driver of the car is driving
regarding their insurance policy. The sensors measure different aspects of the driving to
calculate a risk score for the driver. What the sensors measure could be anything from
position, acceleration, retardation, and revolutions per minute of the vehicle, along with
speed concerning speed limits in the area the driver is in and speed variations over time.
The data is put on the blockchain, in turn, the insurance company, can adjust the pricing of
your insurance. IBM is also imaging that authorities can view the data as well. The author-
ities can take action against illicit traffic activity, and fine traffic violations by looking at the
data [113]. This technology already exists, however, there is latency to such system. IBM
proposes that by integrating a blockchain with such system, the insurance company could
make real-time decisions related to pricing of their customer’s insurance. The way that a
blockchain would be integrated with such system would be to send the car sensor data in a
transaction. Different parties connected to the blockchain would, in turn, be able to see the
transaction and its data as soon as the transaction is confirmed and added to the blockchain.
45
IBM has also looked into possible uses of the IoT blockchain combination in the health-
care sector. By using blockchain in the healthcare data systems, data may be stored in a
distributed ledger securely, along with real-time trusted health data of the patients. Which
in turn can be accessed and used by insurance companies to easier release payments to
their customers. This could also be useful for the hospitalized person’s peers, and such
system would allow peers of the patient to be able to check in on them remotely [112].
Chain of things is a company that is also developing blockchain and IoT integration. One
of their case studies suggests that the blockchain may be a key component in securing IoT
assets. Chain of things proposes many applications of the blockchain in context of IoT se-
curity. One of them is similar to the firmware update service, already discussed. Another
possible usage that Chain of things suggests is using the blockchain for integrity checking
of messages in a network between IoT devices. If a device wants to send some kind of
data or a message to another device, it hashes this message or data and places the hash
onto a blockchain. The devices receive the message and hash it. For the device to check
the integrity of the message received, it can match the hash of the message with the hash
put onto blockchain by the sender. If the hash of the received message is the same as the
hash on the blockchain, the devices can be certain that the message has not been tampered
with [114].
Ali Dorri, Marco Steger, Sali S. Kanhere, and Raja Jurdak et al. [115] state the vehi-
cles are becoming increasingly connected, and especially to the internet, making cars part
of the IoT. However, they argue that security of these connected cars not be adequate at its
current state, giving examples of hackers gaining full control of vehicles core functionality
and steering remotely [115, p.1] [116]. The fact that hackers can exploit security vulnera-
bilities in cars to take control of them does not only make this a security issue but a safety
issue as well, putting drivers at higher risk. They propose to use a blockchain in order for
vehicles to communicate securely, along with the high grade of privacy due to public key
pairs associated with the cars, stored on a blockchain. Also, they state that the right imple-
mentation of the blockchain with IoT and cars is more scalable than today’s solution [115,
p.2]. Their proposal is similar to other security solutions for IoT discussed so far, however,
their proposal include safety of people, which show great trust in the blockchain and that
it may be applied to real life uses.
Another research team has shown that it is possible to combine the Ethereum blockchain
with physical devices. Also, they proved that it was possible to control these devices with
smart contracts on the Ethereum blockchain [117].
Summary of IoT and blockchain applications and possibilities

• Firmware authentication for IoT devices
• Device to device economy, giving things a bank account
• Slock.it connecting smart contracts to physical locks
• Supply chain management and security with Wabi
• Distributed power generation
46
• Healthcare, storing data distributed to giving patients peers a way to monitor their
loved ones easily
• Using blockchain to enable cars to communicate securely
4.6.1 Question 4.1: How is the blockchain used with IoT in a sharing
economy context?
I have already discussed different applications of the blockchain, along with various ap-
plications of IoT with blockchain technology. And touched upon the combination of the
sharing economy, IoT and Blockchain briefly with the New York-based, solar energy shar-
ing company solution. The model of solar panel selling excess electricity would not im-
mediately fit the goal of the thesis. However, the system could in later versions allow for
connection between devices and items without the need for human interaction.
Much closer is the decentralized sharing app by researchers Andreas Bogner, Matheiu
Chanson and Arne Meeuw et al. [7]. Their application is a web application, combined
with a smart contract on the Ethereum blockchain, which allows for decentralized payment
when lending and renting items to and from other users without a trusted third party. A
user can register an item for lending by making a QR code label, scanning it with the web
app and setting rental conditions. Afterward, the label is put on the item. When scanning
the QR code with the web application the second time, the option to rent the item with
the conditions set is shown, and the option to rent the item is displayed to the user in the
form of a ”Rent Object” button. To rent an object with the system, users are required
to have an Ethereum public address with sufficient amount of Ether on it to pay the de-
posit the item requires. A transaction with the deposit goes to the smart contract, and the
user is now renting the item. When the renter is done renting the item, the user presses a
”Stop renting” button. This activates another function of the smart contract. To calculate
the how much of the deposit the user will receive back, the time stamp from the activa-
tion of the contract is subtracted with the time stamp of when the smart contract receives
the stop renting action. This sum is sent back to the renter, and the rest is sent to the lender.
Slock.it is a German startup that focuses on making a free and open source infrastructure
for renting, selling and sharing items called the Universal Sharing Network (USN) [8].
Their idea springs out of a survey done by The Nielsen Company [118]. The survey states
that 66% of the world is willing to share their assets for financial gain, with the same figure
being as high as 94% in China [118, p. 4]. Slock stands for smart electronic lock and is
the combination of smart contracts and physical locks. If you have a device that carries
the right token, you can physically open the door with the Slock on it. Such token can
be bought on the Ethereum blockchain. A Slock can be placed on cars, on doors to real
estate, on lockers, or anything else that uses a lock. So let’s say a user wants to rent a
car or a house, he would buy a token or get a hold of one through a smart contract that
counts time use for instance. Then the user would use the token on the Slock to gain access
to the house or the car. Afterward price for the rental is calculated, and the user spends
his Ether [8]. It is the combination of the Slock and their USN that is their service. By
this Slock.it believe that there is an untapped opportunity in sharing un-utilized items and
47
[7, p. 177]
Figure 4.7: Figure of Andreas Bogner, Matheiu Chanson and Arne Meeuw’s decentralized appli-
cation with caption:”DAPP in use: The owner of the smart contract registers device by scanning a
barcode with a numerical id (left screen). After scanning the same barcode on a registered device,
the app displays the rental conditions to the interested renter (right screen).”
assets, and it is possible to do this with higher automation than today. The USN is con-
necting IoT devices with Ethereum smart contract access control mechanisms to mobile
phones. They want to apply the USN in many different industries and markets, including,
but not limited to: The Sharing Economy, Supply chain management, maritime contracts
and the shipping container industry, energy, and smart homes [119]. When it comes to
the implementation of the USN in the sharing economy, the idea is to put items behind a
”slock” (smart electronic lock), pay for it with Ethereum, and access the item. The slock
will open when you scan your phone onto it, and it sees that the transaction made on the
Ethereum blockchain was from your Ethereum account on your phone. They describe the
process of renting an item like this: you open their app, find the object, pay for the item
and then use it. When you have paid for the item, an IoT device on the item will unlock
the item, and then you can use it. When you put the item back, you pay for how long you
rented the item. An illustration of such scenario with a bicycle can be seen in figure 4.9.
48
[8]
Figure 4.8: The figure shows how many percents of people are willing to share their assets for
financial gain per continent.
4.6.2 Search process IoT and Blockchain, and IoT, blockchain and
sharing economy
To answer question 4 and to find information about blockchain and IoT implementations,
and use cases I searched with the string ”blockchain and iot” at Google.com. Limiting
ourselves to use only hits on the first page, the paper: ”Practical comparison of distributed
ledger technologies for IoT” [120] was found. The paper itself was not used further, but
it lead to the finding of the paper ”Blockchains and Smart Contracts for the Internet of
Things” [101]. This paper led to several other papers including:”Device democracy: Sav-
ing the future of the Internet of Things” [102], ”Own a Vizio Smart TV? Its Watching
You” [103], ”The USN” [8]. Also, this led us to find out about transactive grids [104],
but I found this citation from Google instead of the paper due to lack of information in
the cited ones. Information about the Wabi token was discovered while looking for infor-
mation about other cryptocurrencies on Coinmarketcap.com [28], and it matched question
4, so I decided to include it. The rest of the references was found by using the string
”blockchain IoT” in Oria on the first pages, ”automotive blockchain iot,” and ”blockchain
sharing economy” in Google.
49
[8]
Figure 4.9: How Slock.it picture bike rental through the USN
50
Chapter 5
Motivation and requirements for an
IoT based sharing app with
decentralized payment
5.1 Limitations of existing IoT-blockchain SEPs

In Andreas Bogner, Matheiu Chanson and Arne Meeuw’s project [7] the only way to deter-
mine what the renter owes the lender is by calculating how long the item was rented. Also
with Slock.it’s solution, it seems that time is the only way to determine what price a renter
should pay for renting an item. Slock.it is more focused on the lock feature. You pay to
have the item unlocked for some time, essentially paying for how much time you use the
item. After further investigation of Slock.its homepage and other resources like YouTube,
I cannot conclude otherwise. Using smart locks in an IoT sharing system is a brilliant idea,
however when the payment in the system solely rely upon unlocking the locks, and time
spent using the item, I believe the system comes a bit short related to accurate and fair
payment calculations.
I also believe that their system is not exploiting the blockchains full potential. I believe
that time spent renting an item does not accurately enough reflect the price the user has to
pay for using the item. I also believe that this is not fair to the lender of the item. I believe
there should be more ways than just time spent renting an item, to determine how much a
renter in this scenario would have to pay for the rented item. Like previously discussed,
the idea of using IoT for accurate pricing is already being done by insurance companies
related to the car insurance they provide their customers. Slock.it and Andreas B’s team
does not use the blockchain to send data about the condition and whereabouts of the item
in their platform. This further limit the possibility of selling data generated by usage of
the items.
51
Chapter 5. Motivation and requirements for an IoT based sharing app with decentralized
payment
Limitations listed:
• Time is used exclusively to calculate the cost of rent
• Underlying blockchain protocol is only used for payment and authentication
• No transfer or storing of data with blockchain technology
5.2 Motivation
I believe that utilizing the power IoT with the blockchain, would give an option for a more
diverse price calculation for renting and lending items. I want to determine the price by
equipping items with an IoT device. Also, with this IoT device on and connected to the
item, use the data it gathers to make a more accurate and fair price for both parties. Also
to start renting an item, you would scan the IoT device instead of the QR code.
Figure 4.7 in the right frame shows a user having the option to rent a power drill. Why
would we need to connect an IoT device to this item to determine the final price for renting
it? One reason is that a renter of the drill would not necessarily spend the entire time rent-
ing the drill actually drilling with it. This is unfair to the renter. A more fair price would
be if the renter paid a lower price for the time spent having the drill, along with paying
more for the electricity spent from the batteries of the drill, essentially paying for the ac-
tual usage of the drill. The reason for keeping time as a measure is to limit the renter of
the drill to let other people rent the drill as well. At this stage, we can determine the actual
usage of the drill. However, we are not able to determine how the drill is used. Users may
interact differently with the same item. Some people may handle the drill roughly, while
others may handle it delicately. An IoT device could measure this with impact sensors
and different movement sensors. The data from these sensors would also make an impact
on how much the renter would have to pay for renting the item. Let’s say the IoT device
detects an impact that would damage the drill, the IoT device would, in turn, charge the
renter more. On the other hand, if the IoT device detects that the item is handled delicately,
it will reward the renter by giving a lower price. There are many possibilities with IoT and
sharing of devices with data. Therefore I have made tables for a couple of items (including
the drill) to show what could be measured by IoT devices to determine the price for renting
items (table 5.1). Having an IoT device on a non-electrical item is possible; however, the
item’s IoT device would need frequent charging. The scenario is more viable when the IoT
device and its sensors have constant access to power, i.e., used with items with batteries or
other sources of power. These lists are just some examples of some classes of items that
could use IoT sensors to be rented out for an accurate price. The lists are not complete,
and there are possibilities of using different sensors for different items and usages. Some
items may also share the same sensors across classes, like for instance with an unmanned
aerial vehicle or drone. A drone would be an electronic device, but should share many of
the same sensors as vehicles to determine an accurate price.
Another possibility not discovered by these two actors is the possibility of utilizing the
52
5.2 Motivation
Types
1. Hand held tools - Drill, chainsaw, concrete breaker, lawnmower, and similar
• Time
• Consumed power from battery
• Accelerometer
• Impact sensor
• And more..
2. Vehicles - Cars, motorbikes, bicycles, excavators, and similar
• Time
• Distance
• Gas consumption
• Impact sensor
Including a driving monitor like Autologger [113] which include data about how the driver is:
• ..accelerating the car
• ..braking and the braking distance
• ..driving in different weather conditions
• ..turning - driver turning to hard is at higher risk
• ..and more
3. Electronic devices - Computers, gaming systems, cell phones, and similar
• Time
• Consumed power and/or consumed power from battery
• Accelerometer
• Impact sensor
• And more..
Table 5.1: Possible sensor data measurements for different items
53
payment
blockchain more in their implementations, specifically related to using the blockchain to

send and receive data in real-time(section 4.6). By utilizing this feature of the blockchain
in a SEP would allow for continuous monitoring of the items whereabouts, condition and
more. This would be useful for the users lending items in such system. Also, data gathered
about user behavior could be useful for all the actors lending and renting items across the
SEP. This data could be useful for the lenders to put a price for renting their items more
accurately. This data would accumulate over time, thus making the accuracy of renting
prices better over time, benefiting both lender and renter. This data would essentially be
used to put weights on the different data types that participate to calculate the price for
renting an item. These weights would get better with more data. This data could also be
useful for the manufactures of the items rented in the system. A manufacturer could use
the data to improve their products based on the user data. Let us say that the data on the
blockchain show that people who rent drills, frequently drop them. This data could be sold
to or given to the manufacturer of the drill. In turn, the manufacturer could use the data
to improve their drills where needed, resulting in a more sturdy drill. Such use case for
the data may apply to all items rented and lent in an SEP enabling data gathering on the
blockchain. It is likely that this possibility is not discovered by the two, due to limitations
of the Ethereum blockchain, especially regarding transaction speeds.
5.3 Research questions

What I want to do is to use data from IoT devices to determine an accurate price when
renting and lending items in a SEP. Additionally, I want payment in the system to be de-
centralized by having users pay with cryptocurrency. Like previously discussed in section
4.6, researchers believe that the blockchain or similar may give the possibility of efficient
real-time systems. Moreover, I believe that this should be a feature of this SEP. Because it
will provide real-time information to owners of items. In addition, this data may be sold
and used later by other third parties.
Summarized:
• Use data from IoT devices to determine an accurate and fair price when renting and
lending items in a SEP
• Payment in the system shall be decentralized by having users pay with cryptocur-
rency
• Enable real-time monitoring of items through a blockchain
• Enable selling of data generated by items, stored on a blockchain to third parties
This result in the following research questions:
In a sharing economy platform for item sharing:
54
5.3 Research questions
Research question 4: How can data be stored on a blockchain to provide manufactur-

ers of items information about how their items are being used?
5.3.1 Machine-to-machine economy

Predictions of how IoT devices will interact with each other in the future suggest a ma-
chine to machine economy. Machines that do services for people, people doing services
for machines, and machines doing services for other machines. The machine-to-machine
economy may take part in the different aspects of the sharing economy in the future. This
includes all the different models within sharing economy such as Business-to-business
(B2B), Business-to-consumer (B2C) and Consumer-to-consumer (C2C). It may also be
likely that the machine-to-machine economy can co-exist with these models, without ac-
tually taking part in any of them. This would mean we would have machines existing
strictly on their own, with no owner, with their only motivation being to exist. A machine-
to-machine economy is described as machines interacting with other machines exchanging
assets between them to fulfill their purpose. Essentially, the machine-to-machine economy
might open for many new and undiscovered business models. my assumption is that you
can have machine as its own class in the economy (Table 5.2), and/or you can add ”ma-
chine” to all the different classes of sharing economy (Table 5.3).
Business Consumer Machine

Business B2B economy B2C economy B2M economy
Consumer C2B economy C2C economy C2M economy
Machine M2B economy M2C economy M2M economy
Table 5.2: Machine as its own class in the economy
Business machine (BM) Consumer machine (CM)

Business machine (BM) BM-to-BM economy BM-to-CM economy
Consumer machine (CM) CM-to-BM economy CM-to-CM economy
Table 5.3: Machine as a supplement to the sharing economy
An example could be an automated taxi service. The car is self-driven and drives
55
payment
around picking up customers, the sensors of the car measure every aspect of the car. Sud-
denly low tire pressure is measured, the car places an order in an open marketplace for car
services. The service provider with the lowest cost comes to aid the car with an automated
drone. The drone fixes the cars tier, and charge the car for this service, and the drone
flies off to assist other cars or other vehicles. When the drone needs new parts for fixing
other vehicles, it can fly to another machine to purchase the parts it needs. Alternatively,
when the drone needs to recharge or replace its own parts, this can again be purchased
from other machines. In this system, the machines would charge people for the data they
generate while using this vehicle.
This is a future vision, and I believe that it will take several years to reach this kind of
automation. However, a system enabling people to interact with items through their phone
could be tweaked into letting machines interact with or other machines, essentially allow-
ing for a machine to machine interactions. It is likely that machines would exchange some
kind of information between them to interact with each other. This could be done through
a system as I propose. However, these things would also need to pay each other for their
services. This is where the blockchain comes in. The blockchain is interesting in many
different aspects, many of which I have already shed light upon in this thesis, however
one of the most interesting features related to the sharing economy and IoT, is that the
blockchain could allow everyone and everything to have a ”bank” account. And when
everything can have a bank account, then everything can pay other things, i.e., machine-
to-machine economy. The system I want to make is a Sharing economy platform (SEP).
A SEP where users of the system can rent items from each other, with blockchain as a
base for data distribution and payment. So I believe that the system I am presenting in
this thesis could be applied in a machine-to-machine scenario in the future. This is not my
main motivation.
5.4 Empirical study of research questions

I did a survey to elaborate my research questions. The participants of the survey were
students aging from 18-30, mostly studying computer science or mathematics. There were
24 participants in the survey. The participants were first presented with a description of
the system, along with an example of a person lending a drill, and a company buying data
generated from the drill. After the description, participants were presented with four open
questions regarding the system, i.e., this thesis’s research questions.
These are the questions the participant were presented with:
• Q1: What do you think about the systems way of using data to calculate renting
prices?
• Q2: What do you think about the systems way of making users use cryptocurrency
to pay each other?
• Q3: What do you think about the systems way of giving lenders real-time informa-
tion about their items when they are rented?
56
5.4 Empirical study of research questions
• Q4: What do you think about the possibility the system gives the lenders in regards
to making extra income from selling data generated by their items to third parties?
By having open questions I could get an explanation of what the participant like or disliked
about the research questions. When processing the data from the survey, I first read through
all of the answers to make categories for the answers. This resulted in five categories:
The participant is positive to the question, the participant is negative to the question, the
participant is positive to the question and concerned regarding users privacy, the participant
is negative and concerned regarding users privacy, and the participant was neither positive
or negative, to the question. GDPR was mentioned several times in the data set; therefore
I needed the categories regarding privacy. Also, some participants were unsure of what
to answer to some of the questions; therefore I added the ”unsure” category. In order to
classify the answers, I read through each of the answers once more and marked the answers
with one of the categories. The data is available online [121].
5.4.1 Results question 1

The answers regarding question one were mostly positive, with 66,7% being in the pure
positive category. 16% of the answers were positive, with concerns regarding GDPR.
Making 77% of the answers to this question positive. 8,3% were of the answers were
negative with concerns regarding GDPR. No one answer in the pure negative category.
And 8.2% were unsure. All of the negative answers were negative due to privacy concerns.
In regards to the positive answers, most of these stated that including data would make the
system trustworthy. Some of the positive answers were critical to privacy and were positive
to the question as long as privacy for the users is taken into account.

The answers regarding question two were mostly negative. 45,8% of the answers were
negative. Participants did not like that the system solely relayed on paying with cryptocur-
rency. Moreover, many stated that volatility of value and adoption of cryptocurrencies
are problematic for them. Therefore many answers were labeled negative. 33,3% were
positive to the question and thought it was innovative. And 20,8% were unsure. The ”un-
sure” answers stated that they lack insight into how cryptocurrencies work to answer the
questions.

In regards to question three, 37,5% were positive, 37,5% were positive but with concerns
regarding privacy. Making 75% of participants positive to question three. The solely
positive stated that this surveillance of items could make lenders feel safer renting their
items. For the positive answers concerned about privacy stated the same as the sole positive
once, however, they also stated that this is a good idea as long as the system is compliant
with GDPR and other privacy standards. All the answers identified as negative were due to
57
payment
privacy concerns and stood for 20,8% of the answers. They answered that the amount of
surveillance in the system would make them uncomfortable using it. 4,2% answered that
they were uncertain or not interested, therefore their answers were classified as unsure.

For the last question, 54,2% very solely positive to the question. 29,2% answered posi-
tively but, with privacy concerns. Making 83,4% answers identified as positive in regards
to the question. The positive answers along with the positive and privacy-related answers
both thought the idea of selling data from items were great, but the privacy-related answers
stated that the system should be compliant with GDPR or other privacy laws in order for
them to use the system. 8,3% answered negatively, stating that a lender would not be able
to gather enough data from its items in order to make any significant profit. 4,2% answered
negatively due to privacy concerns, stating that it would be difficult to make such system
in regards to compliance towards privacy laws and regulations. Lastly, 4,2% answers were
identified as unsure.
5.4.5 Notes from participants

Privacy is noted as a potential issue in answers to all questions, except for question 2.
Privacy is important, however not in regards to my research questions. If I were to release
a system based on the prototype made in this thesis, I would have to take privacy into
account. Privacy was not a deal breaker for using the system, as long as privacy was taken
into account, and users were properly informed about what is going to happen with the
data they generated. However, this was not the case for the negative answers regarding
privacy. These would not use the system at all, because they found it creepy that someone
could monitor them. Few participants were happy with the fact that the system is using
cryptocurrency in order to pay each other. It is likely due to the description of the sys-
tem before the questions not giving a full explanation of how the system is reliant on a
blockchain. Many participants saw problems with converting cryptocurrency to fiat cur-
rencies, and that such process could become a hassle for the users of the system. Some
users also explained that they did not fully understand cryptocurrencies, and were there-
fore not positive about it. Answers regarding question 3 were mostly positive, however
privacy was again pointed out to be a problem, for the most negative answers privacy was
a deal breaker for them. The positive answers liked the idea of real-time monitoring, as
long as it is compliant with privacy laws and regulations. The positive answers stated that
this is a very nice feature for the lender, making it feel safe to lend items in the system. In
regards to question 4 the solely negative answers were stating that the extra income made
from selling that would likely not be of any substantial amount. The rest of the negative
answers were in once more in regards to privacy. The positive answers stated that this was
a nice feature, as long as the users in the data was made anonymous before selling it.
58
Chapter 6
High level architecture and design
6.1 System concept description

The concept for the thesis is a sharing economy platform with the goal of allowing people
to rent and lend items from each other easily. This is how the system will be: First, you
need to register yourself as a user in the system’s app. After registration, you will be able
to register items for rent, and rent items. To register an item for rent, you need to install
an IoT device on the item. This IoT device will have sensors on it, and these sensors will
determine what a renter pays for renting your item. This is done by using data generated
by the sensors during the period of time a renter rents the item. To rent an item, you locate
the item in the system’s app. Then you connect to the item by placing your phone on the
items scanning surface. The item check if you have a sufficient amount of funds in your
cryptocurrency wallet. If you have you have sufficient balance, you may start to use the
item. The IoT device on the item you rent is communicating with the owner of the item
through the renter’s phone, letting the owner know the whereabouts of the item along with
how the renter is handling the item, based on the data from the IoT devices sensors. The
renter pays for renting the item based on the data from the IoT device’s sensors. This is
the baseline for the system.
6.2 Business model

The prototype is in a grey area between access based business model and Marketplace.
Access based because a user may be a renter as well as a lender. However, the rest the
of the prototype is based on the Marketplace model. The matching of supply and demand
of tools, items, vehicles, and data is the main service of the prototype, making the proto-
type more of a marketplace type of SEP. The platform also offers some services as well,
like monitoring of items, as well as the possibility to purchase data. In the long run, the
prototype may become a community marketplace to keep its customers on the platform.
However, will start out as a pure marketplace based platform. The prototype will generate
59
Chapter 6. High level architecture and design
income by deducting a small fee from every transaction made in the system. Also, the
platform may sell the IoT devices to put on the items.
6.3 IoT components in system

Every item used in the system must have an IoT device on its body. The IoT device should
consist of several sensors measuring different aspects of the items condition. The IoT
device does not necessarily need to be embedded into the device, but it must be attached
to the item. All the sensors would need an MCU or an MPU as to send the data forward,
and act as a sink between the sensors connected to it. All items would not need all of the
same sensors (as discussed in my motivation 5.1), but some would be common to all items,
for instance, RFID and GPS sensors. This is a list of baseline sensors and IoT technology
that would generate data for a precise price calculation, as well as giving the renter the
information it needs to keep track of its items properly. The data from these sensors could
also be useful for third parties. However, these are only suggestions, due to that different
objects could require different sensors.
• RFID tag
• GPS tracker
• Accelerometer
• Impact sensor
• Gyro sensor
• Water detector
RFID is important to many IoT based systems, including my system. RFID would give an
item an id, and make it possible to read this id from the RFID tag. An RFID tag would
give the interface in order to connect the physical device to the renters and the lenders of
the system. An RFID tag would also be able to do some sensing, data based on the sensing
could be included in the calculation of price, along with information to lenders and third
parties. The GPS tracker would give information about the whereabouts of the item to the
renter, and if put on vehicles calculate how far items have traveled. The accelerometer
would give information about sudden movements and combined with a gyro sensor could
give insight into how renters are using the device. The impact sensor would give the renter
an insight in how harshly the item is rented.
6.4 System actors and roles

The system consists of five system actors. These actors are:
• Items
60
• Owner of items (lenders)
• Third parties
• Renters
• Blockchain
These actors have different roles:
• The items role is to be rented, generated data, and transmit data to a renter.
• The renter’s role is to rent items, relay data from the item, and pay the item owners.
• The lenders’ role is to lend items, keep track of their items condition and where-
abouts, receive payments from renters and sell the data their items generate to third
parties.
• Third parties role is to make offers for the lenders’ items data and purchase this data.
• The blockchains role is to calculate the price for renting items and charge the renter
accordingly, relay payments from renter to lender and store data generated by items.
6.4.1 System design

Figure 6.1 shows how the different actors in the system relate to each other. In order to
understand how to system work, we need to understand this figure.
(1)
This is the relation between the lender and its items. The lender owns the item and puts it
up for rent.
(2)
This is the relation between the third parties in the system and the lenders in the system.
The third party pays the lenders to access the data generated from the items they rent.
(3)
This is the relation between the item, the renter, and the items indirect relation to the
blockchain in the system. The renter scans the items sensors, and the item then sends
a signal to the phone activating a smart contract, which starts the process of billing the
renter’s account. The item sends data to the owner’s phone, and the owner’s phone con-
veys this information forward to the blockchain, along with payment for renting the item.
The lender specifies the frequency of this action. The relation between item, renter and
blockchain are further described in figure 6.2.
61
Figure 6.1: How the different actors in the system are related to each other
(4)
The relation the lender has with the blockchain is divided into two. First, the lender re-
ceives payments made by renters. Secondly, the lender can access the data generated by
its items. This data is transferred along with transactions made from the item, through the
renter’s phone, originally meant for calculation of the price the renter is paying for using
the item. However, this data is also useful for the lender. This data lets the lender know
the location of the item, condition, and events that have occurred with it (as long as there
are sensors on the item measuring this).
(5)
After a third party has paid a lender to access the data generated by the lenders’ items, the
third party get information about the which transactions items has made on the blockchain.
The third party can then identify an items transaction, and read the data encapsulated inside
each transaction off the blockchain. The third party may further use this data in order make
improvements to their products or other usages for the data.
(6)
The renters’ relation to the blockchain is conveying data from the item in transactions
including payments to a smart contract on the blockchain.
62
Figure 6.2: Figure show how a user would rent an object
63
6.5 System features and use cases

6.5.1 System features
• Users shall be able to track their items when they are rented
• Users shall be able to sell the data their items generated while being rented
• Payment and billing in the system shall be decentralized with the help of a cryp-
tocurrency
• Each item shall have at least one IoT devices attached to it
• Third parties hall be able to buy data generated by items
• Data shall be anonymized before sold to third parties
• System shall use data from IoT devices to calculate the cost of usage of an item
• System shall use a blockchain or a blockchain alike technology
6.6 Use cases

The use cases are limited because I am only making a prototype, the use cases will be
limited to what’s the minimal viable product of the project. The minimal viable products
use cases consist of putting an item up for rent and renting an item that is put up for rent
with automatic payment. I will use Alistair Cockburn’s Casual use cases with additions to
describe the use cases for my prototype [122]. The most important use cases are: Putting
an item up for rent, renting an item, paying for renting an item, show status of a rented
item, and purchase data from users items.
6.6.1 Use case 1: Put an item up for rent

Primary Actor: A lender with an Ethereum address
Scope: Lender and App
Preconditions: IoT device on the item
Brief: A lender is putting an item up for rent
Basic flow:
1. User open mobile phone application
2. Scans IoT device
3. Inputs information about item
4. Information is sent to a smart contract, and the item is now able to be rented
64
6.6 Use cases
6.6.2 Use case 2: Rent an item

Primary Actor: An actor with an Ethereum address
Scope: Actor and App
Preconditions: Ethereum light client on phone, IoT device on item and smart contract
deployed on Ethereum blockchain
Brief: An actor is renting an item
Basic flow:
2. Locate whereabouts of the item
3. Receive item from a lender
4. Scans item’s IoT device with phone and pays a deposit to the smart contract auto-
matically
5. Using the item
6. Delivers the item back to the lender
7. Lender sends stop signal to smart contract
6.6.3 Use case 3: Charging a renter

Primary Actor: Smart contract, IoT device on an item, and a renter’s phone
Scope: System and phone
Preconditions: Ethereum light client on the phone, IoT device on item and smart contract
deployed on Ethereum blockchain
Brief: An item sends data to a renter’s phone, renter’s phone sends data to smart contract,
smart contract deducts an amount from the renter’s deposit based on the data received.
This process continues as long as the deposit is sufficient
Basic flow:
1. Within a time interval, the IoT device on the item sends data to renter’s phone
2. The renter’s phone relays the data to the smart contract
3. Smart contract calculate how much the renter needs to pay in relation to the data
received
4. The smart contract deducts an amount of the deposit on in the smart contract and
sends it to the owner of the item
65
6.6.4 Use case 4: Show status of a rented item

Primary Actor: Owner of a rented item
Scope: App and smart contract
Preconditions: Ethereum light client on phone, an item is rented
Brief: A owner of an item checks the condition and whereabouts of its item
Basic flow:

2. The user navigates to the page for the rented item
3. System reads the data of the last transaction from the item
4. This information renders a map of the whereabouts of the item, along with ”last
events” of the item
6.6.5 Use case 5: Buy data about an item

Primary Actor: A third party wanting to buy data related to specific items
Scope: App and smart contract
Preconditions: Items have been rented
Brief: A third party of the systems purchase data generated by items when they were
rented
Basic flow:
1. Third party access application

2. Third party navigates to the third-party section
3. Third party uses the search field in order to look up an item it is interested in
4. Results show different items, and how much data is stored
5. Third party pays for the data and can read data of all transactions regarding the item
66
Chapter 7
Detailed design and implementation
7.1 System Inspiration

I decided on building a system based on Andreas Bogner, Matheiu Chanson and Arne
Meeuw’s [7] system. Due to similarities with my project, some of my code is inspired by
their code. I also used the Truffle development framework [123], along with the library
web3.js [124]. Truffle is a framework for binding JavaScript to smart contract code. More-
over, the web3.js library allows for interaction with a local or external Ethereum node. The
combination of the two allows for writing JavaScript code that interacts with code from
smart contracts on the Ethereum blockchain. I used Ganache in order to test my system
with a blockchain, without having to spend real Ether. Ganache is a part of Truffle. My
smart contract is written in the Ethereum’s smart contract language, Solidity. Also, I based
my user interface on a template from HTML5 UP [125], along with JQuery. Moreover,
the prototype use node package manager to install and run my code, along with managing
dependencies.
In summary:
• Code is inspired by Andreas Bogner, Matheiu Chanson and Arne Meeuw’s work [7]
• System is using Truffle development framework for binding JavaScript and Solidity
• System is using web3.js to interact with Ethereum nodes
• System is using node package manager for dependencies, installing and running my
code
• System is using Ganache for testing and simulation
• Systems user interface’s HTML is based on a template [125] and used with JQuery
67
Chapter 7. Detailed design and implementation
7.1.1 Smart contracts
A smart contract is code place on a blockchain, in our case on the Ethereum blockchain.
To put a smart contract onto the Ethereum blockchain, you have to make a transaction
with no recipient, which contains the code you want to place on the blockchain. To run
the code, you must send an amount of ether to the contract. When paying for transactions
or paying for having your smart contracts ran, is called paying Gas. The amount of gas
you pay is a fee you have to pay for your smart contract or transaction to be either ran or
confirmed. The Gas price fluctuate based on the supply and demand for code execution or
transaction confirmations, meaning that if there are many actors sending transactions, or
in need of executing their smart contracts, the price of gas will rise. The Gas price will be
lower in the opposite scenario. This means that usually, you will not pay the same amount
for running a smart contract or getting your transactions confirmed every time. The Gas
you pay goes to the miners in the Ethereum network because they are the one confirming
transactions and running the smart contracts. A user have to send an amount of Ether to its
smart contract’s address for the Ethereum network to run it. It cost Gas to run, and write
to the Ethereum blockchain, however reading data from the blockchain is free.
7.1.2 How the smart contract is used in the prototype
The smart contract in the system’s purpose is to handle all logic users, payments, and data.
A user only needs an Ethereum address to use the smart contract. A user must register
the item in the user interface, information regarding the item is sent to the smart contract.
The item is now registered and is ready to be rented. I have not built an IoT device with
the system, for now, a renter has to know about the id of the object to rent it. When the
user accesses the items Id in the user interface, the renter press the rent item button. The
renter then pays a deposit to the smart contract, and the renting process begins. The smart
contract receives data from the item through the renter’s phone, and calculates the cost in
regards to different data and time spent, and deducts this from the deposit. This process
stops when the renter delivers the item back, and the lender presses the stop renting button
for the items id in the user interface. When this button is pressed, the smart contract stops
charging the renter.
The data generated by the users of the system is stored on the blockchain. This data may
be valuable to third parties. Third parties may be manufactures of the items rented and lent
in the system. The data these item generate while being rented may give a manufacturer
valuable insight in how their products are used. Item generated data is therefore for sale
in the prototype. Making a third party able to purchase the generated in the system from
lenders in the system.
68
7.2 System implantation user interface
Figure 7.1: Figure showing the architecture of the prototype. All interactions with the system
included the use the smart contract’s function. Third parties read data off the blockchain, without
the need for the smart contract
7.2 System implantation user interface

This section shows different screenshots of my prototype. Most of them are related to the
use cases in section 6.6. This section mentions the different functions that is activated in
the user interface. These functions are describe in section 7.3.
7.2.1 Registering and putting an up for rent

Figure 7.2 shows a screenshot of the prototype’s user interface. The screenshot is showing
a lender who is putting an item up for rent after the items id have been registered by the
”Register object” button. The lender can set the description of the item, along with the
deposit needed to rent the item. Also, the lender sets the weights that are going to be
multiplied with the data that is sent from the item while is is being rented. Different items
would have different weights. Moreover, it is likely that in a real scenario these weights
would be calculated and set based on data made up of earlier use of the same type of item.
Finding accurate weights for the different item is out of scope for this thesis. After this
data set, the lender presses the ”registerObject” button, this activates the ”registerObject”
function in the smart contract, and the item gets put available for renting.
69
Figure 7.2: Screenshot of the prototype showing registration of an item
70
7.3 Smart contract implementation and code: Data structures and functions
7.2.2 Renting an object

Figure 7.3 shows a screenshot of the prototypes user interface. The screenshot shows a
user who have found an item it wants to rent. The user presses the ”Rent Object” button in
order to rent the item. Figure 7.4 shows a screenshot of the prototypes user interface. The
screenshot shows how the user interface look like after the user has rented the item. The
user is given the possibility to send data. In a fully functional prototype with an IoT device
attached to the items, the sending of data would be done in the background of the software.
And these fields would be removed. I have implemented the possibility to send data from
the user interface because I have not developed an IoT device for this thesis. Pressing the
”Send data” button actives the ”payData” function in the JavaScript code, which furthers
uses the ”payData” function in the smart contract. This data is sent in a transaction and is
later retrievable by the lender, and possible third parties.
7.2.3 Show status of Object

Figure 7.5 shows a screenshot of the prototype’s user interface. The screenshot shows the
information an owner of an item would view, while its item is being rented. Because I do
not use real data, the map and the event log shows how I would picture, the formatting of
the data sent from the user’s item, read off the blockchain, would look like. The lender
can press the ”Take back object” button when the lender has received the item back. An
alternative to this could be to use the technology made by Slock.it [8]. A renter instead of
giving it back to the lender put in a cabinet with a slock on it. When renter had put the
item back, locked the slock, the function of the ”Take back object” button could be called
by the slock.
7.2.4 Buy data

Figure 7.6 shows a screenshot of the prototype’s user interface. The screenshot shows how
a third party could purchase data from items. I have not implemented this in the prototype
because I did not use real data. However, this could be done by storing transaction ids in
the ”Object” struct. Another possibility is for the owner of the data, the lender, to give his
Ethereum address to the third party. From there, the third party could access the data of
the transactions sent to the lender, from the blockchain. A search would be done on the id
of the object in the transactions, finding the data sent from the item. Although this is not
an optimal solution, this is possible with the current implementation of the prototype.
7.3 Smart contract implementation and code: Data struc-

tures and functions
Due to my prototype’s smart contract revolves around the concept of renting items, An-
dreas Bogner, Matheiu Chanson and Arne Meeuw’s [7] smart contract contains many use-
ful functions and structs, specifically the structs Client and Object, and functions regarding
them. Therefore I decided to reuse some of their functions, or making changes to them to
fit my prototype.
71
This is code from the smart contract:

The structs:
struct Client {
address cliAddress;
uint since;
bool exists;
}
And
struct Object {
uint objId;
string description;
uint deposit;
Client client;
uint created;
address owner;
bool exists;
In order to use data for payment in the system I added the arrays ”dataWeights”, data”, the
variable ”lastPaid”, and the variable depositReset to the Object-struct looking like this:
struct Object {
uint objId;
string description;
uint deposit;
Client client;
uint created;
address owner;
bool exists;
uint[] dataWeights;
uint[] data;
uint lastPaid;
uint depositReset;
72
Figure 7.3: Screenshot of the prototype showing a renter who are about to rent an item
73
Figure 7.4: Screenshot of the prototype showing the view for the renter after it has started renting
the item
74
Figure 7.5: Screenshot of the prototype showing information about a rented item
75
Figure 7.6: Screenshot of the prototype showing an interface a third party would access in order to
purchase data
76
Variable type Variable name Usage
uint objId This is the Id of the object
string description Description of the object
uint deposit Holds the current deposit of a user while the item is rented
Client client Which client is currently in possession of the item
uint created What time the item was registered
address owner Address of the client owning the item
Checks if the items exist, and
bool exists
to check if the item is rentable or not
An array containing weights that will be multiplied with data received
uint dataWeights
from the items sensors
uint data An array containing the data generated by an item
uint lastPaid A variable that shows previous amount of ether from the renter
Holds the original value of the deposit set by the renter, used
uint depositReset
to reset the deposit variable after the item has been used
Table 7.1: Explain variables in the the struct ”Object” that represent an item
77
78

Function name Usage Return type
getObjectDeposit(uint objId) Gets the deposit payed by the renter from the object uint
getObjectDescription(uint objId) Gets the description of the object string
Gets the address of the objects ”owner.”
getObjectClientAddress(uint objId) address
(A renter is set as the owner of an object while renting it)
getObjectOwnerAddress(uint objId) Gets the address of the user that registered the item address
Checks if an object is still registered
objectIsRegistered(uint objId) bool
(an object may be unregistered, and therefore not rentable).
objectIsRented(uint objId) Checks if an object is being rented bool
Table 7.2: Shows get functions I reused or edited
Function name Usage Return type

getObjectDataWeights(uint objId)} Gets the weights that are going to be multiplied with the data uint[]
getObjectData(uint objId) Gets the data generated by the object uint[]
dataWeightsLength(uint objId) Gets the length of the dataWeights array uint
getDataLength(uint objId) Gets the length of the data array uint
getLastPaid(uint objId) Gets the lastPaid variable uint
registerObject(uint objId, string descr,
Registering an object bool
uint deposit, uint[] dataWeights, uint[] data)
Table 7.3: Shows get functions that I added and the edited function ”registerObject”
7.3.1 The ”dataWeight” array

The ”dataWeight” array contains numbers that are going to be multiplied with the data that
is received from lenders items. In figure 7.3, we can see the user interface of the prototype.
And in the user interface we describe data weights for four types of data. These types are:
Time, GPS location, Acceleration and Impact, of the item. The weights set are multiplied
with each type of data, added together, and sent as payment to the lender of the item. Let’s
say the renter of an item managed to drop it. When the next calculation and payment
would happen, the smart contract would receive the impact data, and as an example let’s
say that this data was 0.13. 0.13 is then multiplied with the data weight corresponding to
the impact data type. Let’s say the wight for impact data is 1 Ether. A user would have to
pay 0.13 Ether (1 x 0.13) for the impact data they generated. Another example could be
the calculation of time. Let’s say the renter pay for data on a minutely basis. This would
get us the calculation of 0.0167 x 1 Ether (1/60 minutes = 0.0167), making the user pay
0.0167 Ether for the time data. Another example could be an item that would get wear and
tear from traveling. The GPS data would show the difference in location, and would be
multiplied with its data weight. How much Ether the lender of the items receives is based
on the multiplication of the data and the data weights, added together. These types of
data are used as an example in the prototype. Which data is used, depends on the sensors
applied to the item, and this is decided by the lender. Other items could have other sensors,
which in turn would have other data weights. The calculation is done by the ”payData”
function and is further explained in section 7.3.2
7.3.2 Important functions

The functions and code in the previous sections are mainly support functions. This section
describes the code that it is at the prototype’s core. There three are functions in total that
is essential to the prototype. These are the functions:
• rentObject(uint objId)(edited)
• reclaimObject(uint objId)(edited)
• payData(uint objId, uint[] data)
Important to notice is that I have not made an IoT device for this thesis. Therefore regis-
tration of items, renting of items, and sending of data is done in the user interface.
Function 1: rentObject(uint objId)

This function is activated after a user has selected the object it wants to rent and presses
the ”Rent object” button in the user interface. When the button is pressed, it activates the
”rentObject” function in the smart contract and sends the id of the object. The function
checks if the item is available, if the object is not already rented, and if the deposit sent to
the smart contract is sufficient. If at least one these cases are true, the deposit is returned,
and renting of the item will not commence. Else, the object becomes assigned to the renter,
and the deposit is stored in the ”Object” struct, and the function returns the value ”true”
79
to the user interface. This function enables the use of the functions: ”reclaimObject,” and
”payData.”
function rentObject(uint _objId) payable returns (bool) {

if ( !(objectIsRegistered(_objId)) || objectIsRented(_objId)
|| msg.value < objects[_objId].deposit) {
revert();
}
// add client to object
objects[_objId].client = Client({cliAddress: msg.sender,
since: now, exists: true});
//sends back any excess ether
if ( !objects[_objId].client.cliAddress.send(
msg.value - objects[_objId].deposit) ) {
revert();
}
return true;
}
Function 2: reclaimObject(uint objId)
This function is made available for the lender once one of the lender’s items becomes
rented. This function is used when the lender of the item receives the item back from
the renter of the item. More specifically when the lender presses the ”Take back object”
button. This activates the function on the smart contract. First, the function asserts that the
object is rented and that the activator of the function is, in fact, the owner of the object.
Next, the function sends back the rest of the deposit to the renter. Next, it sets the deposit
back to original state with the help of the original deposit. This is because the deposit
gets lowered during the time it is rented, and it is calculated with the ”deposit” variable in
the object. And lastly, the function sets the object as rentable again and returns the value
”true” to the user interface.
function reclaimObject(uint _objId) returns (bool) {

assert ( objectIsRented(_objId) && objects[_objId].owner
== msg.sender );
if ( !objects[_objId].client.cliAddress.send
(objects[_objId].deposit) ) {
revert();
}
objects[_objId].deposit = objects[_objId].depositReset;
objects[_objId].client = Client({cliAddress: 0, since:
now, exFdataists: false} );
return true;
}
80
Function 3: payData(uint objId, uint[] data)
In order to calculate a price with the data, the system would have weights for the different
data. The sensor would add data of the same type together over a set time period, and then
data would be done calculations on. I picture a calculation like this:
Data A x weight for data type A + Data B x weight for data type B...etc.
The different data should make a different impact on the price the renter pay. Time spent
using an item would always be taken into consideration when using an item, and would
be simple to calculate, and would have a low weight. However, a weight for impact data
should be high for fragile items and lower for more sturdy items. If data from the impact
sensor suggest that the item is broken, the renter would likely lose its entire deposit. This
could be similar to the water detector. This is what the function ”payData” do.
This is the most important function of the prototype and the thesis. This function en-
ables the object that is rented to charge the user based on the data it sends to the user’s
phone, and further to the smart contract. This function is activated on a timely basis de-
cided by the owner of the item. The function receives the id of the object, along with the
data it has generated in a transaction to the smart contract. Then the function iterates over
the data wights, multiplying and adding each data weight with the data of the correspond-
ing type. This is stored in the variable ”dataPrice,” that holds the amount the renter has to
pay the data received from the object that is being rented. Then the renter sends an amount
of Ether equal to the ”dataPrice” variable to the owner of the item, and the data price is
deducted from the deposit of the object. This function along with the data structures re-
garding the data is what makes the pay-by-data functionality possible In the prototype, I
assume that the data is sent in the same order as the data weights are structured in the
”dataWeights” array.
function payData(uint _objId, uint[] data) returns (bool) {

uint[] memory _dataWeights = getObjectDataWeights(_objId);
uint[] memory _data = data;
uint dataPrice = 0;
for(uint i = 0; i < getDataWeightsLength(_objId); i++){
dataPrice += _dataWeights[i]*_data[i];
}
objects[_objId].lastPaid = dataPrice;
if ( !objects[_objId].owner.send(dataPrice) ) {
revert();
}
objects[_objId].deposit = objects[_objId].deposit - dataPrice;
return true;
}
81
7.3.3 web3.js
I made and reused JavaScript functions as well, however the interesting functions are in the
smart contract. I decided to include some JavaScript code to show how to call functions
in the smart contract. Here is an example of JavaScript code that calls the smart con-
tract function ”payData.” For readability, and following the conventions of reused code,
I named my JavaScript functions the same as the smart contract functions. This function
gets the user input data from the user interface with Jquery and sends an array of data as
an argument to the ”payData” function, the account that activated the contract’s function
along with the gas required to process the function in the deployed smart contract.
function payData() {
var rentable = RentableObjects.deployed();
var dataWeightsTime =
parseInt(document.getElementById("_dataTime").value);
var dataWeightsGps =
parseInt(document.getElementById("_dataGps").value);
var dataWeightsAccel =
parseInt(document.getElementById("_dataAccel").value);
var dataWeightsImpact =
parseInt(document.getElementById("_dataImpact").value);
var data = new Array(dataWeightsTime, dataWeightsGps,
dataWeightsAccel, dataWeightsImpact);
rentable.then(function (instance) {
return instance.payData(objectId, data, {
from: account,
gas: 1000000
}).then(function (success) {
if (success) {
setStatus("Object paid data");
}
else {
setStatus("object did not pay");
}
switchPageView();
})
}).catch(function (e) {
console.log(e);
setStatus("Error paying object; see log.");
});
}
82
Chapter 8
Evaluation and discussion
8.1 User-testing
To get feedback on my prototype, I conducted a user-test of the prototype. The user-test
was inspired by methodology from the book ”Researching information systems and com-
puting” [126]. The users tried each role of the prototype, as a renter, as a lender, and as
a third party. After each role was tested, the participants were interviewed with the goal
of understanding how they liked the prototype, uncover problem areas of the prototype
and get suggestions on how to improve the prototype. Three user-tests were held. I chose
participants who had responded to the survey for the research questions. I chose previous
participants of the survey because they would have more insight into how the prototype
function and what technology the prototype uses. I also chose students with a background
in computer science, in the last year of their degree, because my assumption is that their
general understanding of technology could offer better answers than less experienced tech-
nologists. I decided on dividing the results of the user-tests into each role of the prototype.
Further, each role is divided into what the participant answered, related to the research
questions. Lastly, a section of general comment follows.
I used an item and simulated that it had an IoT sensor attached to it, along with the proto-
type running on a computer, and acted out the different scenarios with the participant, in
order to make the testing as realistic as possible.
8.1.1 user-testing: Renter

This was the second largest part of the user-test. Each participant completed three use cases
in the test. These use cases were: ”Select an item and activate the renting process”, ”Use
the item,” and ”Deliver the item back”. While testing each of the uses cases the participants
were explained what was happening in the app, especially regarding the sending of data,
and automatic payment.
83
Chapter 8. Evaluation and discussion
Use of data in price calculation
Participants stated that the prototype lacked information about how much it usually costs
to rent an item. The price listed was for each type data, which made it difficult for the
renter to make an estimate how much it would cost to rent the item. Users suggested
that an average price based on previous rentals should be displayed for the renter. Also,
displaying price comparisons of other lenders lending similar items was also suggested.
Automatic payment
The participants did not mind that transactions are running while using the item. A partici-
pant stated that this was a nice feature that would give the renter more flexibility in relation
to how long the renter wants to rent the item. This participant gave the example of a renter
needing to extend the rental period. The renter would not have to worry about giving the
item back before the renter were finished using the item. Another participant suggested
that the system should include a refund program if an item breaks while using it, and it is
not renters fault. One of the participants stated that using a cryptocurrency to pay seemed
foreign, therefore the prototype should include a user-friendly gateway between Ethereum
and fiat currency. If this gateway functioned well, the participants would be more positive
towards using the system. The participants expressed concerns about the renter having to
pay transaction fees both for the transaction fees for storing data generated and for activat-
ing the smart contract on the blockchain. Nevertheless, it was stated that they would use
the system if these fees were not too high.
Real time monitoring
The participants did not like the GPS monitoring of items. This was also reflected in the
results of the survey regarding my research questions. The participants felt that the GPS
monitoring was uncomfortable, because it intruded upon their privacy. However, the par-
ticipants stated that the other monitoring of the item was good. The participants said that
they would handle an item with more care when it is monitored because this would be
reflected in the cost. A participant stated that the monitoring assigns a greater responsibil-
ity to the renter. Another participant stated that the monitoring was fine, but would have
preferred not being monitored at all, especially the monitoring of their location. Another
participant underlined the importance of informing the renter about the monitoring. A par-
ticipant noted that it would helpful to get a notification if the renter handled an item too
roughly.
Data purchase
Participants did not mind that data was purchased by a third party, as long as the data was
anonymized beforehand. However, a participants found problems in the ownership of the
data in the prototype. And asked: Who owns the data, the owner of the item, or the renter?
84
8.1 User-testing
8.1.2 user-testing: Lender

The lender role was the most comprehensive role to test. This role touches upon almost
every aspect of the prototype, and is therefore the most important role to test. Hence, the
accompanying interview, included the most questions for the testers. The use cases tested
for the lender role was: ”Register an item and put it up for rent”, ”Show status of a rented
item”, and ”Take back a rented item”.
Use of data in price calculation

Participants stated that setting the weights for the calculation of price with the data, was
difficult. It was hard for the participants to imagine what the price of a specific type of data
should cost. Also, the participants stated that they had never calculated anything based on
data. Setting the price in Ether made it even harder for participants to determine the value
of the weights. The participants expressed that their lack of knowledge about Ether pricing
and conversion to fiat currency was an important cause for this. Once more a fiat gateway
was proposed for the system. A participant stated that it would be nice with predefined
weights for different classes of items, making it easier to determine good weights. In
addition, setting the deposit proved difficult for the participants. Most of them stated it
would be helpful with information about the average deposit set for similar items. All of
the participants stated that the prototype would give a fair calculation of price, as long as
good weights are in place for the calculation. Moreover, a participant stated that different
items should be tested with the sensors in order to determine what type of data that should
make an impact on the price.
Automatic payment
Nothing particular were stated about the automatic payment aspect of the prototype from
the lender perspective.
Real-time monitoring
Regarding the real-time monitoring feature of the system, privacy was once more of con-
cern for the participants. One participant found the monitoring the renter’s position un-
comfortable. However, all the participants were positive to the other monitoring aspects
of the prototype. Stating that as lender it is a good feature that would make them feel safer
about lending their items’. And that it was nice to see if the item were treated well or
badly. A participant stated that if the prototype was a real system, the participant would be
more likely to rent its things. Another participant said that the monitoring could be source
of stress for the lender. And said that a lender could become occupied by always monitor-
ing items, worrying more about the items’ condition, than they would without monitoring
in place. A participant stated that it would make it more comfortable to rent things to
strangers with the monitoring in place. The same participant suggested a reputation sys-
tem for the prototype. Which would keep track of renters previous experiences with other
items. And based on this how well a renter had treated previous items, be able to determine
if the lender wants to lend its items to that specific person.
85
Data purchase
The participants were positive to the idea of selling the data, as long as the data is anonymized.
However, some participants wondered about how much you would actually make by sell-
ing the data of your items. Also, a participant wondered who are owner of the data in the
prototype: the renter or the lender?
8.1.3 user-testing: Third party

Testing of the third party role was the most difficult role in testing. Due to students lack of
experience in purchasing data or looking at data from a business perspective. Therefore,
getting accurate, and realistic results from this part of the user-test were difficult. However
I did get some feedback. The use case that was tested in relation to the third party role
was: ”As a third party, buy data.” The third party role only partakes in one aspect of the
prototype and is therefore excluded from the other aspects.
Data purchase
Participants stated that purchase of user data is a good opportunity for a third party, and
a helpful way to improve their products. Once more, problems regarding privacy were
pointed out. And that data should be anonymized before a third party is allowed to pur-
chase the data. The question regarding who owns the data was also raised again. A partic-
ipant asked who should be allowed to purchase data, who can be a third party? Moreover,
the participant said that it would only sell data to serious actors because the participant
was afraid that an actor could use the data maliciously.
8.1.4 General comments

After all the tests and interviews were completed, I proceeded to ask the participant about
general feedback on the prototype. All the participant stated that the prototype had a nice
flow to it and that it was easy to use. Two participants especially like the scanning of the
item’s IoT device. Participants also stated that the concept of sharing items is good for the
environment, and having a system like this could make more people want to share their
items. Participants also found it interesting that users could sell data, and, that lenders
would get better control of their items because they are being monitored.
On the negative side, participants stated that they felt they lacked a communication chan-
nel between the renter and the lender. Also, that they wanted more information about a
potential renter before lending their items to it. Privacy was a huge concern for all of the
participants, and they stated that privacy must be taken into account before putting such
a system into production. Another participant stated that the security of the IoT device
should be adequate, in order to hinder potential tampering of the device, which could re-
sult in the device reporting false data. One participant also stated that seniors might have
difficulties adopting this kind of technology.
86
8.2 Discussing the prototype

This section is divided into each of thesis’s research questions, with each section divided
into problem areas for the prototype related to the question. The problem areas were
identified by the author and in the user-tests. The problem areas are:
• Research question 1:
– The data weights
– Paying for smart contract usage and data storage on the Ethereum blockchain
– Owner of the data
– Fairness of the prototype
– Real-time payment
– Paying with Ethereum
– Privacy and security of data
– Real-time monitoring of items
– Usefulness of the data
– (Privacy and security of data)
• General problems:
– Lack of information in the user interface
8.2.1 Research question 1

How can data be used in a decentralized sharing economy platform to determine an accu-
rate and fair price for both the renter and the lender?
Data Weights
Testers had difficulties setting the weights for each data type in the prototype. It is not
surprising, because testers lack experience in data-price calculations. It is understandable
that the weights are difficult to set. Different items would require different weights, and
people would lack experience in making such calculations. For instance, a fragile item
would need a higher weight for its impact data than a though item would need to reflect
the cost of tear and wear. However, what could be a viable method for setting the weights
in the prototype?
First, we would have to find a starting point for the weights. To define a starting point for
the weights, testing would have to be done on different types of items with the IoT device
87
attached to it. Several tests would have to conducted in order make a good estimation of
what the different weights could be. The testing would start by finding items that could
represent most items of the same type. Then, we would have to test and use the items
in different scenarios. These scenarios could include: testing normal usage of the items,
rough usage of the items, breakage, and similar tests. We would then be able to make an
estimation of the weights derived from the data generated by these tests. The goal of the
initial tests would be to find weights that would pay an amount of Ether that is equal to
the items cost when the item becomes depleted. With weights that generate a zero-sum
cost of renting an item, the weights could be tuned into generate profit for lenders. The
system would recommend these weights, but should allow lenders to tweak them to their
liking. After some time, the system could use the data generated by the items’ IoT device
to tweak the weights more accurately for specific items. Finding the estimates for the
weights would be a tedious process. There would be many different items to test, and
it would take a lot of time and resources to do so. It is likely that some manufacturers
do tests on their products and are aware of what durability their product has. Therefore,
another approach could be to gather item durability data from different manufacturers of
items and then apply weights based on their data. Another idea would be to give the users
the possibility to set the weights themselves and let the open market decide by itself, what
the weights should be. Making the market decide the weights themselves could be, as
discovered in the user-tests, difficult for the users. Hopefully, users would be able to learn
how to set good weights over time. Another possibility of helping the users set accurate
and good weights, could be to show the users average weights set on different items over
time. The average weights could be a good reference for the users.
Paying for smart contract usage and data storage on the Ethereum blockchain
Renters in the prototype have to pay fees for the prototype to functional well. This was a
concern for the testers and is also a general problem of the prototype. Making payments
and running software decentralized on the Ethereum blockchain is not free. Moreover, it
is the renters in the prototype that have to pay most of these costs. Renters of the system
have to pay Gas each time they send data to the blockchain for calculation and storage.
Gas is a unit of measuring of the computational work needed for running a smart contract
and making transactions in the Ethereum network. The price for Gas is paid in wei; one
wei is 1 ∗ 10− 18 Ether. The price of Gas varies in the Ethereum network, and the current
(25.05.2018) [127] average Gas price is 7 Gwei (1 Gwei is 1 ∗ 109 wei). The variations in
Gas price are decided by the supply and demand for computing power in the Ethereum net-
work. According to Ethereum’s yellow paper [128], the fee for storing a 256-bit word on
the Ethereum blockchain costs 20 000 Gas. Meaning that if a renter where to send 1kB of
256 bit words of data, generated by the IoT device on an item, to the blockchain, it would
cost a renter 0.004375 Ether (8000/256 = 31,25 256 bit words in one kilobyte and 31,25*
20 000 gas = 625000 gas and 625000 gas * 7 Gwei = 0.004375 ETH) which is about 2.6
USD (25.05.2018). The prototype only sends four uints which are 256 bits each. Meaning
that a renter would have to pay about 0.34 USD (4 ∗ 20000 ∗ 7Gwei = 0.00056Ether)
for sending data with the current implementation of the prototype. However, there might
be items that need to send more data, and therefore the price for sending data could vary
in the prototype. Sending 8-bit [129] ints to the smart contract is possible. 8-bit ints have
88
a lower cost to send. However, not all data would be able to fit an 8-bit int.
What the calculation comes down to is how often a renter must send data. The more often
a renter sends data, the more accurate becomes the data stored on the blockchain. How-
ever, the renter would pay more fees in Gas the more often the renter sends data. It is up
to the lender to decide how frequent it wants information about the condition of its items.
Therefore the lender decides how often a renter must send transactions. For instance, let’s
say that the renter needs to send data every minute. The IoT device would send an average
of all data gathered in that minute for each type of data. The renter would have to pay Gas
each time it sends the data. Sending data on a minute basis would give the lender frequent
updates about the condition of its items. In contrast, data sent on a 30-minute basis would
give the lender information about its items only every 30 minutes. In addition, data could
become less useful for third parties if data was based on 30-minute averages. In total,
the price for the renter to send data varies by these factors: the frequency of how often
the lender requires information about its items, the type of data the renter sends (8-bit or
256-bit), and what the current price for Gas is in the Ethereum network. Renters should,
therefore, be informed about the extra costs of frequent data sending before renting an
item.
Owner of the data

When using encryption to store data on the blockchain (described in section 8.2.4), only
the lender and the renter have access to the data. Therefore both of these actors should be
the owner of the data. Initially, I decided that the lenders should be the owner of the data
because it is the lenders’ IoT devices that create the data. However, it is the actions of the
renter that triggers the creation of the data. Also, it is the renter that pays for the sending,
storing and processing of the data. If the renter pays the cost, it should be the renter that
owns the data. Optionally, the lender and the renter could split the cost of transaction fees
paid by the renter and split the profit made by selling the data.
Accuracy and fairness of price

The prototype gives a better accuracy of cost calculation than just calculating with time,
by including data about how renters handle items in its calculation of price. However,
the accuracy of the price is determined by the data weights, and by the sensor data. I
have already discussed the data weights, but not the sensors. In order for the prototype
calculate an accurate price, the sensors needs provide accurate data. If the sensors do not
output accurate data, the price will not be accurate and fair. Therefore, the lenders should
calibrate their sensor after each use in order to mitigate the risk of data being inaccurate.
Fairness is relative, however, I do not believe it is fair that the renter should the take the
full cost of sending data because this is a feature for the lender. The prototype should make
the renter and the lender split this cost, in order for the prototype to become fairer to use.
Also, the user-tests revealed that lenders would use the option of having more frequent
data transactions if the item they were lending was more valuable. Meaning that renters
89
should expect to pay higher fees while renting valuable items. I believe this is fair, because
the lender takes a larger risk by lending an item that is worth more.

How could such system provide real-time decentralized payment through a blockchain
technology?
Real-time payment
Participants stated that real-time payment in the prototype was useful feature. Real-time
payment, gives the renter the possibility to extend their rental period if they need to. How-
ever, testers of the lender role did not mention this feature as either good or bad. My
opinion on the real-time payment feature is that it is also a good feature for the lenders. By
giving renters the possibility to extend their rental periods, will generate additional profit
for the lenders. However, the system could have allowed for renters to pay the lender after
the device was used. This would be in a scenario where the lender would not require any
information about its item’s condition during the rental period. Instead of sending data
during the rental process, all data would be calculated in one final transaction. However,
sending and calculating all of the data generated after the rental period is over would give
less accurate data for a data purchaser.
Regarding sending transactions in real-time in the prototype, comes down to how effi-
cient the Ethereum network is to confirm transactions. How fast a transaction is confirmed
in the Ethereum network comes at the cost of how much Gas a renter would pay to get its
transaction confirmed quickly. On average, a block in the Ethereum network is confirmed
every 17 seconds [130]. However, the transactions are valid until the block it is in, reaches
a certain depth on the Ethereum blockchain. Vitalik Buterin, the founder of Ethereum,
explains in a blog post [131] that users of Ethereum have to wait for at least 12 blocks in
order to be certain that their transaction is valid. Meaning that if a high enough amount of
gas is paid along with the transaction, and that the transaction gets put in the next block, it
would take about three minutes to get the transaction confirmed. This means the prototype
fastest transaction speed of Ether is about three minutes. And this would be the closest the
prototype could get to providing real-time payments.
Paying with Ethereum

Participants in the user-test stated that using a cryptocurrency in the system to pay was
difficult for them because they had not paid with a cryptocurrency before. The participant
stated that a fiat gateway in the prototype would be nice. The solution to this problem
is to have a conversion of Ether to the preferred currency of the user. The user interface
would display prices in the preferred currency for the users, however, users would still
pay and receive payment in Ether. With the conversion displayed in the user interface,
users would not need to know about Ether pricing. However, the users of the prototype
would still need to purchase Ether to use the system. There are several providers of fiat-to-
cryptocurrency exchanges in the cryptocurrency sphere, therefore, getting a hold of Ether
90
should not be a problem for the users. However, before releasing a system based on the
prototype, information about how and where to get Ether should be included.

How can real-time transactions with data provide real-time information to a lender about
the condition of its items?
8.2.4 Privacy and security

In both of the user-tests and the survey regarding my research questions, privacy was
identified as a problem for the prototype. Especially regarding the monitoring of renters
location, enabled by the GPS data sent from the IoT device. It is likely that EU’s General
data protection regulation (GDPR), and a recent scandal involving the improper use of
Facebook data [132], is the reason for privacy-related answers in both the user-tests and
survey. Nonetheless, it is an important matter.
There is a solution to the privacy problem in the prototype. The solution should be im-
plemented in the prototype before a potential release of a complete system. The solution
to the problem impacts how data is stored on the Ethereum blockchain and how users in
the prototype will be able to sell their data. As we know, the blockchain is completely
transparent. All users of Ethereum have access to all information stored on the Ethereum
blockchain. Meaning that all transactions made by all of Ethereum’s users are accessible
to anybody. However, users of Ethereum are anonymized by their public address. To use
the prototype, users only need an Ethereum address. And as long as users of the prototype
do not reveal their real identity, no one would be able to connect users real identity to their
address. As long as no one makes this connection, their privacy is safe. However, this is
difficult in the prototype. It is likely that a renter has to meet the lender in person to rent
an item. Therefore a lender would be able to identify the renter and connect the Ethereum
address to the person. The lender would only have to check which Ethereum address sent
the payment for the rental. A renter would also be able to identify the lenders Ethereum
address with a similar method. After the lender has made the connection between a renter’s
real identity and its address, the lender could identify all transactions made by this person,
by looking up the renter’s address on the blockchain. Information about the compromised
renter could include all transactions containing data made by the renter, meaning that by
identifying a renter someone would be able to access all the data that a renter has gener-
ated. The lender would also be able to see all previous transactions made with the renter’s
address. A possible solution is for the renter to use a different Ethereum address each time
it rents an item. This would mitigate the risk of a lender finding the complete rental, and
transaction history of the renter. However, this solution is inconvenient for the renter.
Because of the transparent nature of the blockchain, the data that is transferred to and
stored on the blockchain in order to be calculated by the smart contract is also publicly
available. This is a problem for the renters because if a user were able to identify the
renter, the user would be able to get the renters entire history of transactions, and all previ-
ous data generated by this user. This is also a problem for the lender, if the data is publicly
91
available, a third party would not need to purchase the data. A third party could use the
system once as either renter or lender, store the bytecode of the smart contract from the
blockchain, and look up the bytecode on the blockchain. Then, the third party could iden-
tify all contracts made with the prototype, and identify all transactions made to each of the
smart contracts. Making the third party able to access all of the data, of all of the trans-
actions, from all of the items in the system without paying for it. This problem is created
because the prototype calculates the price of the data on the blockchain.
It is not possible to communicate encrypted with a smart contract, because a smart contract
is on the blockchain, and all information on the blockchain is transparent. In order to com-
municate encrypted with a smart contract, the smart contract would have to generate a key
pair and store it on the blockchain. However, when these keys are stored on the blockchain,
they would be accessible to everyone, ultimately destroying the purpose of creating them.
A solution to this problem would be to do the calculation with the data off-chain, meaning
that the calculation would take place on the IoT device of the item or the user’s client.
When the price calculation is complete, the IoT device or the user’s client will proceed
to encrypt the data. The encrypted data would be sent along with the unencrypted result
of the cost calculation to the smart contract on the blockchain. By encrypting the data
before sending it, would result in the data being stored on the blockchain encrypted. This
would mean that in the scenario when someone got a hold of the Ethereum address of a
user and identified the owner of it, they would not be able to get any useful information.
However, by encrypting the data from the renter would leave the lender blind, not able to
get information about the condition of its items. This would remove the functionality of
real-time monitoring of the system. However, there is a way to solve this problem as well.
To enable real-time monitoring with encrypted data in the prototype, the prototype would
need to establish an encrypted connection between the renter and the lender. The two par-
ties would, in turn, exchange the keys used for encrypting the data, making the lender’s
client able to decrypt the data of its items on the blockchain. The key exchange could, for
instance, be done over Ethereum’s Whisper protocol, which is a decentralized, encrypted
communication channel for decentralized applications [133]. To ensure that a lender can-
not access data of previous rentals made by the renter, the renter would need to generate
new encryption keys and exchange these keys with the lender for each time renting an
item. Making only the renter and the lender able to decrypt their renting sessions. Also,
by encrypting the data before storing it on the blockchain, would mitigate the risk of a
third party acquiring the data without paying for it.
In relation to the selling of the data in the prototype, the users of the system would have
to store their keys used in for encrypting the different rental sessions. A third party would
pay for the encryption keys of these rental sessions, to access their data. Moreover, to keep
privacy even better, the process of purchasing data should include a step to anonymize the
data before the third party receives it.
Cryptography in the prototype could also give the possibility of allowing users to encrypt
more aspects of information in the prototype. Encrypting more information about an item
could give the possibility of renting an item with only one specific user, and fully anony-
mous to other parties than the renter and lender. To achieve an anonymous rental session,
92
the lender could encrypt the item’s description, deposit, and id, sharing the encryption key
with the other user. The only data visible to a third party would be the sending of Ether
between the lender’s and renter’s addresses.
Other features that could be implemented to give users more control of their privacy could
be to let lenders decide what data they need for monitoring of their items. Meaning that
if a lender does not care about the GPS location of its items, it could turn it off. The
lender’s exclusion of different data monitoring could, in turn, attract renters that are more
concerned with privacy, and the lender could make a bigger profit. The data could still
be valuable for third parties, and the lender would still receive information (except for the
excluded data types) about the condition of its items.
Real-time monitoring of items

In the discussion of the real-time payment in the prototype, we showed that the prototype
is only able to do transactions of Ether every third minute. However, this is not the case for
the real-time monitoring of the data. The data is available for the lender to be view when
the data reaches the blockchain. It is only the payment with Ether that has to wait in order
for users to be certain that the transaction is valid. Meaning that as soon as the transaction
that includes data from an item is formed into a block and the block is mined onto the
blockchain, the lender’s client will be able to access the data. The only factor playing a
role in how quickly the lender’s client could get a hold of the data is tied to the price of
the Gas spent for making the transactions. Once more, paying a higher price for Gas, the
faster a transaction would be added to the blockchain. Meaning, that if a renter were to
pay a high price for the Gas, maximum wait time for the lender to get an update about its
items condition, would be about 30 seconds (paying 20 Gwei pr gas at 25.05.2018 using
ETH Gas Station for calculation [127]).

How can data be stored on a blockchain to provide manufacturers of items information
about how their items are being used?
Usefulness of data
A participant in the user-test asked an important question regarding data purchase in the
prototype. The question was: How useful is the data generated by the items to a manufac-
turer? My answer to this question: It is likely that manufacturers test their items before
mass production. So for larger manufacturers who do thorough testing of their products,
the data might not be useful. However, this depends on the needs of the manufacturers.
Smaller manufacturers with fewer resources for testing of their products may want to pur-
chase data related to the item they produce.
Other third parties than manufacturers could also make use of the data generated by items.
For instance, state institutions like the ministry of transport could make use of GPS data
of vehicles to locate hold-ups in traffic and optimize roadmaps.
A problem related to the usefulness of the data that the prototype generates is the quality
93
of the data. As discussed in section 8.2.1, the frequency of data transmission determines
the quality of data. If the quality of the data is not adequate for the manufacturers, this
feature could see little use.
Privacy and security of data
This section is listed twice because privacy and security of data touch upon aspects of
research question 3 and 4. A discussion and a solution to problems related to privacy and
security of data are found in section 8.2.4 and applies to both questions.
8.2.6 General problems

Lack of information in the prototype’s user interface
A general take from the user-tests was that the participants wanted more information in
the different user interfaces for the different actors in the prototype. Giving users more
information about average rental prices of items, weights set for similar items. Information
like this should be implemented in the prototype before a potential release of the system.
A reputation system could be difficult to create due to the privacy of users. However, the
prototype could allow users to decide on how much information they are willing to reveal
from previous rental sessions. This feature could result in a system with different kinds of
users. Ranging from entirely anonymous users to users that wants to share their reputation
with other users. It would be the lender’s choice to decide which renters it would trust to
rent its items. Renters could choose if they want to partake in the reputation system or
not. A benefit of partaking in the reputation system could be that lenders would be more
willing to lend their items to renters that partake in the program. This comes at the cost of
letting lenders know about some of the data from previous rentals, thus reducing privacy
for the renter. With a reputation system in place, anonymous renters could have a harder
time getting to rent items, because they could be perceived as less trustworthy.
8.3 Choice of technology

In this section, I discuss the choice of the different technologies I used for developing the
prototype. This thesis describes how Ethereum function in section 4.4.1 (Ethereum), and
section 7.1 describe the other technologies used in the prototype.
8.3.1 Ethereum
Of the reviewed blockchain technologies in the state of the of blockchain technologies,
there was only two blockchain technologies, Ethereum and NEO, with the possibility to
run smart contracts. Making the prototype run solely on a smart contract would make
the system more decentralized. The only part that is centralized is the serving of the
prototype’s user interface. I chose Ethereum over NEO for several reasons:
94
8.3 Choice of technology
• Ethereum has high maturity and have been in use for several years, NEO on the
other hand is fairly new in comparison (Ethereum was released in 2014, NEO was
released in 2017)
• Because of Ethereum’s longevity, the protocol has been tested and used for many
years. As a result of its age, Ethereum is better tested and more used than NEO.
Besides, Ethereum has a bigger community of developers, which in turn gives de-
velopers more resources on how to use the technology.
• NEO is currently in need of validator nodes to run its smart contracts. To become a
validator node in the NEO network, users have to stake at least 10 000 GAS, costing
approximately 19 000 dollars at today’s (25.05.2018) GAS price [134]. This is a cost
out of reach for most people. The high cost of becoming a validator node, results
in a smaller amount of miners, making NEO more centralized, and more prone to
DDoS attacks. Some sources even claim that all validator nodes in the NEO network
run by the NEO foundation, making the smart contract feature of NEO completely
centralized [135]. There no formal requirements of becoming validator node in the
Ethereum network. In fact, every miner in the Ethereum network is mining both
transactions and smart contracts, making Ethereum more decentralized than NEO.
Another factor in the choice of blockchain protocol is that Andreas Bogner, Matheiu Chan-
son, and Arne Meeuw’s (BCM) [7] had proved that it is possible to run an SEP on the
Ethereum blockchain. Moreover, since their proof of concept also revolves around the
sharing of items, I could use their proof of concept to learn how to write code for Ethereum
efficiently and have the possibility reuse parts of their code.
8.3.2 Web3.js
BCM’s proof of concept was also using Web3.js. Web3.js is officially supported and de-
veloped by the Ethereum foundation. I did a search for alternatives to web3.js and found
other Ethereum libraries. These were: ethers.js and ethjs.js. However, Web3.js had far
better documentation compared with the others. At the same time, it felt safer using an
API officially supported by Ethereum. To determine popularity and usage of the different
libraries, I did a lookup on different libraries on the knowledge sharing platform for de-
velopers, ”Stack Overflow”. Searching for the Web3js yielded 218 results, the other two
yielded no results. The result of the lookup was a good indicator of usage. Also, I could
have reviewed the different technologies, and compared them with each other, but overall
web3.js seemed like the best choice based on the factors mentioned.
8.3.3 Truffle framework

BCM’s proof of concept did also use the Truffle framework. Truffle is the most popular
Ethereum development framework. Other frameworks like Populus [136], Embark [137],
and Aragon Nest [138] do exist, but is substantially less popular than the Truffle frame-
work. The Truffle framework was by far the most starred (6000 times) framework on
GitHub [139] of these four, with Embark coming second with about 2000 stars. The other
two had less than 250 stars each. The amount of stars is a good indicator of the popularity
95
of code on GitHub. Other sources found also suggested that Truffle was the framework of
choice [140] [141]. However, what it came down to was the adoption of Truffle compared
to the others. Because I am new to programming with Ethereum, the choice landed on
Truffle. Because of its popularity, I assumed that there would be more resource on how
to use the framework. Also, it gave me the opportunity to learn even more from BCM’s
proof of concept.
8.3.4 Ganache
For testing and simulation of Ethereum blockchain and nodes, I chose Ganache, because
it is a part of the Truffle suit.
8.4 Other problems

8.4.1 Problem: Running an Ethereum client on a smart phone
At the time of writing, Ethereum is not able to run properly on smartphones. Meaning that
the prototype is not able to run on a smartphone either. However, the Ethereum team is
working on a solution. Ethereum has two types of nodes, a full node, and a light node.
It is required to download the entire blockchain of Ethereum to run a full node. Also, a
certain amount of processing power is required to run a full node. A smartphone does not
have the capacity to download the 611 GB Ethereum blockchain. Nor does a smartphone
possess the computing power required to run a full node. Therefore, smartphones must run
an Ethereum light node to connect to the Ethereum blockchain. A light node has limited
functionality compared to a full node, and system requirements are lower for running a
light node. Light nodes need to be connected to a full node in order to do transactions.
However, the development of the light node is yet to be finished by the Ethereum organiza-
tion. The prototype will therefore not be able to run on a smartphone before the Ethereum
light node is completed.
8.4.2 Problem: Paying for smart contract usage and data storage on
the Ethereum blockchain
The main problem of using Ethereum in the prototype is the cost of transactions for the
users. Ethereum has fees for conducting value transfer, for storing data and deploying
smart contracts. It is not possible for any actor of the prototype to avoid paying fees in
the prototype. The renter would have to pay fees for deploying the smart contract and
adding items to it. A third party would have to pay fees when purchasing data. However,
the actor of the prototype that would have to pay the most significant cost is the renter.
The renter has to pay fees for sending payments to the lender and pay fees for storage
of the data generated by the IoT device on the item of the lender. Also, as discussed,
the fees for storing data can become quite high. The reason for the high cost of storing
data on the Ethereum blockchain is that the data stored on the blockchain is stored on it
forever. This is due to the nature of the blockchain, once data is put on the blockchain,
it can never be deleted. Comparing the price for data storage on a blockchain with a data
96
8.4 Other problems
storage service like Dropbox would yield a huge difference in price. This price difference
is because Dropbox can delete data from their disks. However, on the blockchain, you pay
one time for storing your data forever. If we do the maths on calculating a price for sending
and storing 1 KB of data on the Ethereum blockchain and scale it to 1 GB instead, would
result in a price of 4375 Ether per GB (8 000 000 000/256 = 31250000 256 bit words in one
gigabyte and 31250000* 20 000 gas = 625000000000 gas and 625000000000 gas * 7 Gwei
= 4375 ETH). 4375 Ether converts to 2 627 349.375 USD (at today’s price of Ethereum
26.05.2018). The price would be even higher, because it would take several transactions
to send the data, adding a fee for each transaction. This calculation shows that storing
data on the Ethereum blockchain is expensive and must be taken into consideration when
developing systems with Ethereum. It is worth noting that the prototype deals with much a
smaller size of data. Considering the costs calculated in section 8.2.1 shows that system is
viable, but costly to use when minutely monitoring is required by the lender. Ethereum is
planning to change consensus algorithm to Proof of stake. The changing of the consensus
algorithm may result in lower transaction fees in the Ethereum network [142].
8.4.3 Possible solutions: StorJ

There are possibilities for keeping storage costs low and keep the system decentralized.
For instance, the blockchain protocol StorJ [143]. StorJ is a blockchain protocol specifi-
cally designed for storing data distributed and decentralized. StorJ allows its users to rent
their free hard drive space with others. If you were to upload data in the StorJ system, it
would not be stored on a blockchain, but in a distributed and decentralized fashion on the
hard drives of the system’s storage providers. The cost of using StorJ for storage of data
is significantly lower than using Ethereum. StorJ’s current price for storing data is 0.015
USD per uploaded GB, and 0.05 USD per downloaded GB. StorJ could be implemented
in the system for data storage, removing fees for data transfer and storage on the Ethereum
blockchain, resulting in a decentralized system, but with lower costs. StorJ could also host
the code of the user interface, making all aspects of the system completely decentralized.
8.4.4 Possible solutions: IOTA

IOTA is a cryptocurrency that does not utilize a blockchain, but a DAG named The Tangle,
in order to keep track of transactions. IOTA does not have any fees. It is completely free
to send transactions in the IOTA network. Also, users can send data in transactions. IOTA
scales well, the more users of the Tangle, the faster transactions gets confirmed. IOTA
would, therefore, come closer to real-time monitoring than what the prototype is capable
of. However, when it comes to the storing of data, the data sent and store on the Tangle is
only stored there temporarily. From time to time, the IOTA foundation does a snapshot of
the tangle. When a snapshot of the tangle is taken all data stored on it is removed from the
transactions, keeping only information about the transferring of IOTA tokens (when IOTA
is released, a snapshot of the Tangle will be taken monthly). IOTA’s solution for keeping
the data that is being removed from the Tangle is with special nodes in the IOTA networked
called Permanodes. A Permanode would keep a complete copy of the different snapshots
of the Tangle, not removing the data stored in its transactions. However, to receive data
from previous snapshots from the Permanodes, a user would have to pay a fee [144]. If
97
it becomes few Permanodes in the IOTA network, this feature will become less decentral-
ized. The CTO of IOTA, David Sønsterbø, proposed a similar business model like StorJ
and Sia [145] to have a sustainable ecosystem surround the Permanodes [146]. Optionally,
users of IOTA could download and store the snapshots themselves.
If the prototype were implemented with IOTA, data would need to sold before each snap-
shot, or the users of the prototype would have to store the data themselves or to pay to get
the data from Permanodes.
At the time writing (26.05.2018) IOTA is not decentralized and is using what they call
a ”Coordinator,” which is a node in the IOTA network, owned by the IOTA foundation,
validating all transactions in the IOTA network. IOTA is newer, without smart contract
functionality, and is less tested and used than Ethereum. Also, MIT researchers found
several security vulnerabilities in the IOTA protocol: IOTA uses a trinary system instead
of binary system, which could introduce new vulnerabilities compared to the well tested
binary systems. IOTA was running their self-made cryptographic functions. New crypto-
graphic functions usually undergo a test period of several years before they are put to use,
but IOTA’s cryptographic function did not. The cryptographic problems have later been
fixed, but the use of trinary remains in IOTA [147] [148]. It is also worth noting that IOTA
has implemented a decentralized data marketplace for the Tangle. If the prototype were
implemented with IOTA, the selling and purchasing of data would take place in IOTA’s
data marketplace instead of taking place in the prototype [149].
IOTA based prototype

If IOTA were fully functional, decentralized and mature, it would have been the choice of
technology for the prototype. Considering that IOTA is specifically designed for IoT, it
would fit our use case well. Therefore, I want to highlight the impact the implantation of
IOTA could have on the prototype. Firstly, the system’s architecture would be different.
IOTA does not have smart contract functionality. Because of the lack of smart contract
functionality, the calculation of price based on the data generated by an item’s IoT device
would have to take place on the IoT device instead. The fact that the calculation takes
place on the IoT device could heighten its hardware requirements. Optionally, this calcu-
lation can take place on the users’ phones. In contrast to our IOTA, the calculation in the
prototype is made on the Ethereum blockchain. If I were to use IOTA instead of Ethereum,
the main difference would be where the calculation of cost takes place. Also, the purchase
and selling of data would take place on the IOTA data marketplace. In contrast to the pro-
totype, where it takes place in the prototype itself. However, there are similarities. Both
systems would store data on their respective ”chain.” To meet privacy requirements, both
systems would have to encrypt data before storing it. Moreover, users would still have
to exchange keys with each other in order to enable real-time monitoring. Both systems
would need to have a client run on users’ phones. Moreover, third parties would have to
purchase the keys used for encryption of data. An implementation of the prototype with
IOTA would have all smart contract logic on the users’ clients and on IoT device itself. The
Tangle would only be used to store data, and send transactions of IOTAs. How I picture
the prototypes architecture with IOTA can be seen in figure 8.1
98
8.4 Other problems
Figure 8.1: Prototype’s architecture if implemented with IOTA
99
100
Chapter 9
Conclusions
Technology is allowing more people to partake in the sharing economy. At the same time,
the internet of things is coming closer to becoming a reality. The blockchain has shown
that decentralized payment is possible without trust. Researchers suggest that blockchain
and IoT is a good match and that the sharing economy can make use of blockchain based
systems. In this thesis, I suggest that a combination of sharing economy, IoT, data and the
blockchain in a decentralized sharing economy platform is possible. And I have shown that
this is possible by researching blockchain technologies, IoT and developing a prototype.
I have investigated four research questions and the conclusions of the research questions
are as follows:
9.1 Research question 1

How can data be used in a decentralized sharing economy platform to determine an accu-
rate and fair price for both the renter and the lender?
I have demonstrated that it is possible to use data in a decentralized sharing economy

platform to determine an accurate and fair price for the lenders and renters of such a sys-
tem. This was demonstrated by including price calculation based on different types of data
in the prototype.

How could such system provide real-time decentralized payment through a blockchain
technology?
I have demonstrated that it is not possible for a sharing economy platform based on
Ethereum to provide real-time payment. Because of Ethereum’s transaction speed, the
101
Chapter 9. Conclusions
users of the prototype will, at best, only be able to receive payment of Ether every three
minutes.

How can real-time transactions with data provide real-time information to a lender about
the condition of its items?
I have demonstrated that the sharing economy platform is able to provide information
to lenders regarding their items when they are in use. The system is capable of delivering
information regarding lenders items in 34 seconds intervals at best.

How can data be stored on a blockchain to provide manufacturers of items information
about how their items are being used?
I have demonstrated that by using a blockchain to store data, makes it possible for third
parties to purchase data from users of the sharing economy platform. This is made possi-
ble because every transaction with data is stored on the Ethereum blockchain. By storing
the data on the blockchain, makes it possible for a third party to access the data.
9.5 Future work

To answer this thesis’s research question, I did a study limited to the top 10 cryptocur-
rencies in order to find a suitable blockchain protocol for the prototype. However, there
are several other Blockchain protocols, and Ethereum might not have been the best choice
of protocol for the prototype when comparing it to other blockchain protocols outside of
the top ten. Therefore a review of blockchain protocols with smart contract functionality
could be interesting research. And, with over 1400 blockchain protocols in the blockchain
sphere, of various maturity, it could be relevant to develop a methodology for comparing
blockchain protocols and technologies.
In addition, finding appropriate weights to make price calculation based on data proved
to be a challenge in the user tests. As described in section 8.2.1, finding high-quality
weights is a difficult problem in general. And good weights is crucial for the prototype to
make accurate and fair price calculations. In addition, the IoT is and will generate substan-
tial amounts of data, therefore a model for calculation of cost based on data could prove
useful in other data-based systems.
I did not use an IoT device, for gathering data in this thesis. Instead, data was manually
inserted. Therefore to build a device with sensors that may give appropriate information
102
9.5 Future work
about an item’s condition and whereabouts may be interesting research.
As discussed, IOTA would be the optimal choice of technology for the prototype, if the
technology was more mature. Therefore future work can be to develop the prototype with
IOTA as the fundamental technology, show how it was done, and compare it to the proto-
type of this thesis.
In summary:
• Do a review and comparison of blockchain protocols with smart contract function-
ality
• Develop a methodology for comparing blockchain protocols and technologies

• Discover accurate weights of high quality for data price calculations for the proto-
type
• Develop a model for data-based cost calculations
• Build an IoT device that may give appropriate information about an item’s condition
and whereabouts
• Develop the prototype using IOTA as the fundamental technology, show how it was
done, and compare it to the prototype of this thesis.
103
Chapter 9. Conclusions
104
Bibliography
[1] Juliet B Schor and Connor J Fitzmaurice. 26. collaborating and con-
necting: the emergence of the sharing economy. Available at: http:
//www.bc.edu/content/dam/files/schools/cas_sites/
sociology/pdf/SchorElgarHandbook.pdf, 2015. Accessed on
2.12.2017.
[2] Ted Choe. The rise of the sharing economy. 2016.
[3] Georgios Zervas, Davide Proserpio, and John W Byers. The rise of the sharing
economy: Estimating the impact of airbnb on the hotel industry. Journal of Mar-
keting Research, 2014.
[4] Kyoochun Lee In Lee. The internet of things (iot): Applications, investments,
and challenges for enterprises. Available at: https://ac.els-cdn.
com/S0007681315000373/1-s2.0-S0007681315000373-main.
pdf?_tid=580e88d6-d76a-11e7-a8b9-00000aab0f02&acdnat=
1512223920_1d7b4d17369646be6e28919a82c51949, 2015. Accessed
on 10.12.2017.
[5] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. Available at:
https://bitcoin.org/bitcoin.pdf, 2008. Accessed on 18.11.2017.
[6] Ottawa tool library. Ottawa tool library faq. Available at: http://
ottawatoollibrary.com/faq/, 2017. Accessed on 02.12.2017.
[7] Andreas Bogner, Mathieu Chanson, and Arne Meeuw. A decentralised shar-
ing app running a smart contract onthe ethereum blockchain. Available at:
https://www.researchgate.net/publication/310396688_A_
Decentralised_Sharing_App_running_a_Smart_Contract_on_
the_Ethereum_Blockchain, 2016. Accessed on 18.02.2018.
[8] slock.it. The usn. Available at: https://slock.it/usn.html, 2018. Ac-

cessed on 28.02.2018.
105
[9] Oria. Oria.no research databases. Available at: https://
bibsys-almaprimo.hosted.exlibrisgroup.com/primo_
library/libweb/action/search.do?vid=NTNU_UB&openFdb=
true&searchType=AZ&searchTerm=A&prefLang=no_NO#, 2018.
Accessed on 20.04.2018.
[10] Coinmarketcap.com. Cryptocurrency market capitalizations — coinmarket-

cap. Available at: https://web.archive.org/web/20180116123504/
https://coinmarketcap.com/, 2018. Accessed on 23.01.2018.
[11] Rainer Alt Thomas Puschmann. Sharing economy. Available

at: https://link.springer.com/content/pdf/10.1007%
2Fs12599-015-0420-2.pdf, 2015. Accessed on 01.12.2017.
[12] Giacomo Morabito Luigi Atzori, Antonio Iera. The internet of

things: A survey. Available at: https://ac.els-cdn.com/
S1389128610001568/1-s2.0-S1389128610001568-main.pdf?
_tid=7ba73d8f-0db0-4dbd-9be3-87692dac6892&acdnat=
1524663229_fbaf0307fbf9ada5d9b43753ed3c52ed, 2010. Accessed
on 25.04.2018.
[13] Slaven Marusic Marimuthu Palaniswami Jayavardhana Gubbi, Rajku-

mar Buyya. Internet of things (iot): A vision, architectural elements,
and future directions. Available at: https://ac.els-cdn.com/
S0167739X13000241/1-s2.0-S0167739X13000241-main.pdf?
_tid=c7220dec-6dfa-4265-b672-6c0f9f32f654&acdnat=
1524733508_90d2ce4fdbff6d0083a79029d4206c50, 2013. Accessed
on 25.04.2018.
[14] Egol M Clarke D Atkinson J Blumenthal J Decker B Hobbs M Shirsekar S

Bothun D, Lieberman M. The sharing economy. Available at: https:
//www.pwc.com/us/en/industry/entertainment-media/
publications/consumer-intelligence-series/assets/
pwc-cis-sharing-economy.pdf, 2015. Accessed on 01.12.2017.
[15] Aleksandra Kosintceva. Business models of sharing economy companies. Available

at: https://brage.bibsys.no/xmlui/bitstream/handle/11250/
2403861/masterthesis.pdf, 2016. Accessed on 09.05.2018.
[16] Aditi Sarkar Alain Chong M S Balaji, Sanjit Kumar Roy. User ac-
ceptance of iot applications in retail industry. Available at: https:
//www.researchgate.net/publication/308643074_User_
Acceptance_of_IoT_Applications_in_Retail_Industry, 2016.
[17] Wikipedia contributors. Rice - wikipedia. Available at: https://en.

wikipedia.org/w/index.php?title=Rice&oldid=838551864,
2018. Accessed on 04.05.2018.
106
[18] Wikipedia contributors. Radio-frequency identification - wikipedia. Avail-
able at: https://en.wikipedia.org/w/index.php?title=
Radio-frequency_identification&oldid=836773617, 2018.
[19] Aucxis. Rfid chip. Available at: https://www.aucxis.com/en/rfid/

rfid-products/rfid-chip, 2018. Accessed on 26.04.2018.
[20] Zoe Romano. Arduino blog welcome arduino yn the first board combining arduino
with linux. Available at: https://blog.arduino.cc/2013/05/18/
welcome-arduino-yun-the-first-member-of-a-series-of-wifi-products-c
atb, 2018. Accessed on 03.05.2018.
[21] Jan Newmarch. The internet of things - a techie’s viewpoint. Available at: https:
//jan.newmarch.name/IoT/Micros/Introduction/, 2018. Accessed
on 04.05.2018.
[22] Particle.io. How to select a microcontroller for your iot

devices. Available at: https://www.particle.io/
mcu-vs-soc-vs-microprocessor-for-iot/, 2018. Accessed on
05.05.2018.
[23] Tesla. Tesla. Available at: tesla.com, 2018. Accessed on 05.05.2018.
[24] Modum.io. modum.io — solution. Available at: https://modum.io/

system/, 2018. Accessed on 29.01.2018.
[25] Dentacoin.com. Dentacoin. Available at: https://dentacoin.com/, 2018.

[26] Tron.network. Tron. Available at: https://tron.network/en.html, 2018.

[27] Serguei Popov. The tangle. Available at: https://iota.org/IOTA_

Whitepaper.pdf, 2017. Accessed on 23.01.2018.
[28] Coinmarketcap.com. Cryptocurrency market capitalizations: sorted by trade vol-

ume. Available at: https://coinmarketcap.com/, 2018. Accessed on
15.03.2018.
[29] Victor S.Adamchik. Concept of hashing. Available at: https://www.cs.cmu.

edu/˜adamchik/15-121/lectures/Hashing/hashing.html, 2009.
[30] Alt H. Dietzfelbinger M. Reischuk R. Scheideler C. Vollmer H. Wagner D Vcking,

B. Algorithms unplugged. Available at: https://link.springer.com/
content/pdf/10.1007%2F978-3-642-15328-0.pdf, 2011. Accessed
on 04.12.2017.
107
[31] Tutorialspoint.com. Cryptography hash functions. Available at: https:
//www.tutorialspoint.com/cryptography/cryptography_
hash_functions.htm, 2018. Accessed on 19.03.2018.
[32] Douglas R. Stinson. Cryptography: Theory and practice, third edition.
Available at: http://www.ksom.res.in/files/RCCT-2014-III-CM/
CryptographyTheoryandpractice(3ed).pdf, 2014. Accessed on
04.12.2017.
[33] Andreas M. Antonopoulos. Mastering bitcoin. Available at: http://chimera.
labs.oreilly.com/books/1234000001802/ch07.html, 2015. Ac-
cessed on 10.12.2017.
[34] Dirk Timmerman Peter Schwrzler. Iota-modelle zur beurteilung von adnexbefun-
den. Available at: https://link.springer.com/article/10.1007/
s00129-017-4193-1, 2018. Accessed on 02.02.2018.
[35] Saikat Guha Dawei Ding. Noisy feedback and loss unlimited private communi-
cation. Available at: https://arxiv.org/abs/1801.03996, 2018. Ac-
cessed on 15.01.2018.
[36] Ahmed Ben Ayed. A conceptual secure blockchain- based electronic voting system.
Available at: http://aircconline.com/ijnsa/V9N3/9317ijnsa01.
pdf, 2017. Accessed on 03.12.2017.
[37] Andreas M. Antonopoulos. Mastering bitcoin: Structure of a block. Available
at: http://chimera.labs.oreilly.com/books/1234000001802/
ch07.html#_structure_of_a_block, 2015. Accessed on 10.12.2017.
[38] Bitcoin.org. Developer guide - bitcoin. Available at: https://bitcoin.org/
en/developer-guide#block-chain, 2018. Accessed on 19.03.2018.
[39] Yoichi Hirai. Defining the ethereum virtual machine for interactive theorem provers.
Available at: https://link.springer.com/content/pdf/10.1007%
2F978-3-319-70278-0_33.pdf, 2017. Accessed on 23.01.2018.
[40] Vitalik Buterin. A next-generation smart contract and decentralized application
platform: Mining. Available at: https://github.com/ethereum/wiki/
wiki/White-Paper#mining, 2014. Accessed on 17.11.2017.
[41] Aad van Moorsel Maher Alharby. Blockchain based smart contracts : A sys-
tematic mapping study. Available at: https://www.researchgate.net/
publication/319603816_Blockchain_Based_Smart_Contracts_
A_Systematic_Mapping_Study, 2018. Accessed on 23.01.2018.
[42] Ripple. Ripple solution overview. Available at: https://ripple.com/
files/ripple_solutions_guide.pdf, 2018. Accessed on 19.01.2018.
[43] Ripple. Ripple documentation: Ledger format. Available at: https://ripple.
com/build/ledger-format/, 2017. Accessed on 19.01.2018.
108
[44] Ripple. Ripple documentation: Money in xrp ledger. Available at:
https://ripple.com/build/money-xrp-ledger/, 2017. Accessed
on 19.01.2018.
[45] David B. Oliynykov R Kiayias A., Russell A. Ouroboros: A provably secure
proof-of-stake blockchain protocol. Available at: https://link.springer.
com/chapter/10.1007/978-3-319-63688-7_12, 2017. Accessed on
06.02.2018.
[46] David B. Peter G. Kiayias A., Russell A. Ouroboros praos: An adaptively-secure,
semi-synchronous proof-of-stake blockchain. Available at: https://eprint.
iacr.org/2017/573.pdf, 2017. Accessed on 06.02.2018.
[47] Cardano. Why we are building cardano: Proof-of-stake. Available at: https:
//whycardano.com/#proof-of-stake, 2015. Accessed on 23.01.2018.
[48] Cardano. Why we are building cardano: Cardano-computation-layer. Avail-
able at: https://whycardano.com/#cardano-computation-layer,
2015. Accessed on 23.01.2018.
[49] LON WONG. Nem catapult white paper. Available at: https://nem.io/
wp-content/themes/nem/files/catapultwhitepaper.pdf, 2016.
[50] NEM. Nem technical reference. Available at: https://bitcoin.org/
bitcoin.pdf, 2018. Accessed on 23.01.2018.
[51] Finder.com. Nem for beginners: A step-by-step guide to xem. Available at:
https://www.finder.com/no/nem, 2018. Accessed on 07.02.2018.
[52] DAVID MAZIERES. The stellar consensus protocol: A federated model
for internet-level consensus. Available at: https://www.stellar.org/
papers/stellar-consensus-protocol.pdf, 2016. Accessed on
23.01.2018.
[53] Stellar Organization. Assets — stellar developers. Available at: https://www.
stellar.org/developers/guides/concepts/assets.html, 2017.
[54] Stefan Thomas. Why the stellar forking issue does not af-
fect ripple. Available at: https://ripple.com/dev-blog/
why-the-stellar-forking-issue-does-not-affect-ripple/,
2014. Accessed on 11.02.2018.
[55] Stellar Organization. Multisignature — stellar developers. Available
at: https://www.stellar.org/developers/guides/concepts/
multi-sig.html, 2017. Accessed on 11.02.2018.
[56] Stellar Organization. Using stellar for icos. Available at: https://www.
stellar.org/blog/using-stellar-for-ico/, 2017. Accessed on
11.02.2018.
109
[57] IOTA foundation. Pow on the tangle - iota docs. Available at: https://dev.
iota.org/introduction/tangle/proof-of-work, 2018. Accessed
on 12.02.2018.
[58] Scott J. Iota consensus masterclass. Available at: https://forum.

iota.org/t/iota-consensus-masterclass/1193, 2017. Accessed
on 19.03.2018.
[59] IOTA Foundation. Iota - next generation blockchain. Available at: https://
iota.org/, 2018. Accessed on 12.02.2018.
[60] Paul Handy. Introducing masked authenticated mes-

saging. Available at: https://blog.iota.org/
introducing-masked-authenticated-messaging-e55c1822d50e,
2017. Accessed on 12.02.2018.
[61] John D. Licciardello. Announcing the iota ecosys-

tem. Available at: https://blog.iota.org/
announcing-the-iota-ecosystem-339612656bc3, 2018. Accessed
on 12.02.2018.
[62] CryptoTraderNor. Summary, iota moscow meetup. Available at:

https://www.reddit.com/r/Iota/comments/7r23e0/summary_
iota_moscow_meetup/, 2018. Accessed on 12.02.2018.
[63] basiccrypto. (almost) everything you wanted to know about neo (part 1 of 2). Avail-
able at: https://steemit.com/cryptocurrency/@basiccrypto/
almost-everything-you-wanted-to-know-about-neo-part-1-of-2,
2017. Accessed on 15.02.2018.
[64] NEO. Neo white paper: A distributed network for the smart economy. Avail-
able at: http://docs.neo.org/en-us/index.html, 2014. Accessed on
23.01.2018.
[65] neo project. Neo white paper. Available at: https://github.com/

neo-project/docs/blob/master/en-us/index.md, 2018. Accessed
on 15.02.2018.
[66] Blocktivity. Block’tivity: The real value of blockchains. Available at: http:
//www.blocktivity.info/, 2018. Accessed on 08.03.2018.
[67] Ripple. Ripple market performance. Available at: https://ripple.com/

xrp/market-performance/, 2018. Accessed on 08.03.2018.
[68] Trustnodes. Cardano eyes ethereum smart contracts, grabs half a billion mar-
ket cap. Available at: https://www.trustnodes.com/2017/10/02/
cardano-eyes-ethereum-smart-contracts-grabs-half-billion-market-cap
2017. Accessed on 08.03.2018.
110
[69] Lumenauts. How many transactions per second can stellar pro-
cess? Available at: https://www.lumenauts.com/blog/
how-many-transactions-per-second-can-stellar-process,
2018. Accessed on 08.03.2018.
[70] iotasear.ch. Nonzero transactions feed. Available at: https://iotasear.ch/

live-transactions, 2018. Accessed on 09.03.2018.
[71] CryptoCoinMastery. Neos reddit ama top 10 questions and answers. Available
at: https://cryptocoinmastery.com/neo-reddit-ama/, 2017. Ac-
cessed on 09.03.2018.
[72] Ittay Eyal Adem Efe Gencer Ari Juels Ahmed Kosba Andrew Miller Pra-
teek Saxena Elaine Shi Emin Gn Sirer Dawn Song Kyle Croman, Chris-
tian Decker and Roger Wattenhofer. On scaling decentralized blockchains.
Available at: http://www.comp.nus.edu.sg/˜prateeks/papers/
Bitcoin-scaling.pdf, 2016. Accessed on 08.03.2018.
[73] etherescan. Ethereum transaction history. Available at: https://etherscan.

io/chart/tx, 2018. Accessed on 08.03.2018.
[74] Dominik Scheiner. Iota stresstest. Available at: https://twitter.com/

domschiener/status/858379721029111808?lang=en, 2017. Ac-
cessed on 09.03.2018.
[75] steemhoops99. Transaction speed - bitcoin, visa, iota, paypal. Avail-

able at: https://steemit.com/cryptocurrency/@steemhoops99/
transaction-speed-bitcoin-visa-iota-paypal, 2017. Accessed
on 09.03.2018.
[76] steemhoops99. In tangle we trust - 10 amazing facts about iota +

1000000 token giveaway (faucet closed- pending payouts still resum-
ing). Available at: https://steemit.com/iota/@steemhoops99/
in-tangle-we-trust-10-amazing-facts-about-iota-1000000-token-giveaw
2017. Accessed on 09.03.2018.
[77] CaptainPatent. Theoretical maximum tps for iota assuming bandwidth and node
performance limitations. Available at: https://www.reddit.com/r/
Iota/comments/7kdkcc/theoretical_maximum_tps_for_iota_
assuming/drdmjgz/, 2018. Accessed on 09.03.2018.
[78] Mark Schwarz. Transaction speeds: Which crypto is the fastest? Available
at: https://www.abitgreedy.com/transaction-speed/, 2018. Ac-
cessed on 09.03.2018.
[79] XBCADMIN. Block size and transactions per second.

Available at: https://www.bitcoinplus.org/blog/
block-size-and-transactions-second, 2017. Accessed on
08.03.2018.
111
[80] Blockchain.info. Average number of transactions per block. Available at: https:
//blockchain.info/charts/n-transactions-per-block?
timespan=all, 2018. Accessed on 08.03.2018.
[81] Stellar. Fees — stellar developers. Available at: https://www.
stellar.org/developers/guides/concepts/fees.html#
transaction-fee, 2018. Accessed on 10.03.2018.
[82] Bitinfocharts. Bitcoin avg. transaction fee historical chart. Available at: https:
//bitinfocharts.com/comparison/bitcoin-transactionfees.
html, 2018. Accessed on 15.03.2018.
[83] bitcoin.it. Mining. Available at: https://en.bitcoin.it/wiki/Mining,
2018. Accessed on 09.03.2018.
[84] Bitinfocharts. Bitcoin, ethereum, ripple avg. transactions historical
chart. Available at: https://bitinfocharts.com/comparison/
transactions-btc-eth-xrp.html, 2018. Accessed on 15.03.2018.
[85] Vitalik Buterin. A next-generation smart contract and decentralized application
platform. Available at: https://github.com/ethereum/wiki/wiki/
White-Paper, 2014. Accessed on 17.11.2017.
[86] Vitalik Buterin. Devcon1: Understanding the ethereum blockchain protocol
- vitalik buterin. Available at: https://www.youtube.com/watch?v=
gjwr-7PgpN8, 2016. Accessed on 23.01.2018.
[87] Arthur Britto David Schwartz, Noah Youngs. The ripple protocol consensus algo-
rithm. Available at: https://ripple.com/files/ripple_consensus_
whitepaper.pdf, 2014. Accessed on 19.01.2018.
[88] Ripple. Ripple solution overview. Available at: http://
whitepaperdatabase.com/ripple-xrp-whitepaper/, 2017. Ac-
cessed on 19.01.2018.
[89] Cardano. Why we are building cardano. Available at: https://whycardano.
com/, 2015. Accessed on 23.01.2018.
[90] Cardano. Cardano academic papers. Available at: https://www.
cardanohub.org/en/academic-papers/, 2016. Accessed on
23.01.2018.
[91] NEM. Nem general information. Available at: http://docs.nem.io/en,
2016. Accessed on 23.01.2018.
[92] Majlinda Zhegu F. Xavier Olleros. Research handbook on digital transfor-
mations. Available at: https://books.google.no/books?hl=en&
lr=&id=1_QCDQAAQBAJ&oi=fnd&pg=PA225&dq=applications+
using+blockchain+technology&ots=s-32DzJHP1&sig=
lkvLiZxuDGUG2U9uuQwhX8eNATU&redir_esc=y#v=onepage&q=
112
applications%20using%20blockchain%20technology&f=false,
2016. Accessed on 19.02.2018.
[93] Nicolas van Saberhagen. Cryptonote v 2.0. Available at: https:

//github.com/monero-project/research-lab/blob/master/
whitepaper/whitepaper.pdf, 2013. Accessed on 19.02.2018.
[94] Christina Garman Matthew Green Ian Miers Eran Tromer Madars Virza Eli Ben-
Sasson, Alessandro Chiesa. Zerocash: Decentralized anonymous payments from
bitcoin (extended version). Available at: http://zerocash-project.org/
media/pdf/zerocash-extended-20140518.pdf, 2014. Accessed on
19.02.2018.
[95] Feng Hao Patrick McCorry, Siamak F. Shahandashti. A smart contract for board-
room voting with maximum voter privacy. Available at: https://eprint.
iacr.org/2017/110.pdf, 2017. Accessed on 25.11.2017.
[96] Emercoin. About emercoin. Available at: https://emercoin.com/

content/About_Emercoin.pdf, 2017. Accessed on 20.02.2018.
[97] Christian Meter. Design of distributed voting systems. Available at: https:
//arxiv.org/pdf/1702.02566.pdf, 2015. Accessed on 20.02.2018.
[98] Omni Layer. Omni layer: An open source, fully-decentralized asset platform on
the bitcoin blockchain. Available at: http://www.omnilayer.org/, 2018.
[99] Bitmessage wiki. Bitmessage wiki. Available at: https://bitmessage.org/

wiki/Main_Page, 2018. Accessed on 25.02.2018.
[100] Gridcoin. Gridcoin: Rewarding volunteer distributed computing. Available at:

https://www.gridcoin.us/, 2018. Accessed on 25.02.2018.
[101] MICHAEL DEVETSIKIOTIS KONSTANTINOS CHRISTIDIS. Blockchains and

smart contracts for the internet of things. Available at: http://ieeexplore.
ieee.org/stamp/stamp.jsp?tp=&arnumber=7467408&tag=1,
2016. Accessed on 27.02.2018.
[102] Paul Brody Veena Pureswaran. Device democracy: Saving the future of the
internet of things. Available at: http://www-935.ibm.com/services/
us/gbs/thoughtleadership/internetofthings/, 2014. Accessed on
28.02.2018.
[103] Julia Angwin. Own a vizio smart tv? its watching you.
Available at: https://www.propublica.org/article/
own-a-vizio-smart-tv-its-watching-you, 2015. Accessed on
28.02.2018.
113
[104] Sebastian Malo. In new york, neighbors trading solar en-
ergy electrify community. Available at: https://www.
reuters.com/article/us-energy-usa-blockchain/
in-new-york-neighbors-trading-solar-energy-electrify-community-idUS
2017. Accessed on 28.02.2018.
[105] NZPA. Rush to find extent of nz melamine contamination. Avail-
able at: http://www.stuff.co.nz/national/644196/
Rush-to-find-extent-of-NZ-melamine-contamination, 2009.
[106] CW Chan EYY Chan, SM Griffiths. Public-health risks of melamine
in milk products. Available at: https://ac.els-cdn.com/
S0140673608616049/1-s2.0-S0140673608616049-main.pdf?
_tid=95bf42f4-1b04-46fe-a1e3-62f90a67451c&acdnat=
1520329440_af4f8ae396e0205370e78b4f13b8b227, 2008. Accessed
on 06.03.2018.
[107] WHO. Emergencies preparedness, response: Questions and answers on melamine.
Available at: http://www.who.int/csr/media/faq/QAmelamine/
en/, 2018. Accessed on 06.03.2018.
[108] Wacoin.io. Wabi - crypto token for safe consumer products. Available at: https:
//resources.wacoin.io/WaBI_Whitepaper_ENG.pdf, 2017. Ac-
cessed on 27.02.2018.
[109] Joseph Young. Ibm invests $200 million in iot blockchain, partners with
unionpay. Available at: https://cointelegraph.com/news/
ibm-invests-200-million-in-iot-blockchain-partners-with-unionpay,
2016. Accessed on 07.03.2018.
[110] Chain of things. Advancing innovation in blockchain & iot. Available at: https:
//www.chainofthings.com, 2018. Accessed on 07.03.2018.
[111] Filament. Enabling the future of iot. Available at: https://filament.com/,
2018. Accessed on 07.03.2018.
[112] Joy Patra Amitranjan Gantait and Ayan Mukherjee. Implement-
ing blockchain for cognitive iot applications, part 1: Integrate de-
vice data with smart contracts in ibm blockchain. Available at:
https://www.ibm.com/developerworks/cloud/library/
cl-blockchain-for-cognitive-iot-apps-trs/, 2017. Accessed on
07.03.2018.
[113] Autologger. Autologger for trygg kjoreadferd. Available at: https://www.
autologger.no/, 2018. Accessed on 07.03.2018.
[114] Chain of things. Case study 1: Chain of security. Available at: https:
//www.chainofthings.com/cs1chainofsecurity/, 2018. Accessed
on 07.03.2018.
114
[115] Salil S. Kanhere Ali Dorri, Marco Steger and Raja Jurdak. Blockchain: A dis-
tributed solution to automotive security and privacy. Available at: https://
arxiv.org/ftp/arxiv/papers/1704/1704.00073.pdf, 2017. Ac-
cessed on 01.03.2018.
[116] Chris Valasek Charlie Miller. Remote exploitation of an unaltered passenger vehi-
cle. Available at: https://securityzap.com/files/Remote%20Car%
20Hacking.pdf, 2015. Accessed on 01.03.2018.
[117] Soohyung Kim Seyoung Huh, Sangrae Cho. Managing iot devices using blockchain
platform. Available at: http://ieeexplore.ieee.org/stamp/stamp.
jsp?tp=&arnumber=7890132, 2017. Accessed on 20.02.2018.
[118] Nielseen. Is sharing the new buying? Available at: http://www.nielsen.

com/content/dam/nielsenglobal/apac/docs/reports/2014/
Nielsen-Global-Share-Community-Report.pdf, 2014. Accessed on
13.04.2018.
[119] slock.it. Slock.it: Solutions. Available at: https://slock.it/solutions.

html, 2018. Accessed on 28.02.2018.
[120] Val A. Red. Practical comparison of distributed ledger technologies

for iot. Available at: https://www.spiedigitallibrary.
org/conference-proceedings-of-spie/10206/102060G/
Practical-comparison-of-distributed-ledger-technologies-for-IoT/
10.1117/12.2262793.full?SSO=1, 2017. Accessed on 28.02.2018.
[121] Lauritz P. Somme. Delingokonomiplatform. Available at:

https://docs.google.com/spreadsheets/d/1VqcmklHv_
e2rq6J3VYKvKdrqMFBU3hSQ-6tDbPbTVhc/edit?usp=sharing,
2018. Accessed on.
[122] Alistair Cockburn. Writing effective use cases. Available at: http://
alistair.cockburn.us/get/2465, 2001. Accessed on 11.04.2018.
[123] CONSENSYS. Truffle suite - your ethereum swiss army knife. Available at: http:
//truffleframework.com/, 2018. Accessed on 01.05.2018.
[124] Ethereum. Ethereum javascript api. Available at: https://github.com/

ethereum/web3.js/, 2018. Accessed on 01.05.2018.
[125] HTML5 UP. Overflow — html5 up. Available at: https://html5up.net/

overflow, 2018. Accessed on 01.05.2018.
[126] Briony J. Oates. Researching information systems and computing, 2006. Accessed
on 11.05.2018.
[127] ETH Gas station. Eth gas station. Available at: https://ethgasstation.
info/, 2018. Accessed on 25.05.2018.
115
[128] DR. GAVIN WOOD. Ethereum: A secure decentralised generalised transaction
ledger eip-150 revision, ethereum project yellow paper. Available at: http://
gavwood.com/paper.pdf, 2014. Accessed on 25.05.2018.
[129] Solidity. Types - soliditt 0.4.21 documentation. Available at: http://
solidity.readthedocs.io/en/v0.4.21/types.html, 2018. Ac-
cessed on 23.04.2018.
[130] Etherscan. Ethereum average blocktime chart. Available at: https://
etherscan.io/chart/blocktime, 2018. Accessed on 25.05.2018.
[131] Vitalik Buterin. On slow and fast block times. Available at: https://blog.
ethereum.org/2015/09/14/on-slow-and-fast-block-times/,
2015. Accessed on 25.05.2018.
[132] Wikipedia contributors. Facebookcambridge analytica data scandal. Available at:
https://en.wikipedia.org/w/index.php?title=Facebook%E2%
80%93Cambridge_Analytica_data_scandal&oldid=842502787,
2018. Accessed on 24.05.2018.
[133] Ethereum community Vitalik Buterin. Whisper. Available at: https:
//github.com/ethereum/wiki/wiki/Whisper, 2018. Accessed on
23.05.2018.
[134] Coinmarketcap.com. Gas (gas). Available at: https://coinmarketcap.
com/currencies/gas/, 2018. Accessed on 25.05.2018.
[135] Tyson O’Ham. Neo blockchain goes down after a single node dis-
connects temporarily. Available at: https://bitsonline.com/
neo-blockchain-tanks/, 2018. Accessed on 25.05.2018.
[136] Ethereum. Populus: The ethereum development framework with the most cute
animal pictures. Available at: https://github.com/ethereum/populus,
2018. Accessed on 26.05.2018.
[137] Embark-framework. Embark: Framework for serverless decentralized applications
using ethereum, ipfs and other platforms. Available at: https://github.com/
embark-framework/embark, 2018. Accessed on 26.05.2018.
[138] Aragon. Aragon nest. Available at: https://github.com/aragon/nest,
2018. Accessed on 26.05.2018.
[139] Trufflesuite. Truffle: The most popular ethereum development framework. Avail-
able at: https://github.com/trufflesuite/truffle, 2018. Ac-
cessed on 26.05.2018.
[140] Dave Kajpust. The best way to start coding in solid-
ity. Available at: https://medium.com/@davekaj/
solidity-tips-and-tricks-for-beginners-building-their-first-dapp-on
2017. Accessed on 25.05.2018.
116
[141] ConsenSys. A 101 noob intro to programming smart contracts on
ethereum. Available at: https://medium.com/@ConsenSys/
a-101-noob-intro-to-programming-smart-contracts-on-ethereum-695d15c
2015. Accessed on 25.05.2018.
[142] Ethereum. Proof of stake faq. Available at: https://github.com/
ethereum/wiki/wiki/Proof-of-Stake-FAQ, 2018. Accessed on
26.05.2018.
[143] StorJ. Decentralized cloud storage - storj. Available at: https://storj.io/,
2018. Accessed on 26.05.2018.
[144] David Sønstrebø. Iota development roadmap. Available at: https://blog.

iota.org/iota-development-roadmap-74741f37ed01, 2017. Ac-
cessed on 26.05.2018.
[145] Sia. Sia. Available at: https://sia.tech/, 2018. Accessed on 26.05.2018.
[146] Walla. David snsteb, iota interview,. Available at: https://www.youtube.
com/watch?v=T2FJ9hH66b8&t=38m10s, 2017. Accessed on 26.05.2018.
[147] Neha Narula. Cryptographic vulnerabilities in
iota. Available at: https://medium.com/@neha/
cryptographic-vulnerabilities-in-iota-9a6a9ddc4367,
2017. Accessed on 26.05.2018.
[148] IOTA. Consensus on the tangle - iota docs. Available at: https://docs.iota.
org/introduction/tangle/consensus, 2018. Accessed on 26.05.2018.
[149] IOTA. Iota data market. Available at: https://data.iota.org/, 2018. Ac-
cessed on 26.05.2018.
117
118
Appendix
lstlisting breaklines=true
119
120
Appendix A
Smart contract code
pragma solidity ˆ0.4.11;
contract RentableObjects {
struct Client {
address cliAddress;
uint since;
bool exists;
}
struct Object {
uint objId;
string description;
uint deposit;
uint[] dataWeights;
uint[] data;
Client client;
uint created;
address owner;
bool exists;
uint lastPaid;
uint depositReset;
}
mapping (uint => Object) objects;
address owner;
function RentableObjects() {
owner = msg.sender;
}
function registerObject(uint _objId, string _descr, uint

_deposit, uint[] _dataWeights, uint[] _data) returns (bool) {
121
if ( !(objectIsRegistered(_objId)) ) {
Client memory nilClient = Client({cliAddress: 0, since: now,
exists: false});
objects[_objId] = Object({objId: _objId, description: _descr,
deposit: _deposit, dataWeights: _dataWeights, client:
nilClient, created: now, owner: msg.sender, exists: true,
lastPaid: 0, data: _data, depositReset: _deposit});
return true;
}
revert();
}
function unregisterObject(uint _objId) returns (bool) {

if ( objectIsRegistered(_objId) && !(objectIsRented(_objId)) )
{
delete objects[_objId];
return true;
}
revert();
}
function rentObject(uint _objId) payable returns (bool) {

if ( !(objectIsRegistered(_objId)) || objectIsRented(_objId) ||
msg.value < objects[_objId].deposit) {
revert();
}
objects[_objId].client = Client({cliAddress: msg.sender, since:
now, exists: true});
if ( !objects[_objId].client.cliAddress.send(msg.value -
objects[_objId].deposit) ) {
revert();
}
return true;
}
function reclaimObject(uint _objId) returns (bool) {

assert ( objectIsRented(_objId) && objects[_objId].owner == msg
.sender );
if ( !objects[_objId].client.cliAddress.send(objects[_objId].
deposit) ) {
revert();
}
objects[_objId].deposit = objects[_objId].depositReset;
objects[_objId].client = Client({cliAddress: 0, since: now,
exists: false});
return true;
}
function payData(uint _objId, uint[] data) returns (bool) {
uint[] memory _dataWeights = getObjectDataWeights(_objId);
uint[] memory _data = data;
122
uint dataPrice = 0;
for(uint i = 0; i < getDataWeightsLength(_objId); i++){
dataPrice += _dataWeights[i]*_data[i];
}
objects[_objId].lastPaid = dataPrice;
if ( !objects[_objId].owner.send(dataPrice) ) {
revert();
}
objects[_objId].deposit = objects[_objId].deposit - dataPrice;
return true;
}
function objectIsRegistered(uint _objId) returns (bool) {

return objects[_objId].exists;
}
function objectIsRented(uint _objId) returns (bool) {

return objects[_objId].exists && objects[_objId].client.exists;
}
function getObjectDeposit(uint _objId) returns (uint) {

return objects[_objId].deposit;
}
function getObjectDescription(uint _objId) returns (string) {

return objects[_objId].description;
}
function getObjectClientExists(uint _objId) returns (bool) {

return objects[_objId].client.exists;
}
function getObjectClientTime(uint _objId) returns (uint) {

return now - objects[_objId].client.since;
}
function getObjectClientAddress(uint _objId) returns (address) {

return objects[_objId].client.cliAddress;
}
function getObjectOwnerAddress(uint _objId) returns (address) {

return objects[_objId].owner;
}
function getContractOwnerAddress() returns (address) {

return owner;
}
function getObjectDataWeights(uint _objId) returns (uint[]) {
return objects[_objId].dataWeights;
123
}
function getObjectData(uint _objId) returns (uint[]) {
return objects[_objId].data;
}
function getDataWeightsLength(uint _objId) returns (uint) {
return objects[_objId].dataWeights.length;
}
function getDataLength(uint _objId) returns (uint) {
return objects[_objId].data.length;
}
function getLastPaid(uint _objId) returns (uint) {
return objects[_objId].lastPaid;
}
function () {
revert();
}
124
Appendix B
User interface code
"use strict";
var accounts;
var account;
var objectId;
var contractOwner;
var balance;
var finney = 1 / 1000;
var wei = 1 / 1000000000000000000;
var contract = require(’truffle-contract’);

var Web3 = require(’web3’);
var provider = new Web3.providers.HttpProvider("http://localhost
:28545");
var web3 = new Web3(provider);
var json = require(’../../build/contracts/RentableObjects.json’);

var RentableObjects = contract(json);
RentableObjects.setProvider(provider);
var qrScanner = require(’./qr-scanner.js’);
var blockCreator = setInterval(function () {

console.log("Creating Block.");
web3.eth.sendTransaction({from: accounts[2], to: accounts[2],
value: 5});
if (objectId !== undefined) {

getObjectClientTime(objectId, function (clientTime) {
var clientTimeElement = document.getElementById("clientTime")
;
clientTimeElement.innerHTML = parseInt(clientTime);
125
});
}
}, 30000);
var initWindow = function () {

qrScanner.init();
web3.eth.getAccounts(function (err, accs) {

if (err !== null) {
alert("There was an error fetching your accounts.");
console.log(err, accs);
return;
}
if (accs.length === 0) {
alert("Couldn’t get any accounts! Make sure your Ethereum
client is configured correctly.");
return;
}
initState();
accounts = accs;
var accNum = parseInt(get(’accNum’));

console.log(accNum);
if ((accNum === 0) || (accNum === 1) || (accNum === 2)) {
console.log("Switching to Account: ", accNum);
account = accounts[accNum];
}
else {
account = accounts[0];
var remoteUrl = "192.168";
if (window.location.href.indexOf(remoteUrl) >= 0) {
}
}
refreshBalance();
var objIdElement = document.getElementById("_objId");

var _objId = get(’objId’);
if (_objId !== undefined) {
objectId = _objId;
objIdElement.value = _objId;
switchPageView();
}
});
};
126
function initState() {
return instance.getContractOwnerAddress.call({from: account});
}).then(function (value) {
contractOwner = value;
if (!contractOwner) {
throw "Expected contractOwner to be defined!";
}
console.log("Setting contractOwner=" + value);

console.log(e);
setStatus("Error executing getContractOwnerAddress()");
});
}
var setObjectId = function (objId) {

objectId = objId;
};
var switchPageView = function() {
refreshStatus();
refreshDetails();
refreshBalance();
objectIsRegistered(objectId, function (registered) {

if (registered) {
// object is registered
objectIsRented(objectId, function (rented) {
if (rented) {
// object is rented
getObjectClientAddress(objectId, function (clientAddress)
{
if (clientAddress === account) {
// account is client -> show rentOverview
document.getElementById("ownersPage").style.display = "
none";
document.getElementById("reclaimPage").style.display =
"none";
document.getElementById("rentOverview").style.display =
"block";
document.getElementById("rentingPage").style.display =
"none";
document.getElementById("objectInformation").style.
display = "block";
document.getElementById("registerPage").style.display =
"none";
127
document.getElementById("notFoundPage").style.display =
"none";
document.getElementById("dataInsertion").style.display
= "block";
document.getElementById("mapInformation").style.display
= "none";
}
else if (account === contractOwner) {
// account is owner -> show reclaimPage
console.log("Account owns this (rented) object.");
none";
"block";
"none";
"none";
display = "block";
"none";
"none";
= "none";
= "block";
}
else {
// account is third party -> show object information
none";
"none";
"none";
"none";
display = "block";
"none";
"none";
= "none";
128
= "none";
}
});
}
else {
// object is unrented
if (account === contractOwner) {
// object is unrented -> show stats for owner
block";
document.getElementById("reclaimPage").style.display = "
none";
document.getElementById("rentOverview").style.display = "
none";
document.getElementById("rentingPage").style.display = "
none";
display = "block";
document.getElementById("registerPage").style.display = "
none";
document.getElementById("dataInsertion").style.display =
"none";
document.getElementById("mapInformation").style.display =
"none";
}
else {
// account is not owner -> show rentingPage
none";
document.getElementById("reclaimPage").style.display = "
none";
none";
document.getElementById("rentingPage").style.display = "
block";
display = "block";
none";
document.getElementById("notFoundPage").style.display = "
none";
document.getElementById("dataInsertion").style.display =
"none";
document.getElementById("mapInformation").style.display =
"none";
}
}
});
129
}
else {
// object is unregistered
if (account === contractOwner) {
// account is contract owner -> show register screen
document.getElementById("ownersPage").style.display = "none
";
document.getElementById("reclaimPage").style.display = "none
";
none";
document.getElementById("rentingPage").style.display = "none
";
document.getElementById("objectInformation").style.display =
"none";
block";
none";
document.getElementById("dataInsertion").style.display = "
none";
document.getElementById("mapInformation").style.display = "
none";
}
else {
// -> show not found screen
document.getElementById("ownersPage").style.display = "none
";
none";
document.getElementById("reclaimPage").style.display = "none
";
document.getElementById("rentingPage").style.display = "none
";
document.getElementById("objectInformation").style.display =
"none";
none";
block";
document.getElementById("dataInsertion").style.display = "
none";
document.getElementById("mapInformation").style.display = "
none";
}
}
});
};
function get(name) {
130
if (name = (new RegExp(’[?&]’ + encodeURIComponent(name) +
’=([ˆ&]*)’)).exec(location.search))
return decodeURIComponent(name[1]);
}
var toggleAccounts = function () {

if (account === accounts[0]) {
}
else {
}
var addressElement = document.getElementById("address");
addressElement.innerHTML = formatAccountAddress(account);
setStatus("");
if (objectId !== undefined) {

switchPageView();
console.log("Switching page view");
} else {
refreshBalance();
}
};
function setStatus(message) {
var status = document.getElementById("status");
status.innerHTML = message;
}
function setLoading(show) {
if (show) {
document.getElementById("loadingDiv").style.display = "inline";
}
else {
document.getElementById("loadingDiv").style.display = "none";
}
}
function refreshBalance() {
var balance = web3.eth.getBalance(account) * wei;

var balanceElement = document.getElementById("balance");
balanceElement.innerHTML = balance.toFixed(3);
}
function viewRegisterPage(state) {
var registerPage = document.getElementById("registerPage");
131
var unregisterPage = document.getElementById("unregisterPage");
if ((registerPage !== null) && (unregisterPage !== null)) {
if (state) {
registerPage.style.display = "none";
unregisterPage.style.display = "block";
}
else {
registerPage.style.display = "block";
unregisterPage.style.display = "none";
}
}
}
function objectIsRegistered(objId, callBack) {

return instance.objectIsRegistered.call(objId, {from: account})
;
callBack(value);
console.log(e);
setStatus("Error getting objectIsRegistered()");
});
}
function objectIsRented(objId, callBack) {

return instance.objectIsRented.call(objId, {from: account})
callBack(value);
console.log(e);
setStatus("Error getting objectIsRented()");
});
}
function getObjectDeposit(objId, callBack) {

return instance.getObjectDeposit.call(objId, {from: account})
callBack(value);
console.log(e);
132
setStatus("Error executing getObjectDeposit()");
});
}
function getObjectDescription(objId, callBack) {

return instance.getObjectDescription.call(objId, {from: account
})
callBack(value);
console.log(e);
setStatus("Error executing getObjectDescription()");
});
}
function getObjectClientAddress(objId, callBack) {

return instance.getObjectClientAddress.call(objId, {from:
account})
callBack(value);
console.log(e);
setStatus("Error executing getObjectClientAddress()");
});
}
function getObjectClientTime(objId, callBack) {

return instance.getObjectClientTime.call(objId, {from: account
})
callBack(value);
console.log(e);
setStatus("Error executing getObjectClientTime()");
});
}
function getObjectDataWeights(objId, callBack) {

133
return instance.getObjectDataWeights.call(objId, {from: account
})
callBack(value);
console.log(e);
setStatus("Error executing getObjectDataWeights()");
});
}
function getObjectData(objId, callBack) {

return instance.getObjectData.call(objId, {from: account})
callBack(value);
console.log(e);
setStatus("Error executing getObjectData()");
});
}
function getObjectLastPaid(objId, callBack) {
return instance.getLastPaid.call(objId, {from: account})
callBack(value);
console.log(e);
setStatus("Error executing getObjectDataWeights()");
});
}
function refreshStatus() {

var objIdElement = document.getElementById("objId");

objIdElement.innerHTML = objectId;
objectIsRegistered(objectId, function (value) {

var registeredElement = document.getElementById("registered");
if (value) {
registeredElement.innerHTML = "";
}
else {
registeredElement.innerHTML = "not ";
134
}
viewRegisterPage(value);
});
objectIsRented(objectId, function (value) {

var rentedElement = document.getElementById("rented");
if (value) {
rentedElement.innerHTML = "";
}
else {
rentedElement.innerHTML = "not ";
}
});
function refreshDetails() {
getObjectDeposit(objectId, function (value) {

var depositElement = document.getElementById("deposit");
var deposit = parseInt(value) * wei;
depositElement.innerHTML = deposit.toFixed(4);
});
getObjectDescription(objectId, function (value) {

var descriptionElement = document.getElementById("description")
;
descriptionElement.innerHTML = value;
});
getObjectClientTime(objectId, function (value) {

var clientTimeElement = document.getElementById("clientTime");
clientTimeElement.innerHTML = parseInt(value);
});
getObjectDataWeights(objectId, function (value) {

var clientTimeElement = document.getElementById("
objectDataWeights");
const reducer = (acc,curr) => acc + " " + curr;
const mapped = value.map(c => (c * wei).toFixed(4));
console.log("Her kommer en array");
console.log(mapped);
const reduced = mapped.reduce(reducer, "");
clientTimeElement.innerHTML = reduced;
});
getObjectLastPaid(objectId, function (value) {

var clientTimeElement = document.getElementById("lastPaid");
clientTimeElement.innerHTML = (parseInt(value) * wei).toFixed
135
(4);
});
var clientObjectElement = document.getElementById("clientObject

");
if (clientObjectElement !== null) {
clientObjectElement.innerHTML = parseInt(objectId);
}
}
function registerObject() {
var deposit = parseInt(document.getElementById("_deposit").value
) / wei;
var description = document.getElementById("_description").value;
var dataWeightsTime = parseInt(document.getElementById("
_dataWeightsTime").value) / wei;
var dataWeightsGps = parseInt(document.getElementById("
_dataWeightsGps").value) / wei;
var dataWeightsAccel = parseInt(document.getElementById("
_dataWeightsAccel").value) / wei;
var dataWeightsImpact = parseInt(document.getElementById("
_dataWeightsImpact").value) / wei;
var dataWeight = new Array(dataWeightsTime, dataWeightsGps,
dataWeightsAccel, dataWeightsImpact)
var data = [0,0,0,0];
console.log(rentable);
console.log(deposit);
console.log(description);
console.log(objectId);
console.log(dataWeight);
setStatus("Registering object... (please wait)");

setLoading(true);
setTimeout(function () {
setLoading(false);
}, 3000);
// we store all value in wei
return instance.registerObject(objectId, description, deposit,
dataWeight, data, {
from: account,
gas: 1000000
})
}).then(function (regSuccess) {
console.log(regSuccess);
if (regSuccess) {
setStatus("New object registered successfully.");
136
}
else {
setStatus("Object registering not possible. Please try again
.");
}
switchPageView();
console.log(e);
setStatus("Error registering object; see log.");
});
}
function unregisterObject() {
setStatus("Unregistering object... (please wait)");
return instance.unregisterObject(objectId, {from: account, gas:
1000000}).then(function (success) {
if (success) {
setStatus("Object removed successfully.");
}
else {
setStatus("Unregistering object not possible. Please try
again.");
}
refreshStatus();
})
console.log(e);
setStatus("Error unregistering object; see log.");
});
}
function rentObject() {
setStatus("Renting object... (please wait)");
getObjectDeposit(objectId, function (deposit) {
console.log("Renting object with objId=%s", objectId);
var objId = Number(objectId);
return instance.rentObject(objId, {from: account, value:
deposit, gas: 1000000}).then(function (success) {
if (success) {
setStatus("Object successfully rented.");
}
else {
setStatus("Renting object not possible. Please try again
137
.");
}
switchPageView();
})
console.log(e);
setStatus("Error renting object; see log.");
});
});
}
function payData() {
var dataWeightsTime = parseInt(document.getElementById("
_dataTime").value);
var dataWeightsGps = parseInt(document.getElementById("_dataGps
").value);
var dataWeightsAccel = parseInt(document.getElementById("
_dataAccel").value);
var dataWeightsImpact = parseInt(document.getElementById("
_dataImpact").value);
var data = new Array(dataWeightsTime, dataWeightsGps,
dataWeightsAccel, dataWeightsImpact);
console.log(data);
return instance.payData(objectId, data, {
from: account,
gas: 1000000
}).then(function (success) {
if (success) {
setStatus("Object paid data");
}
else {
setStatus("object did not pay");
}
switchPageView();
})
console.log(e);
setStatus("Error paying object; see log.");
});
}
function reclaimObject() {
console.log("Reclaiming object with objectId=" + objectId);
setStatus("Returning object... (please wait)");

return instance.reclaimObject(objectId, {from: account, gas:
138
1000000}).then(function (success) {
if (success) {
console.log("Object with objectId=" + objectId + "
successfully reclaimed.");
setStatus("Object successfully reclaimed.");
}
else {
console.log("Reclaiming object objectId=" + objectId + " not
possible. Please try again.");
setStatus("Reclaiming object not possible. Please try again
.");
}
switchPageView();
})}).catch(function (e) {
console.log(e);
setStatus("Error returning object; see log.");
});
}
function formatAccountAddress(account) {
return account.substr(0, 32) + ’...’;
}
module.exports = {
initWindow: initWindow,
toggleAccounts: toggleAccounts,
setObjectId: setObjectId,
switchPageView: switchPageView,
registerObject: registerObject,
rentObject: rentObject,
unregisterObject: unregisterObject,
reclaimObject: reclaimObject,
payData: payData
};
window.addEventListener(’load’, function () {
if (typeof web3 !== ’undefined’) {
console.warn("Using web3 detected from external source. If you
find that your accounts don’t appear or you have 0 MetaCoin
, ensure you’ve configured that source properly. If using
MetaMask, see the following link. Feel free to delete this
warning. :) http://truffleframework.com/tutorials/truffle-
and-metamask");
// Use Mist/MetaMask’s provider
window.web3 = new Web3(web3.currentProvider);
} else {
console.warn("No web3 detected. Falling back to http://
localhost:8545. You should remove this fallback when you
139
deploy live, as it’s inherently insecure. Consider
switching to Metamask for development. More info here: http
://truffleframework.com/tutorials/truffle-and-metamask");
// fallback - use your fallback strategy (local node / hosted
node + in-dapp id mgmt / fail)
window.web3 = new Web3(new Web3.providers.HttpProvider("http://
localhost:8545"));
}
});
140

Fulltext PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Fulltext PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Decentralized Item Sharing Powered by

the Blockchain and the Internet of Things

Lauritz Prag Sømme

Master of Science in Informatics

Norwegian University of Science and Technology

Research question 4: How can data be stored on a blockchain to provide manufactur-

Teknologien gjør at flere personer deltar i delingsøkonomien. Samtidig kommer Tingenes

I denne oppgaven vurderes de ti mest verdifulle blockchain-protokollene. Dette gjøres

Forskningsspørsmål 1: Hvordan kan data brukes i en desentralisert

Forskningsspørsmål 2: Hvordan kan et slikt system tillate for desentralisert betaling i

Forskningsspørsmål 3: Hvordan kan transaksjoner med data gjort i sanntid gi sanntidsin-

Forskningsspørsmål 4: Hvordan kan data lagres i en blokkjede for å gi produktprodusen-

Avhandlingen demonstrerer at det er mulig å lage og bruke en blokkjedebasert

Table of Contents viii

List of Figures xii

4 State of the art of blockchain technologies 19

6 High level architecture and design 59

7 Detailed design and implementation 67

8 Evaluation and discussion 83

A Smart contract code 121

B User interface code 125

4.1 Bitcoin block structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 Possible sensor data measurements for different items . . . . . . . . . . . 53

2.1 Sharing economy business models sorted by industry . . . . . . . . . . . 7

3.1 The different visions that IoT consists of . . . . . . . . . . . . . . . . . . 10

4.1 A message M is hashed by hash function H, and a hash value h is returned.

8.1 Prototype’s architecture if implemented with IOTA . . . . . . . . . . . . 99

SEP = Sharing Economy Platform

In 2009 a decentralized crypto-currency was proposed by Satoshi Nakamoto. The pa-

Research question 4: How can data be stored on a blockchain provide manufacturers

1.3 Scientific contribution

• Demonstrating how sending data in transactions on a blockchain may generate data

• In addition, contrasting and comparing the top 10 cryptocurrencies, and elaborating

1.6 Document Structure

Three possible drivers have been identified for this development:

• Change in consumer behavior: Convenient, cost-efficient and ecologically friendly

2.1 Sharing economy business models

2.1.1 Marketplace business model

2.1.2 Access based business model

2.1.3 On-demand service provider business model

3.1 Internet of things devices

3.1.2 Wireless Sensor networks (WSN)

3.1.3 Micro processor units (MPU) and microcontroller units (MCU)

3.2 Internet of things and its applications

• Transportation and logistics domain

• Smart environment (home, office, plant) domain

• Personal and social domain.

3.2.1 Transportation and logistics

Tracking is aimed at identifying people or objects in motion. This includes real-time

3.2.3 Smart environment

3.2.4 Personal and social

• Question 1: How does the blockchain work?

• Question 2: How does popular blockchain protocols work?

• Question 3: What are current applications of blockchain protocols?

• Question 4: How is the blockchain used with IoT in particular?

4.1.2 Hash functions

4.2 General search process

4.3 Question 1: How does the blockchain work?

• Name of coin: Bitcoin (BTC)

• Consensus algorithm: Proof-of-work

Size Field Description

Table 4.1: Bitcoin block structure

Size Field Description